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 <[EMAIL PROTECTED]> 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 > > ===== > > [EMAIL PROTECTED]:~/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 > [EMAIL PROTECTED]:~/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 > [EMAIL PROTECTED]:~/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@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
