It seems like you need a component which will take the individual packets of one sniffed connection and relays that reassembled stream to another client, in a separate connection, on demand.
No amount of trickery in a packet filter will do this, as TCP isn't made for three-party connections at all. You need that component doing the TCP stream reassembly, especially in the common case where you have packet loss and retransmits. Take a look at /ports/net/tcpshow. You don't need a fancy bridge with shunting wires. Just place a cheap three port hub between the real client and server, and connect a passive sniffing box on a third port. Sniff the client-server connection, pass the individual packets to something like tcpshow, which produces the reassembled TCP stream (either two, one for each direction, or one, intermixing both directions). Then put a little daemon on the sniffer which accepts connections from a tapping client. Whenever such a connection is established (which is completely unrelated to the ongoing client-server connection), have the daemon relay the output of tcpshow to its client. If you don't want/can't write your own, use nc(4) -l tail(8)ing tcpshow's text log, for instance. I don't understand the part about ToS shapping in your post, was that meant to somehow create a three-way TCP connection? If so, I don't see how that could possibly work. If it's an unrelated problem (i.e. you want to shape ToS between the real client and server, for some purpose), treat the problems separately. Daniel
