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

Add if_tsoffset_ns option to IDB #161

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

GioMusto
Copy link

@GioMusto GioMusto commented Jul 8, 2024

This new option allows having a grater precision in the timestamp offset of packets.

@guyharris
Copy link
Collaborator

So, in effect, the rules are:

  1. initialize a pair consisting of a 64-bit seconds value and a 32-bit nanoseconds value to {0, 0};
  2. if there's a ts_offset option, set the seconds value to the option's value;
  3. if there's a ts_nsoffset option, set the nanoseconds value to the option's value;
  4. for all packet from this interface, add the resulting seconds/nanoseconsds value to each time stamp.

What should be done if the time stamp resolution for this interface isn't 1 nanosecond? For example, what if it only has microsecond resolution?

An alternative would be to have an offset option that's a 64-bit value, with the same resolution as interface time stamps on the interface; you'd just add that value to the time stamp in a packet block; that seems a bit less complicated. The ts_offset value, if any, would be an additional offset to add, after the 64-bit offset is added.

(Having ts_offset be in seconds would provide a way to keep the pcapng file format usable for microsecond-resolution time stamps even after 2^63-1 microseconds (about 292271 years), usable for nanosecond-resolution time stamps even after 2^63-1 nanoseconds (about 292 years) and, if we ever need picosecond-resolution time stamps, even after 2^63-1 picoseconds (about .29 years).)

@GioMusto
Copy link
Author

GioMusto commented Jul 8, 2024

I also thought about the second option (having a separate 64-bit value), but I didn't like it because it provided potential overlap between the two options (i.e. multiple ways of expressing the same offset), but I agree it would provide more flexibility.

For that to work, we should still define a default precision in case there's no if_tsresol option. Also, is it ok having an option depending on another one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants