Date: Mon, 14 Jun 2004 13:51:15 -0500 From: Jon Noack <noackjr@alumni.rice.edu> To: James Housley <jim@Thehousleys.net> Cc: freebsd-net@FreeBSD.org Subject: Re: Using netgraph for filtering/modifing packets Message-ID: <40CDF3A3.7000608@alumni.rice.edu> In-Reply-To: <40CDE026.3040502@Thehousleys.net> References: <Pine.BSF.4.21.0406141016280.30464-100000@InterJet.elischer.org> <40CDE026.3040502@Thehousleys.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40CDF3A3.7000608>