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
Version 1.76 messing up packets orders #684
Comments
Your program is supplying that number - |
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. |
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.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)? |
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. |
works for me. |
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). |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: