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
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
