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