[Winpcap-users] packet redirection

[Guy Harris]

On Sep 13, 2005, at 7:37 PM, Ben Greear wrote:

> Guy Harris wrote:
>> On Sep 13, 2005, at 4:55 PM, Ben Greear wrote:
>>> With a slightly modified driver, you can become a transparent  
>>> bridge,
>> Do the modifications include inserting the driver into the  
>> networking  stack in such a way that intercepted packets *have* to  
>> get passed on  by the driver in order to be transmitted?
>
> The modification is about 2 lines that just make transmitted packets
> NOT received by the tap sniffing on that interface.  With this patch,
> you can make a bridge, without it, you basically get into an endless
> loop or have to do horrible things to try to figure out if a packet
> you sniffed is tx or rx.

That doesn't help you *intercept* packets, in the sense I mentioned,  
i.e., it doesn't mean that, for example, you can, using WinPcap,  
arrange either that

	1) incoming packets get handed to your code before *any* other part  
of the networking stack sees them, and that the only packets the rest  
of the networking stack sees are those packets that your code passes  
on to the stack

or

	2) outgoing packets get handed to your code before the driver sees  
them, and that the only packets that get put onto the wire are those  
packets that your code passes on to the driver

where "passes on" can mean "passes on after modification".  I think  
that's what Mohammad Ali Agheli needs for his application.

>>> The standard winpcap does not support sending packets  
>>> (correctly),  however.
>> It doesn't?  "pcap_sendpacket()" (and, in 3.1, "pcap_inject()")  
>> don't  correctly send a packet that an application has constructed?
>
> It correctly sends, it's just that it also 'sniffs' the sent packet,
> just as it would a packet from the external network.

OK, so what you meant is "the standard WinPcap doesn't support the  
libpcap 0.9[.x] pcap_setdirection() API with an argument of  
PCAP_D_IN", that being the API that on *some* platforms libpcap  
supports to say "don't show me the packets transmitted by this host".

Or do you mean "the standard WinPcap doesn't have an API to specify  
that it shouldn't see packets that *it* sent, even if it should see  
other packets sent by the host"?

BTW, I'm not convinced that libpcap/WinPcap is the right library to  
use to write transparent bridges, just as I'm not convinced that it's  
the right library to use to implement protocols in userland (e.g.,  
wpa_supplicant).  The only reason I can think of using it rather than  
a more appropriate library is that it exists and the more appropriate  
library currently doesn't. :-)

A library for doing userland protocol support would:

	if possible, request that the low-level mechanism it uses *not* show  
it transmitted packets;

	if possible and appropriate, request that the low-level mechanism it  
use show it only packets of a particular type (at a layer below the  
packet filtering layer, if possible) - doing so might, with some  
drivers (e.g., the Br**dc*m driver on Solaris) also keep it from  
screwing up the link-layer header on *outgoing* packets);

	if possible, request that packets be delivered as soon as they  
arrive, rather than doing buffering;

and it might have an API more convenient for that sort of application.

> It's relatively trivial to capture GigE at line speed (with MTU  
> sized packets,
> at least), but to bridge requires 4Gbps across the PCI bus, not  
> counting
> overhead.  I can *almost* do this with Linux..can get about 920Mbps  
> bi-directional,
> but this is with a kernel module.

...and to save it to disk requires that much bandwidth to the disk,  
if you're not filtering and not using a snapshot length to cut the  
traffic short.

> The really sad thing is that so much would be easier if winders just
> had a packet-socket api :P

Most OSes supported by {libp,WinP}cap don't have such an API, but at  
least some of them have APIs and mechanisms that do at least some of  
the same things, and, just as libpcap doesn't use *all* the  
capabilities of the packet-socket API (only those appropriate to  
packet capture and, in 0.9.[.x], transmission), so {libp,WinP}cap  
don't use all the capabilities of the other underlying mechanisms.   
It could, in theory, have APIs added to do that, but perhaps those  
APIs belong in a different library.