Hi there, <hi daniel, been a few years since you and jason wright helped me out when testing transparent bridging when pf first came out...>
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", but would like to use PF if at all possible to help 'shape' some of the packets being exchanged: 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 its 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 Its 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 isnt 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 RFCs 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, its still vague as to what we can utilize. -karlski
