Wireshark · Wireshark-dev: [Wireshark-dev] Question about traffic forwarding between two adapters based on WinPcap/Npcap

[Yang Luo <hsluoyb@xxxxxxxxx>]

Hi list,

This is a help request to me about traffic forwarding between two adapters based on WinPcap/Npcap. I am stuck on an issue. There're more talented minds familiar with WinPcap here, so I hope you could help.

Let me summarize the question if you don't want to see the details in the previous mails below.

There're two machines A and B. A has two adapters, a physical adapter and a virtual adapter (actually a Microsoft Loopback Adapter). B has one physical adapter which is connected with A's physical one. There's a forwarding software called UserLevelBridge. It can capture A's physical adapter's traffic and forward them to A's virtual adapter and vice versa. And PCAP_OPENFLAG_NOCAPTURE_LOCAL is set to avoid flooding. Then the result turns out to be that B can ping A's virtual adapter. I just don't understand how this could be possible in Win7?

And for his question of Win8 not working this way, I don't know if my Rx injecting means works?

Cheers,

Yang

---------- Forwarded message ----------
From: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Date: Thu, Jan 14, 2016 at 12:20 AM
Subject: RE: Use of npcap in automation system
To: 食肉大灰兔V5 <hsluoyz@xxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>, Gisle Vanem <gvanem@xxxxxxxx>

So you are saying there's no flooding and response is ok for WinPcap under win7 with that flag set? How could that be possible. In my understanding, if the flag is set, there's no response, if not, then flooding happens. There shouldn't be too much difference between win7 and win8.

 

[Ferreira] Yes, if the flag is set there is no flooding in win7 (it works perfectly). When I found this problem in 2014 I contacted Gianluca Varenni from riverbed and he was the person who told me about the limitation in windows 8, but I can assure you it works fine in Windows 7, I had made test of my application and it works fine.

You also can validate it using the UserLevelBridge in a win7 computer.

 

And I think adding injecting packets to Rx is possible in the driver. The question is how to add this interface to pcap/libpcap. I don't think it's a good idea to add a function to send Rx packets. Because I want least modification. Do you have any ideas about this?

 

[Ferreira] Actually I do not have so many knowledge about the working and the methods involved in WinPcap. I don’t think it needs to be a new function, because as you have seen in your tests with UserLevelBridge and WinPcap despite the flooding the RX messages were delivered to the virtual adapter.

Again if you make the same test in win7 or winXP you will see this happening without the flood and with all messages delivered correctly.

 

I hope this could help you.

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 13 de janeiro de 2016 16:06

To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Re: Use of npcap in automation system

 

Hi,

 

So you are saying there's no flooding and response is ok for WinPcap under win7 with that flag set? How could that be possible. In my understanding, if the flag is set, there's no response, if not, then flooding happens. There shouldn't be too much difference between win7 and win8.

 

And I think adding injecting packets to Rx is possible in the driver. The question is how to add this interface to pcap/libpcap. I don't think it's a good idea to add a function to send Rx packets. Because I want least modification. Do you have any ideas about this?

 

Cheers,

Yang

On Wednesday, January 13, 2016, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

Hi,

 

For what I’m seeing here you reproduced exactly what is happening to me.

 

