On Wed, Dec 17, 2003 at 09:48:46AM +0100, [EMAIL PROTECTED] wrote: > Yes that is the problem I get BAD State with the misc debug. How come > this violates TCP?
The more obvious rule is that two concurrent TCP connections cannot use the same source/destination address/port pair at the same time, as the receiver uses that information to associate the packets with the appropriate socket. But even when a single connection is closed, the pair must not be reused for a while (2MSL, twice the maximum segment lifetime, the amount of time a stray packet, like a retransmission, might be delayed in the network), otherwise a late packet of the first connection could be wrongly associated with the socket of the second connection by the receiver. The details are explained in RFC 793 TRANSMISSION CONTROL PROTOCOL (TCP) http://www.faqs.org/rfcs/rfc793.html I guess the rsh client producing the problem is explicitely binding to source port 514 because the source port is checked by the rshd (for instance, OpenBSD's rshd(8) requires it to be in the range 512-1023, as a weak security constraint) and using the socket option SO_REUSEADDR to bypass the 2MSL restriction (otherwise enforced by the OS). Maybe you find something relevant in the man page of that particular rsh client. > Is there any solution in order to keep state and manage to forward > packet for that crappy rsh implementation (linux is not ok, sgi is ok). > > From my point of view i don't see any apart from disabling the > stateful inspection. Try lowering the tcp.closed timeout for these state entries, so the first state is removed earlier. The default is 90 seconds (so late packets are associated with the state entry for 90 seconds after the connection has been closed). You can reduce that to, say, 3 seconds, so the state entry is removed and a second connection will create a new state and work properly if it is created at least 3 seconds after the first one is closed. You can set the timeout in a particular rule, so only states created from that rule will have lowered timeouts: pass proto tcp from port 514 to port 514 keep state (tcp.closed 3) Note that timeouts are only checked (and timed out state entries removed) in intervals (default is 10 seconds, see pfctl -st). If you are using timeouts near or below that interval, you might want to lower the interval, too, to get enough precision. With tcp.closed 3 and interval 10, the state removal might occur as late as 13 seconds after the connection is closed. Just curious, what does that rsh client do if you try to run multiple concurrent rsh sessions to the same destination? It can't possibly use source port 514 for more than one connection (to the same destination address and port) at the same time. That wouldn't just confuse pf, but also the receiver (it wouldn't work even if you disable pf). Daniel
