Improve nanosecond precision support for pcap

[egecetin]

Instead of compile time constant definitions use pcap_get_tstamp_precision() to detect timestamp precision which introduced with libpcap 1.5.1

This should also fix #906

• Update pcap open functions to control precision
• Add arguments to specify desired precision
• Keep backward compatibility since original Winpcap does not support nanosecond precision
• Manually (or with CI) test different precisions for pcap/pcapng files
  • Read Microseconds -> Write Microseconds
  • Read Microseconds -> Write Nanoseconds
  • Read Nanoseconds -> Write Microseconds
  • Read Nanoseconds -> Write Nanoseconds

[egecetin]

This is Visual Studio generated file to hold configuration when remote compilation (ssh/wsl etc) requested or modify build mode from UI

[egecetin]

Manually tested, it looks like it works for pcap files. Can you also test before merging for different precisions?

[seladb]

@egecetin why can't we write tests for it? 🤔

[egecetin]

@seladb If i can figure out a test flow yes, it is possible 😀. One way I'm thinking.

• Craft two RawPackets with one microsecond and one nanosecond precision
• Write both of them to two pcap files with one opened with microsecond and the other nanosecond
• Read these files
• Compare the timestamp headers of read packets with crafted ones. Microsecond precision should truncate, nanosecond should persist.

If I'm right only missed part with this flow, if somehow, I write mathematically inverse operations in write and read only the pcap file itself will be wrong but all other cases should be covered right? 🤔

[seladb]

@seladb If i can figure out a test flow yes, it is possible 😀. One way I'm thinking.

* Craft two `RawPacket`s with one microsecond and one nanosecond precision

* Write both of them to two `pcap` files with one opened with microsecond and the other nanosecond

* Read these files

* Compare the timestamp headers of read packets with crafted ones. Microsecond precision should truncate, nanosecond should persist.

If I'm right only missed part with this flow, if somehow, I write mathematically inverse operations in write and read only the pcap file itself will be wrong but all other cases should be covered right? 🤔

Yes, I think it's a valid test that mostly covers what is mentioned in the ticket: #906 (comment)
You can even extend the test a bit more:

• Craft two RawPackets with one microsecond and one nanosecond precision
• Write both of them to two pcap files with one opened with microsecond and the other nanosecond
• Read both files in 2 ways:
  1. Read microsecond file with microsecond precision
  2. Read microsecond file with nanosecond precision
  3. Read nanosecond file with microsecond precision
  4. Read nanosecond file with nanosecond precision
• Make sure you get the expected result in each case:
  1. crafted packet timestamp == read packet timestamp
  2. crafted packet timestamp * 1000 == read packet timestamp
  3. crafted packet timestamp / 1000 == read packet timestamp
  4. crafted packet timestamp == read packet timestamp

[egecetin]

Actually, for the reading side there is no option implemented. It always uses as much high as precision always. So only WinPcap will use microsecond, and all other systems/tests will use nanosecond for reading mode. So, I added a function isTimestampPrecisionNanoSupported to check compiled binary supports the nano precision.

[egecetin]

@seladb It is ready to review again

[egecetin]

@seladb Probably I addressed all your comments. Can you review it again when you have time?

[seladb]

For better test coverage, maybe we can add tests for this method?

It'll actually be interesting to test it before opening the file and after opening it

[seladb]

You only added tests for PcapFileWriterDevice::getTimestampPrecision() but not for PcapFileReaderDevice::getTimestampPrecision()...

[egecetin]

@seladb libpcap scales precision because of pcap_open_offline_with_tstamp_precision behaviour. So, I added a test and updated comments of reader function. Can you take a look again before merging for anything i missed?

https://www.tcpdump.org/manpages/pcap_open_offline.3pcap.html

pcap_open_offline_with_tstamp_precision() takes an additional precision argument specifying the time stamp precision desired; if PCAP_TSTAMP_PRECISION_MICRO is specified, packet time stamps will be supplied in seconds and microseconds, and if PCAP_TSTAMP_PRECISION_NANO is specified, packet time stamps will be supplied in seconds and nanoseconds. If the time stamps in the file do not have the same precision as the requested precision, they will be scaled up or down as necessary before being supplied.

[seladb]

Please see this last comment: #1368 (comment)

Can you fix it before merging?