This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Editcap timeshift error

0

I am trying to shift the time of a set of pcap files by -112934478 seconds. The thing is for some files it shifts the times correctly, but others its off by an hour. I'm wondering if this is a bug or if theres possibly something I'm doing wrong. Heres a few examples of what I'm talking about.

The command I'm using: /usr/sbin/editcap -F pcap -t -112934478 <inputfile.pcap> <outputfile.pcap>

Example 1- Fail

Original Time: 2008-09-13 7:29:29

Expected Time: 2005-02-14 4:48:11

Result from Shift: 2005-02-14 3:48:11

Example 2 - Success

Original Time: 2013-04-16 13:10:11

Expected Time: 2009-09-17 10:28:53

Result from Shift: 2009-09-17 10:28:53

Example 3 - Fail

Original Time: 2007-12-11 8:58:25

Expected Time: 2004-05-13 6:17:7

Result from Shift: 2004-05-13 7:17:7

asked 24 Apr '15, 12:59

drowningincode's gravatar image

drowningincode
11114
accept rate: 0%


2 Answers:

2

In what timezone are you? It looks like example 1 is going from "Summer time" to "Winter time", example 2 is going from "Summer time" to "Summer time" and example 3 is going from "Winter time" to "Summer time".

Did you take daylight saving into account?

answered 25 Apr '15, 06:46

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

I'm in the Eastern Time Zone. Is there a way to force editcap to deal with daylight savings time or do I have to deal with it on my end.

(27 Apr '15, 11:26) drowningincode

All timestamps in the pcap[-ng] files are stored in UTC format. This means the actual timestamps in the tracefiles are agnostic to daylight saving corrections. It is when displaying the timestamps that your local timezone is used to make sure the time displayed in wireshark is the same as the time on your wall-clock (at the time).

So, editcap really does not care about daylight savings, it just follows your instruction to add/substract a certain amount of seconds. If you need the result to be an exact wall-clock time for your timezone, you need to take the daylight saving into account yourself.

(28 Apr '15, 04:13) SYN-bit ♦♦

I wrote a blog post about packet/frame time stamps here, if anyone is interested:

https://blog.packet-foo.com/2015/04/deep-dive-frame-timestamps/

(28 Apr '15, 06:28) Jasper ♦♦

Thank You so much, I was convinced that the problem was in editcap but I know when to admit that I was wrong. Turns out I just needed capinfos to return times in seconds since epoch instead of how it was doing it.

(28 Apr '15, 11:25) drowningincode

0

Although the usage is a bit odd, I guess this should work. It would be worth a bug report.

answered 25 Apr '15, 05:46

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

What is odd about the usage?

(27 Apr '15, 11:27) drowningincode

Offsetting timestamps a few years(!). I could imagine a couple of minutes in case of comparing captures from platforms with misaligned clocks.

Anyway, Sake got you on the right track I think.

(28 Apr '15, 09:12) Jaap ♦