Daniel Smith zamadatix at gmail.com
Thu Sep 29 04:23:26 UTC 2016

It looks like I just misinterpreted this piece of the documentation:

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

But PCAP_OPENFLAG_NOCAPTURE_LOCAL doesn't do *quite* that, instead of being
based on if the traffic was sent by the driver/local adapter it actually
seems to be dependent on if it was sent by the exact pcap_open function
that the device pointer holds. If I open the interface a single time and
pass the device to the threads rather than call pcap_open() with that flag
in each thread it seems to filter just fine!

Thanks for the tip on Npcap though, looks like an interesting fork to try

Daniel Smith

On Wed, Sep 28, 2016 at 10:00 PM, 食肉大灰兔V5 <hsluoyz at gmail.com> wrote:

> Hi Daniel,
> You can try Npcap: https://github.com/nmap/npcap.
> The releases are published here: https://github.com/nmap/npcap/releases
> It's a fork of WinPcap. And it supports latest libpcap 1.8.0 interface. So
> maybe the PCAP_SETDIRECTION function works for Npcap, if it works on latest
> libpcap. If I remembered right, The PCAP_OPENFLAG_NOCAPTURE_LOCAL flag is
> also one thing that Npcap fixed before.
> I have also provided a "Send-to-Rx" feature in Npcap and designed a bridge
> application called "UserBridge" to use that feature here:
> https://github.com/hsluoyz/UserBridge. UserBridge mainly do this:
> If you want all received traffic on Adapter A seems like to be received
> on Adapter B, and all traffic sent out from Adapter B to be actually sent
> out from Adapter A
> "Send-to-Rx" means to inject packets to a network interface's receive path
> that makes the interface think it receives those packets (instead of
> sending them out). You can just use it to fulfill a customized need.
> Cheers,
> Yang
> On Thu, Sep 29, 2016 at 8:50 AM, Daniel Smith <zamadatix at gmail.com> wrote:
>> Hello,
>> I have been trying to make a custom software bridge using winpcap.
>> Unfortunately this means sending and receiving packets that arrive on a
>> pair of interfaces which means there needs to be some sort of logic
>> preventing infinitely copying any packet that appears in a cycle. As it is
>> a bridge I can't apply a capture filter to match the source MAC/IP of the
>> interfaces since many (known and uknown) MACs/IPs may need to transit the
>> link pair. After digging through the documentation I came across two
>> possible solutions:
>> PCAP_SETDIRECTION(device, PCAP_D_IN) - a directional filter to the
>> capture. Unfortunately this returns -1 as it does not seem to be supported
>> on Windows.
>> pcap_open() instead of pcap_open_live() - pcap_open() has flags for the
>> 3rd argument, one of which being PCAP_OPENFLAG_NOCAPTURE_LOCAL which is
>> supposed to prevent capturing packets sent by the driver itself.
>> Unfortuntaley when I launch 2 threads, one capturing on the interface and
>> one sending, I still receive the sent packets in the capturing thread. I am
>> using the following to open the interface in both
>> threads: pcap_open(InterfaceName, 65536, PCAP_OPENFLAG_NOCAPTURE_LOCAL,
>> 1000, nullptr, ErrorBuffer)
>> Does anyone have any guidance on why pcap_open() might be behaving this
>> way or another way to achieve my goal of not capturing packets libpcap
>> itself put on the interface?
>> Thank you,
>> Daniel Smith
>> _______________________________________________
>> Winpcap-users mailing list
>> Winpcap-users at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/winpcap-users
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20160929/8f825eba/attachment-0001.html>

More information about the Winpcap-users mailing list