On Fri, Jan 17, 2003 at 07:51:29AM +0000, Steve Schmitz wrote: > The firewall is running not quite the newest version of OpenBSD/PF (a 3.2 > beta). Is it advisable to upgrade, given the interruption in service?
I doubt it will make a difference, as that part of the code (the sequence number tracking) hasn't changed since then, so no. > Jan 16 18:41:32 firewall /bsd: pf: BAD state: TCP 192.168.101.14:32863 > 139.33.102.140:50237 141.225.240.34:1521 [lo=3987556722 high=3987556777 > win=28480 modulator=0] [lo=3963179816 high=3963208296 win=5792 modulator=0] > 4:4 PA seq=3987556722 ack=3963179816 len=121 ackskew=0 pkts=130 dir=out,fwd > Jan 16 18:41:32 firewall /bsd: pf: State failure on: 1 This error means that the client (192.168.101.1) tries to send a packet to the server (141.225.240.34) with a sequence number (3987556722) and length (121) larger than the window the server expects (3987556722-77). When the server acks a packets, the expected window is increased to the acked sequence number plus the advertised window. In this case, the expected window is extremely small (just 55 bytes), so basically the next packet is certain to fail the check. The client isn't sending prematurely here, it just sends the next packet after it got an ack for the previous part (seq=3987556722, src.seqlo=3987556722), the question is why the window is too small. Possibly, the last ack from the server had a very small th_win. You mentioned the behavior depends on the OS (and application) of the server. When Oracle runs on Solaris, it works. And when you connect to the Linux Oracle to another service (ssh, etc.), it works, too? If that's the case, I wonder whether the Oracle on Linux is configured to use any TCP options that might affect window sizes (th_win). Could you run a tcpdump -nvvvSpi <int_if> to catch all packets of a new connection up to the point where it stalls? You can use a filter expression (like 'host 192.168.101.14') to only capture packets of a single connection, as the stall occurs after around 130 packets, the log shouldn't get too large. Mike, have you ever seen such a case before? Daniel
