Skip to content
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

Closed
ZacharyJia opened this issue Oct 6, 2018 · 12 comments
Closed

Npcap: arp packet sent to myself cannot be responsed #116

ZacharyJia opened this issue Oct 6, 2018 · 12 comments

Comments

@ZacharyJia
Copy link

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.

@ZacharyJia ZacharyJia changed the title Npcap: send arp packet to myself cannot be responsed Npcap: arp packet sent to myself cannot be responsed Oct 6, 2018
@dmiller-nmap
Copy link
Contributor

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.

@hsluoyz
Copy link
Member

hsluoyz commented Oct 7, 2018

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:

  1. Adjust the layer of Npcap filter driver. Maybe in a suitable layer, Npcap can work like WinPcap. Here to adjust:

    HKR, Ndi,FilterClass,, ms_medium_converter_128

  2. Add a new data-link layer WFP callout mechanism to capture/send ARP loopback traffic, just like how IP loopback is handled now. But it requires certain development.

@rbeex
Copy link

rbeex commented Apr 2, 2019

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.

@dmiller-nmap
Copy link
Contributor

Ok, the essential problem here is that you want to inject traffic with Npcap (using pcap_inject() or pcap_sendpacket()) as though it was received on that adapter, not transmitted from that adapter. Ordinarily, packets injected with Npcap travel down the stack towards the network adapter and out to the network. However, Npcap does have a feature which allows you to inject packets back up the stack instead. The feature is called SendToRx, and it is described in this mailing list message from 2016, though some minor things have changed since then.

To use the feature, create a REG_SZ value named SendToRx in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters\. In the value, put the device name of the adapter you want to use for receive injection. For instance, if pcap_findalldevs() returns "\Device\NPF_{4E273621-5161-46C8-895A-48D0E52A0B83}", then the value should be "\Device{4E273621-5161-46C8-895A-48D0E52A0B83}". Then restart the "npcap" service. All packets injected on that interface will be sent up the receive side of the stack.

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.

@rbeex
Copy link

rbeex commented Jan 10, 2020

Thanks four your response.
What i had not described in my question on 02.04.2019, i must respond to ARP requests from local- and remote machines. I assume: If i would use "SendToRx", i can only response to requests from local machines, not from remote machines. Is my assumption correct?

@markpizz
Copy link

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."

markpizz referenced this issue in simh/simh Feb 19, 2020
…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
markpizz referenced this issue in simh/simh Feb 23, 2020
- 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
@markpizz
Copy link

markpizz commented Mar 8, 2020

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)?

@rbeex
Copy link

rbeex commented Mar 9, 2020

Hello markpizz. We are working on a solution and we will provide it as a pull request here estimated in this month. Best regards.

@rbeex
Copy link

rbeex commented Mar 16, 2020

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

@j3nks
Copy link

j3nks commented Mar 18, 2020

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.

@dmiller-nmap
Copy link
Contributor

dmiller-nmap commented Apr 6, 2020

Npcap 0.9990, released on Friday, should correct this behavior. We recommend that code relying on loopback of injected packets explicitly call PacketSetLoopbackBehavior(NPF_ENABLE_LOOPBACK) in case the default should change in a future release.

markpizz referenced this issue in simh/simh Apr 11, 2020
Version of Npcap 0.9990 restores full WinPcap functionality

As discussed in nmap/nmap#1929 and nmap/nmap#1343
@DarkDarro
Copy link

The changes work as expected so far.
Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants