I have to test a homebrew server that accepts a lot of incoming TCP traffic on a single port. The protocol is homebrew as well.

For testing purposes, I'd like to send this traffic both : - to the production server (say, listening on port 12345) - to the test server (say, listening on port 23456)

My clients apps are "dumb" : they never read data back, and the server never replies anyway, my server only accepts connections, and do statistical computations and store/forward/service both raw and computed data.

Actually, client apps and hardware are so simple there is no way I can tell clients to send their stream on both servers... And using "fake" clients is not good enough.

What could be the simplest solution ? I can of course write an intermediary app that just copy incoming data and send it back to the testing server, pretending to be the client.

I have a single server running Squeeze and have total control over it.

Thanks in advance for your replies.

  • Is your protocol really based on TCP? UDP would be simple, TCP, not so much. – Zoredache Sep 9 '11 at 0:09
  • Or a switch that supports port mirroring such as a Mikrotik RB250S. They are not expensive. – Matt Sep 9 '11 at 0:24
  • Are you sure the servers never reply? Not even with ACKs? – Gerald Combs Nov 7 '11 at 21:32

If you don't want to write anything, maybe netcat listening on one port, piping to tee, and tee going to a couple named pipes, that are in turn netcat to the prod and test server ports?

Something like:

mkfifo /tmp/prodpipe
mkfifo /tmp/testpipe
nc -l 9999 -k | tee /tmp/prodpipe | tee /tmp/testpipe

And, in separate terminals:

cat /tmp/prodpipe | nc 12345


cat /tmp/testpipe | nc 23456

And then your client spews at port 9999.

  • looks simple and straightforward, exactly what I'm looking for. I'll try this ASAP. – Erwan Queffélec Sep 9 '11 at 12:46

If your traffic is UDP this should be pretty easy to do with iptables.

A TEE target for iptables is available that basically allows you to send a copy of the packet to a different destination.

It isn't built into the kernel by default, but the source and tools is available in the xtables-addons-source package.

  • My traffic is not UDP... The whole point is that I have no control on the protocol as I can't change the way the production server app works, and have no control over the clients. However, if I could find a "clean" way to convert TCP packets to UDP datagrams (huuuummm...), this could be a fallback if the named pipes + tee doesn't work. – Erwan Queffélec Sep 9 '11 at 12:50
  • Does it work for TCP as well? – daisy Dec 30 '12 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.