Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong timestamp with pcapng file #577

Closed
ghost opened this issue May 10, 2017 · 5 comments
Closed

Wrong timestamp with pcapng file #577

ghost opened this issue May 10, 2017 · 5 comments

Comments

@ghost
Copy link

ghost commented May 10, 2017

Following the closed issue #527 (#527), when using certain type of pcapng files, libpcap returns wrong timestamps as shown below:

printf("%ld:%ld (%ld)\n", header->ts.tv_sec, header->ts.tv_usec, header->len);
prints:
-1083806075:0 (558)

In the issue #527 the solution proposed is to change the Snaplen, I have tried with this Profishark files (changed Snaplen from FF FF FF FF to 00 00 04 00), but still happens the same, I keep getting a wrong timestamp.

Could you please check what is wrong with this type of files?
I am trying to attach the .pcapng file but GitHub doesnt support it, also tried with .zip but same problem. Can you provide me a mail address to send you the problematic file?

Thanks in advance!

@guyharris
Copy link
Member

guyharris commented May 14, 2017

There is no reason to believe that changing the snaplen would make any difference whatsoever would make any difference to the interpretation of time stamps; the suggestion that the snaplen be changed was made because libpcap was complaining about the snaplen.

What version of libpcap are you using?

@ghost
Copy link
Author

ghost commented May 15, 2017

Currently we are using libpcap 1.7.4 .

We have been forced to modify the timestamp interpretation. It means changing the "if_tsresol" option from the interface header . We have substituted the Most Significant Bit of "if_tsresol" (from 1 to 0) and changed the timestamps format according to documentation:

"Resolution of timestamps. If the Most Significant Bit is equal to zero, the remaining bits indicates the resolution of the timestamp as as a negative power of 10 (e.g. 6 means microsecond resolution, timestamps are the number of microseconds since 1/1/1970). If the Most Significant Bit is equal to one, the remaining bits indicates the resolution as as negative power of 2 (e.g. 10 means 1/1024 of second). If this option is not present, a resolution of 10^-6 is assumed (i.e. timestamps have the same resolution of the standard 'libpcap' timestamps)."

But still I don't get to understand why our format didn't work, it seemed to be correct according to documentation. If you provide me an email address I can send you the file.

Thanks in advance!

@guyharris
Copy link
Member

Currently we are using libpcap 1.7.4 .

Try using libpcap 1.8.1; that's the latest version, and has fixes to the handling of time stamps.

@guyharris
Copy link
Member

If you provide me an email address I can send you the file.

guy@alum.mit.edu

@mcr
Copy link
Member

mcr commented Apr 18, 2019

If there is still a timestamp issue with libpcap 1.9.x please re-open this issue.

@mcr mcr closed this as completed Apr 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants