Hi folks,
I've run into a bit of an annoying date issue using the editcap utility
compiled with gcc. I'm in Ontario, so EST/EDT; I'm using gcc
3.3.5 on Debian stable (3.1 sarge). When I specify a date that is
in the range for daylight savings time, it is interpreted as EST and
then mktime converts it to an EDT value, effectively adding an hour, so
that e.g. to select packets in a pcap that are recorded as 2000-07-09
20:00:00 (as displayed by wireshark or capinfos), I have to use -A
"2000-07-09 19:00:00" -B "2000-07-09 19:00:00". One solution that
would allow a user to specify the time such that it would match the
timestamps displayed by wireshark or capinfos would be to set
starttm.tm_isdst to -1 when parsing the options, as that would tell
mktime that daylight savings is unspecified, so that it would interpret
it by looking at timezone info; currently that value is 0, which tells
mktime, in my case, that "This timestamp is in EST, not EDT, regardless
of the date". Alternately, it would be nice if one could include
the timezone abbreviation in the datestring, just to be explicit; I
think that's supported by %Z for the GNU strptime function, but would
probably require more work for the BSD version. I've got my own
workarounds for the issue (i.e. giving editcap a time that's one less
than what I want if it's during DST :p), but I figured someone might
want to take a look at this issue.
I've included a dump below that shows me extracting one second from a
pcap file as described above; the original traffic was captured in New
Zealand (it's from the NLANR PMA project,
http://pma.nlanr.net); the
datestamps in the filename are a bit odd (the first is the datestamp of
start-of-capture in NZ local time, the second is from the datestring
passed into editcap, hence it's off by an hour as described above); I
believe the datestamps in the file were converted to EDT by coralreef,
which I used to convert from the original DAG format. None of
that is particularly crucial to the issue I've described, but I thought
I'd explain in case you found the time ranges reported by capinfos
confusing. ;-)
Please let me know if you require more information or clarification.
Thanks,
-Tim
=====
furlong@doyle:~/sandbox/pcap_timezone$ capinfos 20000710-120000.tcp21.20000709-190000.pcap
File name: 20000710-120000.tcp21.20000709-190000.pcap
File type: libpcap (tcpdump, Ethereal, etc.)
Number of packets: 3098
File size: 216884 bytes
Data size: 227941 bytes
Capture duration: 299.975533 seconds
Start time: Sun Jul 9 20:00:00 2000
End time: Sun Jul 9 20:04:59 2000
Data rate: 759.87 bytes/s
Data rate: 6078.92 bits/s
Average packet size: 73.58 bytes
furlong@doyle:~/sandbox/pcap_timezone$ editcap -A "2000-07-09 19:00:05"
-B "2000-07-09 19:00:05" 20000710-120000.tcp21.20000709-190000.pcap
test.pcap
furlong@doyle:~/sandbox/pcap_timezone$ capinfos test.pcap File name: test.pcap
File type: libpcap (tcpdump, Ethereal, etc.)
Number of packets: 20
File size: 1424 bytes
Data size: 1474 bytes
Capture duration: 0.982948 seconds
Start time: Sun Jul 9 20:00:05 2000
End time: Sun Jul 9 20:00:05 2000
Data rate: 1499.57 bytes/s
Data rate: 11996.56 bits/s
Average packet size: 73.70 bytes
