[Winpcap-users] packet redirection

[Loris Degioanni]

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

This is quite funny, because they advertise a functionality *very* 
similar to my BPF jitter, with exactly the same performance I reported 
in my papers on it. Of course, everybody can put that code in its 
application: it's released under the BSD licence.

> I don't know how well WinPcap 3.1 supports SMP systems, 

It does that quite well. We spent quite a lot of time on this subject, 
and we have a paper with Gianluca as the main author 
(http://staff.polito.it/fulvio.risso/pubs/sbac03-smp.pdf).

> or whether  "You 
> can create an application to capture Gigabit network traffic  totally 
> without packet loss."  

This is the typical purely commercial statement used to attract 
inexperienced customers. Nobody nowadays can do Gigabit full rate with 
standard techniques. No question on that.
And, with standard techniques, it's really hard to do better than WinPcap.

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

That is probably the way it works. By the way, we're in the process of 
releasing something similar (an OEM version of WinPcap that can be used 
by applications without the need of installing anything) on the CACE 
website. It will self-contain the WinPcap drivers and dll and extract 
and run them on the fly.


Loris


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