I have a pcap file with nanosecond timestamps. I have used a hex editor to make sure the magic number in the header is correct, and Wireshark does interpret the timestamps correctly. I run the following command to convert it to pcapng:
And editcap writes out a file with only microsecond resolution. This is concerning, because several tools that rely on WinPcap incorrectly interpret nanosecond timestamps as microsecond -- which leads to out of order packets downstream -- and I was concerned editcap might be doing the same thing. Out of curiosity, I tried the following command, to see what would happen:
And as output, got a pcap with nanosecond timestamps! I am hoping someone can explain what is going on here. Are there essentially two "errors" dealing with nanosecond pcaps that are cancelling each other out in the 2nd case (i.e. keeps the ts_usec field is kept unaltered in the process)? In the first case, is it interpreting the ts_usec field correctly and truncating, or is it interpreting it as microsecond and timestamps will be inaccurate? Does editcap use winpcap at all? asked 23 Jun '15, 14:04 Chuu edited 23 Jun '15, 14:25 |
One Answer:
Editcap does not WinPcap. Instead it has its own code to handle the various formats conversion. As you noticed, right now pcapng export only supports the default microseconds timestamp but it properly truncates the value so you do not have any corruption (as Wireshark stores all timestamps internally with nano seconds definition by default). Edit: I'm adding the ability to keep nanosecond timestamp resolution when converting to pcapng format in Wireshark 1.99.8. The corresponding review can be found here: https://code.wireshark.org/review/#/c/9111/ answered 24 Jun '15, 15:28 Pascal Quantin edited 24 Jun '15, 17:13 |