nmap
Upstream new (upcoming) nanosecond precision feature to mainline libpcap
Mainline libpcap has a portable way to determine available timestamp precisions and use them, but nanosecond precision hasn't been supported on Windows until now. The upcoming Npcap 1.83 will contain this ability through a new PACKET_MODE_NANO pcap_setmode feature, and we will neeed to upstream small changes to libpcap so it can utilize this in its more portable API calls. Until then, Npcap users will have to use the Npcap-specific pcap_setmode directly.
Until then, Npcap users will have to use the Npcap-specific pcap_setmode directly.
Or indicate how this works and either 1) I can write the code and check in the code to the main and 1.10 branches of the libpcap library, and you could then apply that change to the Npcap copy and test it or 2) you could make the change and test it and then make a pull request for libpcap. That way 1.83 will support it, and tcpdump, at least, will support it.
It turns out that the code in Wireshark that automatically selects nanosecond mode if it's available is in a file that's only used for UN*X, so that'll require changes to support it - i.e., you won't be able to test this with Wireshark, just with tcpdump, where it's the -j command-line option. I'll look at fixing that and backporting it to the Wireshark 4.4 branch, so the next 4.4.x release will support it on Windows.
Thanks @guyharris . We love how well you support libpcap and tcpdump! We have to do the 1.83 release imminently for unrelated reasons, so that's why we were only able to put in the driver portion of the code at first. But having it in the driver will make it easier for us and others to test and add higher level support (like the Npcap SDK and libpcap).
Also, thanks for the Wireshark details and your help with that!
Thanks @guyharris . We love how well you support libpcap and tcpdump! We have to do the 1.83 release imminently for unrelated reasons, so that's why we were only able to put in the driver portion of the code at first. But having it in the driver will make it easier for us and others to test and add higher level support (like the Npcap SDK and libpcap).
OK, so maybe libpcap API support can wait for 1.84.
The pcap-npf.c code can probably check whether PACKET_MODE_NANO is defined with an #ifdef so that it'll compile with the old or new SDK. Presumably setting that mode involves just calling PacketSetMode() with a value that has PACKET_MODE_NANO set in the argument. I'll look at that, to try to get it into the next 1.10.x release. (That release should have a bunch of other fixes, some generic and some platform-specific ones for various UN*Xes.)
Also, thanks for the Wireshark details and your help with that!
After re-checking the code it looks as if Wireshark should set nanosecond-mode on Windows "out of the box", so it doesn't look as if any changes are needed. Tcpdump requires the command-line argument, but that should also Just Work as well.
I've checked in some code that should work; it compiles with PACKET_MODE_NANO defined and with it not defined.
It's the-tcpdump-group/libpcap@55ee807c9a8718766a8359a2a0e7d6f7170ac9d0, if you want to try it.
I've checked in some code that should work; it compiles with
PACKET_MODE_NANOdefined and with it not defined.It's the-tcpdump-group/libpcap@55ee807, if you want to try it.
You also want the-tcpdump-group/libpcap@ea3853cb0d3818cce9d87d0346cbcf916af314e4 and the-tcpdump-group/libpcap@b1fe28dce73d27002b49722164f14237b2ae2d19.
I d/l npcap ver. 18.83 and rebuilt libpcap + tcpdump with recent changes. This nano-second resolution seem very coarse.
Or limited to the normal Windows resolution of 100 nsec units; windump.exe -ni6 --nano -c 10:
windump.exe: verbose output suppressed, use -v[v]... for full protocol decode
listening on \Device\NPF_{6568F487-0016-453C-8C29-5C28DEDF27A0}, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:42:16.654951100 IP 10.0.0.26.63116 > 10.0.0.10.8080: Flags [S], seq 798158699, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:42:17.218845700 IP 10.0.0.183 > 239.255.255.250: igmp v2 report 239.255.255.250
11:42:18.762485700 IP 10.0.0.10 > 224.0.0.251: igmp v2 report 224.0.0.251
11:42:19.800039100 IP 10.0.0.1 > 224.0.0.2: igmp v2 report 224.0.0.2
11:42:20.200606100 IP 10.0.0.10.55056 > 34.54.88.138.443: Flags [P.], seq 2831123344:2831123625, ack 894951398, win 1025, length 281
11:42:20.200623100 IP 10.0.0.10.55056 > 34.54.88.138.443: Flags [P.], seq 281:508, ack 1, win 1025, length 227
11:42:20.224411900 IP 34.54.88.138.443 > 10.0.0.10.55056: Flags [.], ack 281, win 1049, length 0
11:42:20.224450400 IP 34.54.88.138.443 > 10.0.0.10.55056: Flags [.], ack 508, win 1049, length 0
11:42:20.520118400 IP 10.0.0.1 > 224.0.0.252: igmp v2 report 224.0.0.252
11:42:20.592099300 IP 34.54.88.138.443 > 10.0.0.10.55056: Flags [P.], seq 1:410, ack 508, win 1050, length 409
10 packets captured
10 packets received by filter
0 packets dropped by kernel
Or limited to the normal Windows resolution of 100 nsec units
I think that's all that the Npcap driver can ket from the NT executive. Providing an indication of that and saving it in a capture file would require either an additional magic number for pcap (and changes to tcpdump/Wireshark/etc. to read that) or a new pcapng-oriented API to fully support reading and writing pcapng and thus to indicating the .1 microsecond resolution.