I think I have reproduced it. With Npcap, wireshark can see the ARP request but no response. However, with WinPcap, despite that we can see both ARP request and response, there's also a traffic flooding. I saw 1000+ packets captured in less than 1 second. So you definitely don't want this result. In this case, the only difference between Npcap and WinPcap is the support of PCAP_OPENFLAG_NOCAPTURE_LOCAL. UserBridge.exe sets this flag in its code. And this flag only works for Npcap (WinPcap doesn't support it).

Did you encounter such flooding using WinPcap? If yes, does the flooding happen to other systems? or only Win8.

 

[Ferreira] First of all, I did found that flooding when I used WinPcap and that flooding only occurs in windows 8. The limitation is due to the fact that WinPcap uses an older NDIS driver technology (NDIS 4.0 I believe, the technology used in Win2000). On windows 8, this version of NDIS is supported only as legacy and some advanced features (like this feature exposed by WinPcap) are not supported.

 

Even if you doesn't set PCAP_OPENFLAG_NOCAPTURE_LOCAL in Npcap, you probably won't encounter the flooding. Because if PCAP_OPENFLAG_NOCAPTURE_LOCAL is not set, Npcap will not *REALLY* loopback the packets from Tx to Rx. It only presents the sent packets to upper level (like Wireshark), so the sent packets will not be seen by the adapter itself, so the adapter definitely can't respond to any packets. This is unlike WinPcap.

 

The reason of WinPcap's traffic flooding is: WinPcap has no PCAP_OPENFLAG_NOCAPTURE_LOCAL, so all packets sent will be received again. And another basis you wants to know is, there's Rx and Tx two paths for packets. WinPcap/Npcap only injects packets into Tx way. If PCAP_OPENFLAG_NOCAPTURE_LOCAL is set, the packets injected into Tx won't get loopbacked to Rx, so the adapter itself won't receive it. Let's say machine B wants to ping A.

B sends ARP request --> received by A's physical adapter --> sent by A's virtual adapter (in Tx path) because of UserBridge.exe --> received by A's virtual adapter (in Rx path) because of PCAP_OPENFLAG_NOCAPTURE_LOCAL is NOT set (HERE the request is AGAIN forwarded to A's physical adapter because of UserBridge.exe) --> A's virtual adapter responds to the ARP request --> sent by A's virtual adapter (in Tx path) --> received by A's physical adapter (in Rx) because of UserBridge.exe --> sent by A's physical adapter (in Tx) because of PCAP_OPENFLAG_NOCAPTURE_LOCAL is NOT set  --> ARP response received by B.

 

So you see, with WinPcap, you can make the communication work, but there will be flooding, because feature that all packets sent will be received again and UserBridge.exe will together form a loop. This is the working principle of WinPcap/Npcap, not a bug.

 

[Ferreira]  I notice that, that’s why I cannot use WinPcap in my application. I really net to use PCAP_OPENFLAG_NOCAPTURE_LOCAL to disable this behavior.

 

I think what you need is like this:

1. PCAP_OPENFLAG_NOCAPTURE_LOCAL is set.

2. All packets in the Rx path of A's physical adapter will be forwarded to the Rx path of A's virtual adapter.

3. All packets in the Tx path of A's virtual adapter will be forwarded to the Tx path of A's physical adapter.

.

[Ferreira] That’s exactly what I need.

 

However, there are difficulties in 2. and 3. For 2., WinPcap/Npcap can only inject packets into Tx path with PCAP_OPENFLAG_NOCAPTURE_LOCAL set, there's NO way to just send packets into Rx. For 3. You can't easily tell whether a presented packet (like shown in Wireshark) is a Rx one or Tx one. Maybe you can record the virtual adapter's MAC address, so packets with a specified source MAC address are Tx.

 

Currently I don't know if making Npcap inject packets in Rx path is possible, is there a requirement about this? 

 

[Ferreira] The difficulty you found on 3 I think is not a problem because as you say I can treat MAC addresses as I wish.

Relative to the issue number 2 that is a requirement for my application and I think that should be possible once WinPcap was making it in earlier versions of NDIS. Can you evaluate its possibility? Without it I cannot put my application to work.

 

Thank you very much

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 13 de janeiro de 2016 12:43
To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Re: Use of npcap in automation system

 

Hi Ferreira,

 

