This may be what is happening with:
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1158
I'm waiting for the reporter's answer to verify that anyway I'll try
to set starttm.tm_isdst to -1 and see whether it works .
Luis
On 10/18/06, Tim Furlong <furlong@xxxxxxxxxxxxxxxx> wrote:
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
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
