The client 192.168.220.106:49194 is at fault. It establishes the
connection, then tears it down with these packets:
> 10:17:14.444212 192.168.220.106.49194 > 192.168.221.20.993: FP
> 2634574252:2634574289(37) ack 1101857573 win 65535 <nop,nop,timestamp
> 1476581199 3164056005> (DF) (ttl 64, id 25617, len 89)
> 10:17:14.444286 192.168.220.106.49194 > 192.168.221.20.993: R [tcp sum ok]
> 2634574252:2634574252(0) win 0 (ttl 64, id 25618, len 40)
After the (valid) FIN, the connection is half-closed. That is, the
client told the server that it is finished sending data. The server is
allowed to send further data (until it sends itself a FIN, fully closing
the connection).
But the client doesn't seem to want to read further data from the
server, and sends a RST. But the sequence number (th_seq) used in the
RST is not valid. It should be 2634574290 (past the last segment the
client sent), not 2634574252 (past the second-to-last segment, not including
the payload in the FIN+PSH).
This looks like a bug in the client's TCP/IP stack, and how to fix it
depends on the client's OS. IMO, the RST is invalid, and pf is right in
blocking it.
More details are found in RFC 793 (Transmission Control Protocol), especially
Reset Processing
In all states except SYN-SENT, all reset (RST) segments are validated
by checking their SEQ-fields. A reset is valid if its sequence number
is in the window.
where "in the window" means
A segment is judged to occupy a portion of valid receive sequence
space if
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
or
RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND
where "RCV.NXT" means
RCV.NXT = next sequence number expected on an incoming segments, and
is the left or lower edge of the receive window
The point is that the sender's FIN+PSH has advanced the receiver's
RCV.NXT to 2634574290, and the sender should know that.
Daniel
