[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Mangling TOS, or Precedence/SecurityOpts/Compartment?]

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
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.