I think I have reproduced it. With Npcap, wireshark can see the ARP request but no response. However, with WinPcap, despite that we can see both ARP request and response, there's also a traffic flooding. I saw 1000+ packets captured in less than 1 second. So you definitely don't want this result. In this case, the only difference between Npcap and WinPcap is the support of PCAP_OPENFLAG_NOCAPTURE_LOCAL. UserBridge.exe sets this flag in its code. And this flag only works for Npcap (WinPcap doesn't support it).

Did you encounter such flooding using WinPcap? If yes, does the flooding happen to other systems? or only Win8.

 

Even if you doesn't set PCAP_OPENFLAG_NOCAPTURE_LOCAL in Npcap, you probably won't encounter the flooding. Because if PCAP_OPENFLAG_NOCAPTURE_LOCAL is not set, Npcap will not *REALLY* loopback the packets from Tx to Rx. It only presents the sent packets to upper level (like Wireshark), so the sent packets will not be seen by the adapter itself, so the adapter definitely can't respond to any packets. This is unlike WinPcap.

 

The reason of WinPcap's traffic flooding is: WinPcap has no PCAP_OPENFLAG_NOCAPTURE_LOCAL, so all packets sent will be received again. And another basis you wants to know is, there's Rx and Tx two paths for packets. WinPcap/Npcap only injects packets into Tx way. If PCAP_OPENFLAG_NOCAPTURE_LOCAL is set, the packets injected into Tx won't get loopbacked to Rx, so the adapter itself won't receive it. Let's say machine B wants to ping A.

B sends ARP request --> received by A's physical adapter --> sent by A's virtual adapter (in Tx path) because of UserBridge.exe --> received by A's virtual adapter (in Rx path) because of PCAP_OPENFLAG_NOCAPTURE_LOCAL is NOT set (HERE the request is AGAIN forwarded to A's physical adapter because of UserBridge.exe) --> A's virtual adapter responds to the ARP request --> sent by A's virtual adapter (in Tx path) --> received by A's physical adapter (in Rx) because of UserBridge.exe --> sent by A's physical adapter (in Tx) because of PCAP_OPENFLAG_NOCAPTURE_LOCAL is NOT set  --> ARP response received by B.

 

So you see, with WinPcap, you can make the communication work, but there will be flooding, because feature that all packets sent will be received again and UserBridge.exe will together form a loop. This is the working principle of WinPcap/Npcap, not a bug.

 

I think what you need is like this:

1. PCAP_OPENFLAG_NOCAPTURE_LOCAL is set.

2. All packets in the Rx path of A's physical adapter will be forwarded to the Rx path of A's virtual adapter.

3. All packets in the Tx path of A's virtual adapter will be forwarded to the Tx path of A's physical adapter.

 

However, there are difficulties in 2. and 3. For 2., WinPcap/Npcap can only inject packets into Tx path with PCAP_OPENFLAG_NOCAPTURE_LOCAL set, there's NO way to just send packets into Rx. For 3. You can't easily tell whether a presented packet (like shown in Wireshark) is a Rx one or Tx one. Maybe you can record the virtual adapter's MAC address, so packets with a specified source MAC address are Tx.

 

Currently I don't know if making Npcap inject packets in Rx path is possible, is there a requirement about this? 

 

 

Cheers,

Yang

 

 

On Wed, Jan 13, 2016 at 5:12 PM, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

No. Everything is all right. The problem is exactly that. If you put wireshark scanning loopback you will see packets arriving to it but no answer send away.

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 13 de janeiro de 2016 02:47

To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Re: Use of npcap in automation system

 

Hi,

 

On Tue, Jan 12, 2016 at 11:14 PM, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

I did mean “Microsoft KM-TEST Loopback Adapter”, this is my virtual interface (the interface for which I forward every packet received in the physical adapter).

 

