Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson wrote > Denis Ovsienko wrote on Sun, 5 Aug 2018 > at 17:05:20 +0100 in > <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>: > > > It works in an interactive session; but as soon as the output makes > > it to the Internet and stays there long enough, people will no > > longer understand what the printed time was in their local time or > > UTC. The value of TZ influences the output, but remains invisible. > > I think this is not a real problem; in practice it's rare that long-lived > non-.pcap tcpdump decodings have significant meaning associates with the > time zone of time outputs from printers. One could imagine printing the > local time zone adjacent to the "listening on" output at startup, but it > seems unnecessary. > > But it's important not to let theoretical issues make the tool worse for > actual users. Thank you for your input John. When a network protocol has a timestamp and defines it in UTC (which is often the case), to me it looks consistent if the host in the middle of the exchange (or completely out of the exchange, if that is a .pcap file) prints it in UTC as well. Such as, for example somebody in time zone A decoding NTP packets between hosts in time zones B and C --- why would the man in the middle need to translate the timestamps to any of those timezones when NTP encodes and operates UTC in the first place? The protocol terminating software would be more likely to need to translate UTC to a local timezone to verify or action it. Opposed to that, a protocol decoder just tells you what's on the wire. I accept my point of view may make less sense to other people. > > I understand what you are suggesting, and your description is > > correct, but it does not solve the problem of interpreting tcpdump > > output correctly in a place or time different from the > > original. That said, I can live with print-rx.c using local time and > > being imperfect, it has worked like this many years. Still, I think > > local time should not be the norm for other decoders. > > Doesn't this argument apply for other decoders as well? Whatever is done > should not make the output of decoders harder for the diagnostic users of > tcpdump to interpret, or unnecessarily change the output format. The factor of consistency does indeed apply, and some decoders use UTC already, whilst some others seem to use local time and to fail the tests from time to time. Which reminds us that at the end of the day somebody will need to fix the AFS test, whatever is the consensus. > One could imagine having all of these printers respect -tt, &c., and > conceivably adding an option to force decoder time printing to be UTC; but > such an option would be tantamount to setting TZ=UTC, and generally the Unix > Way is not to duplicate such OS functionality. > > p.s.: Using GMT or GMT0 is deprecated, please use UTC instead. > > --jh...@mit.edu > John Hawkinson > -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
Denis Ovsienko wrote on Mon, 6 Aug 2018 at 09:42:16 +0100 in <1650e66b5ad.12b3ab99e15597.8336631397456496...@ovsienko.info>: > When a network protocol has a timestamp and defines it in UTC (which > is often the case), to me it looks consistent if the host in the > middle of the exchange (or completely out of the exchange, if that > is a .pcap file) prints it in UTC as well. Such as, for example > somebody in time zone A decoding NTP packets between hosts in time > zones B and C --- why would the man in the middle need to translate > the timestamps to any of those timezones when NTP encodes and > operates UTC in the first place? I think most of the time people who look at the output of decoders are doing so from the perspective of one of the two hosts, such as debugging application layer software. In such cases, the man in the middle perspective is really a strawman. > The protocol terminating software would be more likely to need to > translate UTC to a local timezone to verify or action it. Opposed to > that, a protocol decoder just tells you what's on the wire. Under normal usage, tcpdump prints the local time at the beginning of the line. A person looking at timestamps on the wire frequently wants to correlate those timestamps to the time of packet receipt. If they are in different timezones, that can be more challenging (although not always, since often we only care about the minutes and seconds). --jh...@mit.edu John Hawkinson ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On Mon, 06 Aug 2018 09:51:36 +0100 John Hawkinson wrote > Denis Ovsienko wrote on Mon, 6 Aug 2018 > at 09:42:16 +0100 in > <1650e66b5ad.12b3ab99e15597.8336631397456496...@ovsienko.info>: > > > When a network protocol has a timestamp and defines it in UTC (which > > is often the case), to me it looks consistent if the host in the > > middle of the exchange (or completely out of the exchange, if that > > is a .pcap file) prints it in UTC as well. Such as, for example > > somebody in time zone A decoding NTP packets between hosts in time > > zones B and C --- why would the man in the middle need to translate > > the timestamps to any of those timezones when NTP encodes and > > operates UTC in the first place? > > I think most of the time people who look at the output of decoders are doing > so from the perspective of one of the two hosts, such as debugging > application layer software. In such cases, the man in the middle perspective > is really a strawman. This is one of the popular use cases and I definitely have experience with it. However, another experience of mine was such troubleshooting sessions that involved engineers and hosts spread across several time zones. As the network engineer I was effectively the man in the middle, having to analyze traffic that was forwarded rather than terminated, and one of the things you want to keep out of scope are local timezones. I acknowledge this is not the most popular use case, but for me it is a valid experience to consider. > > The protocol terminating software would be more likely to need to > > translate UTC to a local timezone to verify or action it. Opposed to > > that, a protocol decoder just tells you what's on the wire. > > Under normal usage, tcpdump prints the local time at the beginning of the > line. A person looking at timestamps on the wire frequently wants to > correlate those timestamps to the time of packet receipt. If they are in > different timezones, that can be more challenging (although not always, > since often we only care about the minutes and seconds). You have a point, but let me remind that the host that makes the capture may be badly off in terms of both clock (because NTP is broken) and time zone (because it was deployed with a wrong configuration or the daylight saving rules have changed), so the capture timestamps should be taken with a grain of salt. Anyway, as I explained, I can live with either format so long as it is unambiguous. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On 06/08/2018 10:42, Denis Ovsienko wrote: > On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson wrote > > > Denis Ovsienko wrote on Sun, 5 Aug 2018 > > at 17:05:20 +0100 in > <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>: > > > I understand what you are suggesting, and your description is > > > correct, but it does not solve the problem of interpreting tcpdump > > > output correctly in a place or time different from the > > > original. That said, I can live with print-rx.c using local time and > > > being imperfect, it has worked like this many years. Still, I think > > > local time should not be the norm for other decoders. > > > > Doesn't this argument apply for other decoders as well? Whatever is done > should not make the output of decoders harder for the diagnostic users of > tcpdump to interpret, or unnecessarily change the output format. > > The factor of consistency does indeed apply, and some decoders use UTC > already, whilst some others seem to use local time and to fail the tests from > time to time. > Which reminds us that at the end of the day somebody will need to fix the AFS > test, whatever is the consensus. With the rx packet (#4 in the file) showing the problem, in the current printing (CEST), the capture time is '23:46:24' and the StoreStatus date is '22:46:24'. difference -1 hour. And with TZ=GMT0, The capture time is '21:46:24' (-2: OK) and the StoreStatus date is '21:46:24' (-1). same. Does anyone understand why? --- $ ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' reading from file tests/afs.pcap, link-type EN10MB (Ethernet) 4 1999-11-11 23:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, flags [none], proto UDP (17), length 108) 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call makedir fid 536871098/1/1 "tmpdir" StoreStatus date 1999/11/11 22:46:24 group 0 mode 755 (80) --- $ TZ=GMT0 ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' reading from file tests/afs.pcap, link-type EN10MB (Ethernet) 4 1999-11-11 21:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, flags [none], proto UDP (17), length 108) 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call makedir fid 536871098/1/1 "tmpdir" StoreStatus date 1999/11/11 21:46:24 group 0 mode 755 (80) -- Francois-Xavier ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On 06/08/2018 14:52, Francois-Xavier Le Bail wrote: > On 06/08/2018 10:42, Denis Ovsienko wrote: >> On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson >> wrote >> > Denis Ovsienko wrote on Sun, 5 Aug 2018 >> > at 17:05:20 +0100 in >> <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>: >> > > I understand what you are suggesting, and your description is >> > > correct, but it does not solve the problem of interpreting tcpdump >> > > output correctly in a place or time different from the >> > > original. That said, I can live with print-rx.c using local time and >> > > being imperfect, it has worked like this many years. Still, I think >> > > local time should not be the norm for other decoders. >> > >> > Doesn't this argument apply for other decoders as well? Whatever is done >> should not make the output of decoders harder for the diagnostic users of >> tcpdump to interpret, or unnecessarily change the output format. >> >> The factor of consistency does indeed apply, and some decoders use UTC >> already, whilst some others seem to use local time and to fail the tests >> from time to time. > >> Which reminds us that at the end of the day somebody will need to fix the >> AFS test, whatever is the consensus. > > With the rx packet (#4 in the file) showing the problem, in the current > printing (CEST), > the capture time is '23:46:24' and the StoreStatus date is '22:46:24'. > difference -1 hour. > And with TZ=GMT0, > The capture time is '21:46:24' (-2: OK) and the StoreStatus date is > '21:46:24' (-1). same. > > Does anyone understand why? > --- > $ ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' > reading from file tests/afs.pcap, link-type EN10MB (Ethernet) > 4 1999-11-11 23:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, > flags [none], proto UDP > (17), length 108) > 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call > makedir fid 536871098/1/1 > "tmpdir" StoreStatus date 1999/11/11 22:46:24 group 0 mode 755 (80) > --- > $ TZ=GMT0 ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' > reading from file tests/afs.pcap, link-type EN10MB (Ethernet) > 4 1999-11-11 21:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, > flags [none], proto UDP > (17), length 108) > 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call > makedir fid 536871098/1/1 > "tmpdir" StoreStatus date 1999/11/11 21:46:24 group 0 mode 755 (80) Perhaps a 'Daylight saving time' reason ... Not sure. -- Francois-Xavier ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On 06/08/2018 15:09, Francois-Xavier Le Bail wrote: > On 06/08/2018 14:52, Francois-Xavier Le Bail wrote: >> On 06/08/2018 10:42, Denis Ovsienko wrote: >>> On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson >>> wrote >>> > Denis Ovsienko wrote on Sun, 5 Aug 2018 >>> > at 17:05:20 +0100 in >>> <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>: >>> > > I understand what you are suggesting, and your description is >>> > > correct, but it does not solve the problem of interpreting tcpdump >>> > > output correctly in a place or time different from the >>> > > original. That said, I can live with print-rx.c using local time and >>> > > being imperfect, it has worked like this many years. Still, I think >>> > > local time should not be the norm for other decoders. >>> > >>> > Doesn't this argument apply for other decoders as well? Whatever is done >>> should not make the output of decoders harder for the diagnostic users of >>> tcpdump to interpret, or unnecessarily change the output format. >>> >>> The factor of consistency does indeed apply, and some decoders use UTC >>> already, whilst some others seem to use local time and to fail the tests >>> from time to time. >> >>> Which reminds us that at the end of the day somebody will need to fix the >>> AFS test, whatever is the consensus. >> >> With the rx packet (#4 in the file) showing the problem, in the current >> printing (CEST), >> the capture time is '23:46:24' and the StoreStatus date is '22:46:24'. >> difference -1 hour. >> And with TZ=GMT0, >> The capture time is '21:46:24' (-2: OK) and the StoreStatus date is >> '21:46:24' (-1). same. >> >> Does anyone understand why? >> --- >> $ ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' >> reading from file tests/afs.pcap, link-type EN10MB (Ethernet) >> 4 1999-11-11 23:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, >> flags [none], proto UDP >> (17), length 108) >> 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call >> makedir fid 536871098/1/1 >> "tmpdir" StoreStatus date 1999/11/11 22:46:24 group 0 mode 755 (80) >> --- >> $ TZ=GMT0 ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' >> reading from file tests/afs.pcap, link-type EN10MB (Ethernet) >> 4 1999-11-11 21:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, >> flags [none], proto UDP >> (17), length 108) >> 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call >> makedir fid 536871098/1/1 >> "tmpdir" StoreStatus date 1999/11/11 21:46:24 group 0 mode 755 (80) > > Perhaps a 'Daylight saving time' reason ... Not sure. Seems a need to reworking printing time in util-print.c. I am looking at it. -- Francois-Xavier ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On 06/08/2018 17:17, Francois-Xavier Le Bail wrote: > On 06/08/2018 15:09, Francois-Xavier Le Bail wrote: >> On 06/08/2018 14:52, Francois-Xavier Le Bail wrote: >>> On 06/08/2018 10:42, Denis Ovsienko wrote: On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson wrote > Denis Ovsienko wrote on Sun, 5 Aug 2018 > at 17:05:20 +0100 in <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>: > > I understand what you are suggesting, and your description is > > correct, but it does not solve the problem of interpreting tcpdump > > output correctly in a place or time different from the > > original. That said, I can live with print-rx.c using local time and > > being imperfect, it has worked like this many years. Still, I think > > local time should not be the norm for other decoders. > > Doesn't this argument apply for other decoders as well? Whatever is done should not make the output of decoders harder for the diagnostic users of tcpdump to interpret, or unnecessarily change the output format. The factor of consistency does indeed apply, and some decoders use UTC already, whilst some others seem to use local time and to fail the tests from time to time. >>> Which reminds us that at the end of the day somebody will need to fix the AFS test, whatever is the consensus. >>> >>> With the rx packet (#4 in the file) showing the problem, in the current >>> printing (CEST), >>> the capture time is '23:46:24' and the StoreStatus date is '22:46:24'. >>> difference -1 hour. >>> And with TZ=GMT0, >>> The capture time is '21:46:24' (-2: OK) and the StoreStatus date is >>> '21:46:24' (-1). same. >>> >>> Does anyone understand why? >>> --- >>> $ ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' >>> reading from file tests/afs.pcap, link-type EN10MB (Ethernet) >>> 4 1999-11-11 23:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, >>> flags [none], proto UDP >>> (17), length 108) >>> 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call >>> makedir fid 536871098/1/1 >>> "tmpdir" StoreStatus date 1999/11/11 22:46:24 group 0 mode 755 (80) >>> --- >>> $ TZ=GMT0 ./tcpdump -#nv -r tests/afs.pcap|grep -B1 'StoreStatus date' >>> reading from file tests/afs.pcap, link-type EN10MB (Ethernet) >>> 4 1999-11-11 21:46:24.151512 IP (tos 0x0, ttl 64, id 57928, offset 0, >>> flags [none], proto UDP >>> (17), length 108) >>> 131.151.32.21.7001 > 131.151.1.59.7000: rx data seq 1 ser 433 fs call >>> makedir fid 536871098/1/1 >>> "tmpdir" StoreStatus date 1999/11/11 21:46:24 group 0 mode 755 (80) >> >> Perhaps a 'Daylight saving time' reason ... Not sure. > > Seems a need to reworking printing time in util-print.c. I am looking at it. Daylight saving time problem confirmed. Update needed. I am working on it. -- Francois-Xavier ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
