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 <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.
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
