Using netgraph for filtering/modifing packets

[Jon Noack]

On 06/14/04 12:28, James Housley wrote:
> Julian Elischer wrote:
>> On Mon, 14 Jun 2004, James Housley wrote:
>>> For testing of a product I would like to be able to modify or even drop
>>> packets based on their content.  What I have in mind is forcing the
>>> packets through a firewall that would redirect all packet to a netgraph
>>> node that would either pass unchanged, drop or change the contents to
>>> assist in testing some corner cases in the code.
>>>
>>> 1) is this something doable with netgraph, I believe it is.
>>
>> yes
>>
>>> 2) what might be a good place to start?  Have done some searching, but
>>> haven't found any example code I thought I could start from.
>>
>> What sort of filter do you need?
>>
>> you can pass packets to netgraph from ipfw by diverting them and
>> openning a divert socket with teh ksocket node..
>>
>> Or you can pick them directly from the network interface
>> and filter yourself using the 'bpf' node type to select on something.
>> or you can use the etf type of node to filter on a particular ethertype..
>>
>> there are a lot of options but I don't knw your application enough :-)
> 
> I have a product that is connected to a PC via eithernet.  The product 
> runs FBSD, but I would likely put another FBSD box in the middle.  I 
> want to be able modify packets for good and evil based on the data 
> portion of the packet.
> 
> For example to ocasionally drop a packet that is acking some command.  
> Or send an ack for a command that was never sent.  Or just change data 
> to be invalid.
> 
> Then after messing with the data portion put it back in the queue to be 
> sent, if it wasn't just dropped.sys/net/bridge.c

This will only get you the first of the three requirements you 
mentioned, but it is quite easy to setup:
You can simulate a lossy link with dummynet.  A few years ago I setup a 
test environment on a machine with 8 network ports acting as a bridge. 
With a few scripts I could set each port to simulate a modem, dsl, 
cable, or t1-connected client (independent up and down bandwidth, delay, 
packet loss rate, etc.).  I also had an "overseas" option to increase 
the delay.  The product we were testing was a peer-to-peer networking 
engine with failover capability.  It worked quite well (after applying a 
patch from Luigi to allow bridge to work without one_pass -- reminded 
him about the patch and he finally committed it in rev. 1.55 of 
sys/net/bridge.c).  It was quite a success, and uncovered many timing 
related issues with our product.  Handling modem clients gracefully was 
the hardest part, and made me feel a bit nostalgic; using a simulated 
modem link was just as frustrating as the real thing!

Jon Noack