6

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.

Erwan Queffélec
  • 387
  • 3
  • 11

2 Answers2

7

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 127.0.0.1 12345

and

cat /tmp/testpipe | nc 127.0.0.1 23456

And then your client spews at port 9999.

pableu
  • 133
  • 4
cjc
  • 24,533
  • 2
  • 49
  • 69
1

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.

Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • 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 09 '11 at 12:50
  • Does it work for TCP as well? – daisy Dec 30 '12 at 12:58