Version 1.76 messing up packets orders

[joezhouchenye]

Describe the bug
I am sending packets with a frame counter in the data field and using Wireshark to capture these packets. Everything is fine with version 1.75 (tested on another computer) and the default version 1.71 installed by Wireshark 4.0.7.

The packets' frame counter for example should be in order like 00, 01, 02, 03, ... 0f. However, with version 1.76, the packets are in the wrong order like 0f, 0e, 0d, 0c, ..., 03, 02, 01, 00 or 02, 01, 00, 0f, 0d, 0e, ..., 03 or sometimes just more messed up.

The Identification in the IP header also behaves in the same wrong way.

To Reproduce
Use the latest 1.76 version

Expected behavior
Packets should be in order.

Diagnostic information

• Windows 10 Version 21H2, OS Build 19044.3031)

[guyharris]

The Identification in the IP header also behaves in the same wrong way.

Your program is supplying that number - pcap_inject() and pcap_sendpacket() don't generate IP headers (and, in general, don't even generate link-layer headers) - so it's not surprising or noteworthy that the frame counter in the data field (which you supply) and the IP identification field (which you supply) both indicate the same form of out-of-order delivery.

[joezhouchenye]

No, I am not using pcap_inject or anything like that. I am sending packets from FPGA. I can verify using Wireshark with libpcap on Linux and wireshark with npcap of older versions that my packets are correct. So, the packets should be in order and it is a problem with version 1.76.

[guyharris]

No, I am not using pcap_inject or anything like that. I am sending packets from FPGA.

OK, so this is a problem when Npcap receives packets, not a problem where Npcap sends packets out of order (which might not be under the control of Npcap or of any UN*X packet capture/injection mechanism).

I can verify using Wireshark with libpcap on Linux and wireshark with npcap of older versions that my packets are correct.

I.e., the packets are delivered to Wireshark in the order that they were put onto the network if you capture on Linux (meaning the Linux drivers and networking stack, including PF_PACKET sockets, is doing the capturing) or if you capture on Windows with Npcap 1.75 (meaning the NDIS driver and stack, and the 1.75 NPF driver, are doing the capturing), but they're not delivered in that order with Npcap 1.76 (meaning the NDIS driver and stack, and the 1.75 NPF driver, are doing the capturing)?

[joezhouchenye]

Yes, that's the case.

I even did a clean reinstall of Windows and installed just the driver for Intel X710 DA4, Npcap 1.76, and Wireshark 4.0.7. The packets are in the wrong order. I uninstalled Npcap and Wireshark and then reinstall Wireshark which offers to install Npcap version 1.71. Recaptured packets with Wireshark are in order now.

[nachume]

I uninstalled Npcap and Wireshark and then reinstall Wireshark which offers to install Npcap version 1.71.

works for me.

[njk42]

I also upgraded from v1.75 to v1.76 and an application that I'm using (which depends on packets being received in order by pcap) started failing. Rolled back to v1.75 and it worked again. I haven't visually confirmed that this is explicitly an ordering issue by inspecting packets at the pcap API level, but it's consistent with @joezhouchenye observation. I'm on Windows 10 Pro (build 19041).

[dmiller-nmap]

Npcap 1.76 changed the order of some operations in the driver for more efficiency, with the side effect that a set of NET_BUFFER_LISTS received by the driver in a single indication would be stored in reverse order. I've just pushed a change to preserve the ordering.

[chrullrich]

Question: I'm seeing a very similar behavior capturing with Wireshark and npcap 1.76. Whenever the network is getting busy, groups of packets (I have seen between three and ten) show up in reverse order. There is another symptom not mentioned above; all packets in these groups have the same timestamp:

This is, of course, physically impossible on a GbE network, so I'm wondering if it is an effect of the same bug or if something else may be going on.