This problem is easily reproduced with WinPcap remote example “UserLevelBridge” (http://extranet.efacec.com/inetxfer/?u=bec79a85&l=d6780e7f3dbb0f82812f1d1968143c2e&c=93872dfd). To reproduce you just need:

1.       Create a MS Loopback adapter with an IP in your subnet;

I created a loopback adapter, and gave it 192.168.0.107/24.

 

2.       Go to one of your physical adapter and disable TCP/IP v4 and v6;

My physical adapter is a Wi-Fi adapter, with IP 192.168.0.105/24 and gateway 192.168.0.1.

 

3.       Run UserBridge.exe to create a user level bridge between the two mentioned above adapters (without any filter);

 

I restarted the npf service, and in UserBridge.exe I saw the physical and loopback adapters. I specified their indice, and saw the trace info like: >> Len: 46.

 

4.       Connect your physical adapter to another computer and from that computer try to ping the MS loopback IP. With Wireshark you will see the packets arriving in that adapter but no answer sent.

 

I have VMware Workstation installed, and in it I have a virtual machine whose adapter is "Bridged" with the host. I gave it IP 192.168.0.106/24 with gateway 192.168.0.1. Before disabling TCP/IP v4 and v6 on the physical adapter, the host and the guest can ping each other. The guest can't ping 192.168.0.107 (the loopback)

 After doing all steps, the guest can neither ping 192.168.0.105 (the host) or 192.168.0.107 (the loopback). Is there something wrong with my steps?

 

Thank you for your help. If you need any help to reproduce please tell me, I’ll help whatever you need.

 

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 12 de janeiro de 2016 14:30
To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Re: Use of npcap in automation system

 

Hi Ferreira,

 

What did you mean by "the problem was in the loopback adapter"? I hope the loopback adapter doesn't mean "Npcap Loopback Adapter", because  "Npcap Loopback Adapter" is designed to discard any packets other than IPv4 and IPv6, so ARP packets will not be sent and responded. If you mean a normal "Microsoft KM-TEST Loopback Adapter" (The new name of Microsoft Loopback Adapter on Win8 and later). It should support ARP request sending on the TX path, but you can't expect a reply by the working principle of Microsoft's loopback. It's not like the "lo" adapter in Linux. BTW, what's a virtual interface? Is it the same with the loopback adapter thing? 

And it's weird that WinPcap supports your usage, what about turn off the PCAP_OPENFLAG_NOCAPTURE_LOCAL in Npcap to see what happens. And If convenient, could you provide a little working example to send such an ARP request to an interface? Executable is OK, with source then better. I want to try it by myself to see what's wrong here.

 

Cheers,

Yang

 

 

On Tue, Jan 12, 2016 at 8:06 PM, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

Hi Yang,

 

I tried that. Every time I received a packet I was putting the virtual IP and  MAC address as destination and still the problem happens.

 

Meanwhile I tried again with WinPcap 4.1.3 just to make sure the problem was in the loopback adapter and I found that with WinPcap it works (I still have the orginal problem (NOCAPTURE_LOCAL)) but I can see answers in wireshark. Why would the use of Npcap cause this behavior?

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 11 de janeiro de 2016 17:27
To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Use of npcap in automation system

 

Hi Ferreira,

 

Fortunately, I have done a similar project before. See http://www.veotax.com/visualvnc.htm. I think the problem is that your virtual interface and physical one own different Mac and ip addresses. Your virtual interface won't respond to an arp request that the dest MAC address and IP address is not itself. The solution is to manipulate the dest Address fields of the arp request from the physical interface to your virtual one.

 

Cheers,

Yang

On Tuesday, January 12, 2016, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

Dear Yang,

 

I tested this new version and it seems to be working perfectly. Now I’m having a different problem, I think it is not related with pcap but I would like to know if you can help me.

 

I’m making a test where I’m pinging the virtual interface IP, I realize that my forwarding application is working because the arp packet received in the physical interface is sent to the virtual one, but it is never responding to the arp request. I looks like that arp packet is not being passed to OS or OS is not sending the answer. Is this problem familiar to you.

 

PS: I’m using a machine with windows 8.

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 11 de janeiro de 2016 14:03
To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>
Cc: Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Re: FW: [Bulk] Use of npcap in automation system

 

Hi Ferreira,

 

It turns out to be a bug in Npcap. The adapter list will be failed to retrieve using the NPF registry way, because the call for querying OID_GEN_LINK_SPEED failed. OID_GEN_LINK_SPEED is obsolete in NDIS 6. The solution is changing this call to NDIS 6's OID_GEN_LINK_SPEED_EX (and this call is optional). So now Npcap will present the same interfaces with WinPcap 4.1.3 except the additional Npcap Loopback Adapter.

 

Please try latest 0.05 r5 installer at:

https://github.com/nmap/npcap/releases

 

 

Cheers,

Yang

 

 

On Mon, Jan 11, 2016 at 5:30 PM, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

Hi Yang,

 

Yes I mean that. In ncpa.cpl go to the wanted network interface and disable TCP/IP v4 protocol from it. I’m using already the Npcap 0.05 r4 and I can tell you this works with WinPcap 4.1.3.

 

 

Melhores Cumprimentos / Best Regards

Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit

Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363

Disclaimer

 

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx] 
Sent: 9 de janeiro de 2016 03:11
To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx>; Nmap-dev <dev@xxxxxxxx>; Gisle Vanem <gvanem@xxxxxxxx>
Subject: Re: FW: [Bulk] Use of npcap in automation system

 

