[Winpcap-users] packet redirection

[Ben Greear]

Loris Degioanni wrote:
> Ben
> 
> Ben Greear wrote:
> 
>> Guy Harris wrote:
>>
>>>
>>> On Sep 13, 2005, at 4:32 PM, Guy Harris wrote:
>>>
>>>> It does not, however, let you *intercept* packets received by that  
>>>> machine.  A WinPcap-based application cannot see those packets  
>>>> before the rest of the networking stack sees the packets, and  
>>>> cannot prevent the rest of the network stack from seeing the packet  
>>>> as received, and cannot inject its own modified version of the packet.
>>>
>>>
>>>
>>>
>>> This is, by the way, mentioned in the WinPcap FAQ:
>>>
>>>     http://www.winpcap.org/misc/faq.htm#Q-17
>>>
>>> "Q-17: Can I use WinPcap to drop the incoming packets? Is it 
>>> possible  to use WinPcap to build a firewall?
>>> A: No. WinPcap is implemented as a protocol, therefore it is able to  
>>> capture the packets, but it can't be used to drop them before they  
>>> reach the applications. The filtering capabilities of WinPcap work  
>>> only on the sniffed packets. In order to intercept the packets 
>>> before  the TCP/IP stack, you must create an intermediate driver."
>>
>>
>>
>> With a slightly modified driver, you can become a transparent bridge,
>> and then if you really wanted to, you could sit inline and modify packets
>> before transmitting them on their way...
>>
>> The standard winpcap does not support sending packets (correctly), 
>> however.
> 
> 
> WinPcap *does* support sending packets correcly, both in a buffered and 
> unbuffered way. This is more than what most alternative solutions do.
> 
> If you refer to the fact that WinPcap doesn't support filtering packets 
> transmitted by itself, I'm currently implementing that feature, it will 
> be included in the next version.

That is my primary complaint, so I definately look forward to this feature!
To make sure it's clear:  I want to be able to tx a packet and not receive
it.  I would much rather have this just 'work' than have to set up any kind
of filter.  Setting a per-pkt or per connection flag would be the preferred
API for me...

The only other suggestion I can think of at the moment:

Allow one to select on a file descriptor that is somehow tied to
the rx input of the capture tap.  I know you can multi-thread, but that
is a higher price than I wish to pay.  My current work around:  poll once per ms.
Works ok, but not a great solution.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com