Support pcap_setdirection() for filtering packets by direction (sent or received)

[pstavirs]

Similar to WinPcap, Npcap also doesn't seem to support pcap_setdirection.

Any plans to support?

Using Npcap 0.9990

[guyharris]

Is there a way to get an "incoming vs. outgoing" indication from NDIS?

[dmiller-nmap]

For NDIS filter drivers like Npcap, direction is determined by whether the packet is in a "send indication" or a "receive indication." NDIS calls separate callback functions for each of these, and Npcap ends up processing packets in the same NPF_DoTap function. We could potentially support a capture option or mode for this, but we'll have to figure out priority.

@pstavirs You should definitely update to Npcap 1.00.

[guyharris]

For NDIS filter drivers like Npcap, direction is determined by whether the packet is in a "send indication" or a "receive indication." NDIS calls separate callback functions for each of these, and Npcap ends up processing packets in the same NPF_DoTap function. We could potentially support a capture option or mode for this

Yes - you'd have a per-instance mode settable with an ioctl, with options "process all packets", "process received packets only", and "process sent packets only" (or "ignore no packets", "ignore sent packets", and "ignore received packets" - that could be implemented as two "ignore" flags).

@pstavirs You should definitely update to Npcap 1.00.

You won't get pcap_setdirection(), but you will get bug fixes, performance improvements, etc..

[guyharris]

Distinguishing between received and sent could also be useful in the future; at some point I'd like to have a new capture API, delivering pcapng blocks, which would allow the packet direction to be supplied as the epb_flags option. struct bpf_hdr has a bh_hdrlen option - one (possibly unintended) side-effect of that is that if readers honor that field, rather than assuming the structures provided by a read have a fixed size, is that more information can be added to the structure after bh_hdrlen, without breaking binary compatibility.

(That field originally came from BPF, which added it to allow padding to be inserted before the link-layer header, so that, for example, the IP header could be put on a 4-byte boundary - but it also allows additional information to be provided. Apple's extended BPF header is only used if you ask for it - they may have worried about programs using BPF and not using bh_hdrlen, and maybe that'd be an issue in *BSD as well - but I'm guessing that wouldn't be an issue for NPF.)

[fyodor]

I've received some other requests for this as well. It sounds like it wouldn't be too had to implement given that the libpcap API exists and that NDIS uses different callbacks so we can distinguish sent vs received packets that way. The new pcapng API stuff @guyharris talks about for determining direction of received packets might be a longer term goal, but for now (once we have pcap_setdirection support), applications which care could open two handles. One for capturing packets sent by the system and one for those received.

[guyharris]

The new pcapng API stuff @guyharris talks about for determining direction of received packets might be a longer term goal,

Yes - pcapng format includes an option for the Enhanced Packet Block that includes flags that indicate whether the packet was sent by the capturing host, the packet was received by the capturing host, or it's unknown whether the packet was sent or received by the capturing host.

An API that provides EPB-style information for each packet when capturing or reading would allow that information to be provided on platforms that provide it.

[pstavirs]

Any plans for this?

[Saigut]

Any plans?

[farcas-snps]

This is quite embarrassing. Any plans for supporting filtering by direction?