Hi Ferreira,

 

What do you mean by saying "TCP/IP is not active"? You mean disabling the connection in ncpa.cpl? And does this issue occur on WinPcap 4.1.3 too or just Npcap's problem? 

And have you tried latest Npcap 0.05 r4 in https://github.com/nmap/npcap/releases?

 

 

Cheers,

Yang

 

 

 

On Fri, Jan 8, 2016 at 7:44 PM, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx> wrote:

Hi Yang,

First of all, sorry about I haven’t give you feedback since October but I was away of this project I couldn’t do any more  tests. Now I resumed it and I hope you can help me to put this to work. I’m facing a problem now because pcap_findalldevs does not list network interfaces where TCP/IP is not active. That is absolute necessary for my application because witouht that I can’t open them using pcap_open. Can you help understand why. After that I need to put my app reading and writing in raw in the respective adapters.

Here I present a diagram where you can how my app works:

[cid:image002.png@01D14A08.797F6180]

Basically the physical adapters are the Ethernet ports on my device and they are connected to the exterior network. Once the physical one is good it is responsible to receive packet from the exterior and forward to the virtual and vice versa. Once it falis physical 2 will be responsible for that task.

Melhores Cumprimentos / Best Regards
Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit
Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363
[EFA Logo]
Disclaimer<http://efacec.com/email.jpg>

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx]
Sent: 7 de outubro de 2015 09:12
To: Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx<mailto:nuno.ferreira@xxxxxxxxxx>>
Subject: Re: [Bulk] Use of npcap in automation system

Hi Ferreira,

I still didn't quite understand why I failed to reproduce this issue, but this usage corresponds to Microsoft's NDIS_FLAGS_DONT_LOOPBACK flag and it is never well documented. Whatever, this only matters with the NDIS 5's legacy, and we can forget about it.

that If I am understanding it right, you want your program not to see the packets sent out by itself, in other words, the sending program is also the receiving program right?
If yes, then you can try Npcap 0.05 version at:
https://svn.nmap.org/nmap-exp/yang/NPcap-LWF/npcap-nmap-0.05.exe
And let me know the result.

Actually, this functionality can be easily implemented by Npcap, because the three packet flowing paths: receive, other-send, self-send are totally separated in Npcap, so it's convenient to only restrict the self-send path using flag.

Remember: other softwares can still see all possible traffic, for instance, your software disabled the loopback packets using PCAP_OPENFLAGS_NOCAPTURE_LOCAL, then your software no longer sees the self-sent packets, but another software like Wireshark can still see them, because they're not "self" sent.


Cheers,
Yang


On Tue, Oct 6, 2015 at 10:24 PM, Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx<mailto:nuno.ferreira@xxxxxxxxxx>> wrote:
Hi,

My program is a kind of user space bridge. Basically I have a one physical interface (opened in promiscuous mode and PCAP_OPENFLAG_NOCAPTURE_LOCAL) bridged with one virtual. Every traffic received in the physical interface is forward to the virtual and vice-versa. I already followed the WinPcap’s mailing list and I found that after windows 8 does not support any more PCAP_OPENFLAG_NOCAPTURE_LOCAL due compatibility break with NDIS 5. As you can see in the following extract from their release notes (in bold):

Version 4.1.3, 08 mar 13
•         Added support for Windows 8 and Server 2012
•         Removed the old CACE logo
•         Bugfixes:
•         Fixed a bug in the Just-In-Time compiler for BPF filters that could cause an OS crash when dealing with specially crafted LD instructions
•         The BPF filter validation code was not properly validating division-by-zero DIV instructions.
•         Known bugs:
•         Transmitted packets are looped back on Windows 8 even when using the flag PCAP_OPENFLAGS_NOCAPTURE_LOCAL for pcap_open.
•         pcap_dump_fopen is not supported.

What I notice in my application is that all packets sent from my virtual interface no my physical are continuously looped back  putting my CPU consumption at 100%. So at this moment I’m looking for an alternative which might actually work.

Melhores Cumprimentos / Best Regards
Nuno Antonio Dias Ferreira
Unidade de Automação de Sistemas de Energia / Power System Automation Unit
Efacec Energia, Máquinas e Equipamentos Elétricos, S.A.
Phone: 229403363
[EFA Logo]
Disclaimer<http://efacec.com/email.jpg>

From: 食肉大灰兔V5 [mailto:hsluoyz@xxxxxxxxx<mailto:hsluoyz@xxxxxxxxx>]
Sent: 5 de outubro de 2015 18:03
To: Gisle Vanem <gvanem@xxxxxxxx<mailto:gvanem@xxxxxxxx>>; Nuno Antonio Dias Ferreira <nuno.ferreira@xxxxxxxxxx<mailto:nuno.ferreira@xxxxxxxxxx>>; Nmap-dev <dev@xxxxxxxx<mailto:dev@xxxxxxxx>>
Subject: Re: [Bulk] Use of npcap in automation system

Hi Ferreira,

First allow me to paste PCAP_OPENFLAG_NOCAPTURE_LOCAL's description here from winpcap's source:
/*!
            \brief Defines if the local adapter will capture its own generated traffic.

            This flag tells the underlying capture driver to drop the packets that were sent by itself.
            This is usefult when building applications like bridges, that should ignore the traffic
            they just sent.
*/
#define PCAP_OPENFLAG_NOCAPTURE_LOCAL     8

I have tested the WinPcap 4.1.3's PCAP_OPENFLAG_NOCAPTURE_LOCAL flag of pcap_open against my Win 8.1 x64 VM and Win10 RTM x64 VM. Both conditions work as expected (I mean the packet sender will not receive his sent packets), other WinPcap's clients (like Wireshark) will still see the sent packets, which is also expected according to the explanation above. So I can't reproduce the failure you mentioned, could you provide a sample?

For another thing, AFAIK, NDIS 6 is available since Vista, 6.2 for Win7, 6.3 for Win8 (https://msdn.microsoft.com/en-us/library/windows/hardware/ff567893(v=vs.85).aspx). And there isn't quite much difference of NDIS between Win7 and Win8.

/* disable loopback capture if requested */
if(flags & PCAP_OPENFLAG_NOCAPTURE_LOCAL)
{
            if(!PacketSetLoopbackBehavior(fp->adapter, NPF_DISABLE_LOOPBACK))
            {
                        snprintf(errbuf, PCAP_ERRBUF_SIZE, "Unable to disable the capture of loopback packets.");
                        pcap_close(fp);
                        return NULL;
            }
}

And what Gisle said is iterally right, because PCAP_OPENFLAG_NOCAPTURE_LOCAL flag is just implemented by PacketSetLoopbackBehavior (adapter, 1), so these two ways are totally identical. pcap_open() is not standard API but I don't think this is your problem.


Cheers,
Yang

On Mon, Oct 5, 2015 at 4:46 PM, Gisle Vanem <gvanem@xxxxxxxx<mailto:gvanem@xxxxxxxx>> wrote:
Nuno Antonio Dias Ferreira wrote:
I am software developer of automation systems. Last year I develop an application to allow network redundancy where I
was using WinPcap 4.1.3, that application is running well in Windows XP and Windows 7 but is not working in Windows (
and above because of changes in NDIS 6. In my application I am opening Pcap handler with the flag
PCAP_OPENFLAG_NOCAPTURE_LOCAL and that’s the reason why I can’t use my app in Windows 8. Can you tell me if your pcap has
this feature implemented?

The flag PCAP_OPENFLAG_NOCAPTURE_LOCAL is AFAICS a parameter to
'pcap_open()' which is not present in standard libpcap (unless the
REMOTE-stuff is added).

But the same feature can be enabled using:
  PacketSetLoopbackBehavior (adapter, 1);

Works fine under Win 8.1.

--
--gv
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/