[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mangling TOS, or Precedence/SecurityOpts/Compartment?]
Hi Daniel, Abhijit, (and PF list),
Thanks for responding, it's actually existing to get down to brass tacks
on this question. Here's some more clarification about the "Analysis"
machine in terms of how it's connecting to the "Controller" and "Tool"
machines, from my co-worker Abhijit, who maintains said hardware/software,
-he sums up the tcp/ip packet adjustment need fairly well. [see snip below
2 paras] : )
Background on the Anaysis machine:
The Analysis machine is actually really important because it's chasing the
holy grail of chipmaking, gathering information about gas/plasma reactions
from machines involved in chip etching/production. So a sniffing/tapping
effort might not be the solution.
The idea is that this machine already works great, and that it took the
scientists & coders years to work out all the variables to make it able to
sense/apply predictive models using this critical information, which in
turn is used by many chipmakers who already have this hardware to get a
better chip yield. The packet filtering element is a critical issue for
many reasons when it comes to this machine.
Which type of details of the analysis machine do we need to provide?
Yes, we don't need a 3 way connection. Note that when analysis machine
can successfully connect to the TCP server, the host still sends packets
towards the tool, but since the analysis machine is in between them, it
receives the packet, processes it and sends a duplicate packet towards
the tool server.
Note: it is a duplicate packet, not the original one since in the
analysis machine software we are dealing with a higher level protocol
(HSMS over TCP) and the modules of the software that deal with the tool
communication and host communication are independent. THIS IS A GIVEN
AND CANNOT BE CHANGED. All we want to make the duplicate packets look
like it is coming from the host so the tool does not know about the
analysis machine. In order to do that we have to change the source Ip/
port and precendence / security / compartment.
Feel free to ask more about the nature of the analysis machine and it's
software, -as i'm sure it will clarify the nature of the network
connections we are discussing.
> 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.