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 <jh...@mit.edu> >>> wrote ---- >>> > Denis Ovsienko <de...@ovsienko.info> 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 -#ttttnv -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 -#ttttnv -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