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
Npcap: arp packet sent to myself cannot be responsed #116
Comments
I'm going to give my best guess as to why this is the case, but maybe @hsluoyz can comment on whether I am correct. Loopback traffic is IP (network layer) only, and does not use Ethernet as a link layer. ARP is a link-layer protocol used to resolve network (IP) addresses. While older Npcap releases used a fake Ethernet header for injected and received Loopback packets, newer ones default to a BSD-style NULL link header to make this more clear; the only information accepted from this header is the network protocol number (0x2 = IPv4 or 0x18 = IPv6). Because of the way Windows treats IP traffic for any configured network address as loopback traffic, it is not possible to send an ARP request or response to yourself. |
I'm curious that why WinPcap works. Neither of WinPcap and Npcap handles ARP loopback traffic specially. WinPcap is a NDIS 5 Protocol driver, Npcap is a NDIS 6 Filter driver. This may be the point. I can think of several ways to solve it:
|
Hi all. I have a similar topic. We have a user mode tcp/ip stack and an virtual network interface implemented as a miniport driver. On the local machine we do a windows command line "ping" to the user mode tcp/ip stack and it replies with wpcap. With npcap the ping doesn´t reply. In wireshark i see the arp request and the arp response send by our user mode tcp/ip stack. But after response the windows arp table didn´t have an entry for the requested ip address. It seems that the injected arp packet doesn´t send to the upper windows protocol layers by npcap. Is my assumption correct? Thanks in advantage. |
Ok, the essential problem here is that you want to inject traffic with Npcap (using To use the feature, create a The downsides to this approach are that it affects every process on the system that wants to use Npcap. There will be no way for Npcap to inject traffic outbound on that adapter, though regular socket calls will work as usual. We are looking into options for making this easier to use in the future, with a way to specify per-packet or per-pcap-handle the direction that injected packets should go. For now, I will be documenting SendToRx and a related feature, BlockRx, in the Npcap Guide, since they are not currently documented. |
Thanks four your response. |
As you described SendToRX doesn't seem to meet our needs or behave like WinPcap did. As I described in nmap/nmap#1929, we need the traffic produced by pcap_sendpacket() to BOTH make it to the physical wire and to be received into the host system network stack, AND also be received by any additional pcap sessions on the same machine/interface if those connections are in promiscuous mode. Like @rbeex's situation, our application needs to send some traffic to the host and other traffic to other systems on the LAN and possibly beyond. We would be comfortable if the distinguishing factor was that packets directed to the current host interface's MAC address went only to the host network stack, and AND broadcast and multicast packets went both to the host and the wire. Note: The subject of this issue isn't correct. Surely, most IP based conversations will begin with an ARP, but if a static ARP entry exists, the ARP request/reply can be skipped and other conversation potentially exchanged. This same behavior is observed without regard to the type of the traffic. I would suggest something like "Packets sent with pcap_sendpacket() are not received by the Windows network stack, WinPcap's packets are." |
…ring Current versions of Npcap can talk directly to the host system's network stack. This defect was just discovered. Fortunately, WinPcap 4.1.3 works as needed and is still functional on Windows 10. As discussed in nmap/nmap#1929 and nmap/nmap#1343
- Npcap is not currently a superset of WinPcap. Specifically it doesn't allow traffic from simulators to the host system to be received by the host system network stack. As discussed in nmap/nmap#1929 and nmap/nmap#1343
Given the long lifetime of this issue with nothing really addressing the problem, has anyone found alternatives to using npcap to send Ethernet frames that both the host and the LAN can see? Is there something in another project or a Microsoft facility that can be leveraged (i.e. Qemu and VirtualBox manage to do these types of things, as does HyperV)? |
Hello markpizz. We are working on a solution and we will provide it as a pull request here estimated in this month. Best regards. |
Hello together, my colleague mark has send a pull request to provide a solution regarding this issue. On sending, the NDIS-Send-Flag "NDIS_SEND_FLAGS_CHECK_FOR_LOOPBACK" is now passed to the function "NdisFSendNetBufferLists". With this flag, NDIS does all and exactly what is needed to be WinPcap compatible. We have tested this under different scenarios. This behavior is now the standard behavior. For backward compatibility, we introduce new flags for the function "PacketSetLoopbackBehavior". With "NPF_DISABLE_LOOPBACK_RX" you can enable the old behavior. With "NPF_ENABLE_LOOPBACK_RX" you can reenable the new WinPcap compatible behavior. Best regards |
Can someone please build the windows 64 bit and 32 bit installer with mmueller-projektantrieb fix. I spent a couple of hours today trying to get it to work but there are no instructions for us plebes. I finally got the packetWin7 projects to compile but I don't know where to go from there. |
Npcap 0.9990, released on Friday, should correct this behavior. We recommend that code relying on loopback of injected packets explicitly call |
Version of Npcap 0.9990 restores full WinPcap functionality As discussed in nmap/nmap#1929 and nmap/nmap#1343
The changes work as expected so far. |
Hello there,
I am using npcap for sending raw ethernet packets, but I've found there are some problems when I send an ARP response to myself. I ping a specific IP address in my computer and my computer send a broadcast arp request. And then I construct a fake arp response packet from my computer and send it to myself. I can see from wireshark that the packet has been sent but my computer seems not receiving that packet and are still sending arp requests. I have tried to send arp request from another computer and reply arp response from my computer, and it works. I do the same thing with winpcap and it works too.
Is this a bug or a feature that I cannot send packet to myself? Are there any solution?
My npcap version is 0.99-r7 and my os is win10 build 10.0.17134.320
Thanks a lot.
The text was updated successfully, but these errors were encountered: