Re: Use of npcap in automation system

[食肉大灰兔V5 <hsluoyz () gmail com>]

Hi Ferreira,

I am a bit confused about the underlying working way of your scenario.
Better understanding is needed. I have forwarded this mail to wireshark's
list to see if Guy knows something about this issue.

On Thu, Jan 14, 2016 at 11:47 PM, Nuno Antonio Dias Ferreira <
nuno.ferreira () efacec com> wrote:

> Hi Yang,
>
>
>
> Do you have any update about this matter?
>
>
>
> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 13 de janeiro de 2016 16:06
>
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>
> *Cc:* Nmap-dev <dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *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 () efacec com> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 13 de janeiro de 2016 12:43
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>
> *Cc:* Nmap-dev <dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *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 () efacec com> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 13 de janeiro de 2016 02:47
>
>
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>
> *Cc:* Nmap-dev <dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *Subject:* Re: Use of npcap in automation system
>
>
>
> Hi,
>
>
>
> On Tue, Jan 12, 2016 at 11:14 PM, Nuno Antonio Dias Ferreira <
> nuno.ferreira () efacec com> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 12 de janeiro de 2016 14:30
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>
> *Cc:* Nmap-dev <dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *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 () efacec com> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 11 de janeiro de 2016 17:27
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>
> *Cc:* Nmap-dev <dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *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 () efacec com> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 11 de janeiro de 2016 14:03
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>
> *Cc:* Nmap-dev <dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *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 () efacec com> 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
> [image: EFA Logo]
>
> Disclaimer <http://efacec.com/email.jpg>
>
>
>
> *From:* 食肉大灰兔V5 [mailto:hsluoyz () gmail com]
> *Sent:* 9 de janeiro de 2016 03:11
> *To:* Nuno Antonio Dias Ferreira <nuno.ferreira () efacec com>; Nmap-dev <
> dev () nmap org>; Gisle Vanem <gvanem () yahoo no>
> *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 () efacec com> 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 () gmail com]
> Sent: 7 de outubro de 2015 09:12
> To: Nuno Antonio Dias Ferreira <
> nuno.ferreira () efacec com<mailto:nuno.ferreira () efacec com>>
> 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 () efacec com<mailto:nuno.ferreira () efacec com>> 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 () gmail com<mailto:hsluoyz () gmail com>]
> Sent: 5 de outubro de 2015 18:03
> To: Gisle Vanem <gvanem () yahoo no<mailto:gvanem () yahoo no>>; Nuno Antonio
> Dias Ferreira <nuno.ferreira () efacec com<mailto:nuno.ferreira () efacec com>>;
> Nmap-dev <dev () nmap org<mailto:dev () nmap org>>
> 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 () yahoo no<mailto:gvanem () yahoo no>> 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/

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