[Winpcap-users] PCAP_OPENFLAG_NOCAPTURE_LOCAL ignored and PCAP_SETDIRECTION()

[Daniel Smith]

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

[Marcelo Castellon]

A partir del día 01/12/2015 no perteneceré mas a la empresa.
Por cualquier consulta por favor contactar a Hugo Donadello (***@c4i.com.ar).

Muchas Gracias

Ing. Marcelo Castellon

[食肉大灰兔V5]

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

Post by Daniel Smith
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
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
https://www.winpcap.org/mailman/listinfo/winpcap-users

[Daniel Smith]

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

Daniel Smith

Post by 食肉大灰兔V5
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
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

Post by Daniel Smith
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
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
https://www.winpcap.org/mailman/listinfo/winpcap-users

_______________________________________________
Winpcap-users mailing list
https://www.winpcap.org/mailman/listinfo/winpcap-users

[Guy Harris]

Post by Daniel Smith
"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.

"Itself" here means "the underlying capture driver"; if a packet was sent by the regular networking stack, that's *not* one of the packets that gets dropped - only packets sent by the capture driver, i.e. sent by a pcap call, count.

It may also be that it only detects packets sent by the same *instance* of the driver, so that it only filters out packets sent using the same pcap_t.