Hi there, We are running a set of three systems for semiconductor technology, and would like to finalize our work in getting them to interoperate properly, but have run into some issues that touch on the very fabric of TCP/IP expertise, but iptables has already been used to solve "part of this", read on: The three systems consist of: System #1: Chip fabrication ?tool? running std. TCP Server, using port 5000 System #2: Controller machine, running standard TCP Client, using port 5000 System #3: ?Invisible? Analysis machine running Fedora Core 4, and analysis software To see the drawing: http://www.klxsystems.net/pics/Analysis.html The Tool Server? and the ?Controller Machine? typically only communicate with one another over a standard tcp connection, in single mode. For the purposes of analysis, a third ?Invisible? Analysis machine is placed between Systems #1 and 2, and is cabled as shown in Figure 1, it has two Ethernet ports, and in general acts like a ?bridge? in that it possesses a ?Bypass Card?, which allows the Tool Server and the Controller Machine to pass traffic through it?s two Ethernet ports. One of the features of the Bypass card it contains, is that it physically shunts the copper Ethernet connections together when, say, power is cut. It runs in an ?unshunted? format when conducting ?Analysis?, and shunts the copper back together when it ?hangs up? It?s purpose is to sit BETWEEN the Tool and Controller machines, and intercept data they are exchanging, for analysis used to effect better performance, and then ?hang up? by shunting the connection, and thus allowing the two main machines (Tool/Controller) to keep ?talking? as they were prior to the ?analysis? machine intervening. Our problem: We need to seamlessly start and stop the second TCP Client connection the Analysis machine ?invisibly? creates/ terminates. The issue has been one of TCP/IP sequence numbers, ?how to get them to stay the same?, and not ?drop? the connection per RFC 798. Using dsniff or other sequence number guessing isn?t an option. What we did do however was use: iptables ?A POSTROUTING ?t nat ?d <dest_ip> -s <source_ip> -p tcp ?j SNAT ?to-source <source_ip> This allowed a change of the source ip address of the packets going from the analysis machine towards the tool server. We tried to change the ?precedence? field by using the: iptables ?A POSTROUTING ?t mangle ?d <dest_ip> -s <source_ip> -p tcp ?set-tos 32 -but this did not take in the command line, ?TOS value not valid?. So our question is, how do we get the Analysis machine to invisibly connect, and disconnect, without violating RFC 798? There are several RFC?s that point to Differentiated Service field manipulations, using tools like iproute2, but those never went into ways to actually MODIFY the ?Precedence, Security Option, and/or Compartment? fields in an IP header from what we could tell. The RFC that led us to this information stated: With the advent of DiffServ, intermediate nodes may modify the Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header to indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597, RFC2598]. The DSCP includes the three bits formerly known as the precedence field. Because any modification to those three bits will be considered illegal by endpoints that are precedence-aware, they may cause failures in establishing connections, or may cause established connections to be reset. Any suggestions if iproute, iptables, or other technologies would facilitate this complex type of transaction? We understand that modifying the TOS can be done at the application level, as stated by RFC 2873, but these other fields, it?s still vague as to what we can utilize. -karlski
