On Thu, Nov 16, 2006 at 12:48:11PM +0100, Sylwester S. Biernacki wrote: > Nov 16 08:06:30 ungabunga /bsd: pf: BAD state: TCP 10.0.0.1:80 > 1.1.1.1:80 2.2.2.23:5027 [lo=1659423809 high=1659488734 win=16384 modulator=0] > [lo=1312540182 high=1312540506 win=65535 modulator=0] 4:4 A seq=1312540182 > ack=1659423809 len=1460 ackskew=0 pkts=3188:5511 dir=out,rev
(there is one line from pf just after each one of those, you missed to quote it, it helps in these cases) The packet is outgoing, from server 1.1.1.1:80 to client 2.2.2.23:5027. The client has advertised a window of 65535 bytes, and last acknowledged sequence number 1312474971. Therefore, the upper limit is 1312474971 + 65535 == 1312540506. Now the server is trying to send sequence 1312540182 + 1460 bytes of payload. That's 1312541642, and larger than the upper limit. Hence the packet is blocked. Is the window really 65535, or did pf miss window scaling negotiation? The state is not aware of window scaling, according to the output. Try to capture just the TCP handshake (the first three packets) of a failing connection, and post the tcpdump output of that. However, it's unlikely that you didn't create on the initial SYN, the connection wouldn't have worked at all if you did, because of the redirection. Otherwise I don't know why the server would try to violate the client's window. What OS is the server? You might have to capture an entire failing connection (from handshake up to the problem), on both the server and the client. This is going to be quite large (seeing the problem occurs after >8000 packets), so put the dump on a web server somewhere and post the URL to it, if you can :) Daniel
