[Winpcap-users] packet redirection

[Guy Harris]

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?

If so, then "c'est magnifique, mais c'est ne pas WinPcap" - this is a  
very different sort of beast from WinPcap, just as a similar bridging  
mechanism on a BSD would be very different from BPF, and a similar  
bridging mechanism in Linux would be very different from PF_PACKET  
sockets, and a similar bridging mechanism in Solaris would be very  
different from DLPI, and....

> 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?

> For commercial ventures, it appears that these guys have a  
> competing tool
> that their sales guy *said* could transmit packets.  I have not  
> actually
> had time to try it out yet...
>
> http://microolap.com/products/network/pssdk/

They also say it has a bunch of features, at least some of which I  
think or know WinPcap also has:

	BPF support

	JIT compiler for BPF programs.

I don't know how well WinPcap 3.1 supports SMP systems, or whether  
"You can create an application to capture Gigabit network traffic  
totally without packet loss."  Some of the other features sound like  
features above the libpcap/WinPcap API layer (if by "packet  
generating functions" in "Packet generating/sending functions" they  
mean functions such as the ones in libnet:

	http://www.packetfactory.net/projects/libnet/

and by "With PSSDK you can capture TCP sessions and assemle them in  
tcp data streams." they mean that PSSDK has functions to dissect TCP  
packets and assemble the payload.

As for "BPF assembler and disassembler", there's no "BPF assembler"  
other than the macros in bpf.h, but there should be a BPF  
disassembler, at least in 3.1, namely bpf_dump(), although it only  
supports writing to the standard output.

(Obviously no migration module from WinPcap to WinPcap is  
necessary. :-))

I'm not sure what's special about "No pre-installed packet capture  
drivers are required" - unless "internal" means that the code to the  
driver is something such as a giant array of bytes of code, so that a  
PSSDK-based application doesn't have to come with a driver, I'm not  
sure how this is interestingly different from WinPcap.