On Mon, Dec 17, 2007 at 03:52:00PM +0100, Henrik Johansen wrote:
> You can find the requested dump here:
> http://blog.myunix.dk/pf/tcpdump.sanitized
>
> The corresponding BAD state error is here:
> http://blog.myunix.dk/pf/messages_tcpdump.sanitized
There is nothing obviously wrong with the dump. The peers negotiate
SACK, and the bulk of the data is from server to client. Eventually,
a packet got lost. The client makes use of SACK to tell the server about
the gap due to the lost packet. The server takes a while to react and
re-transmit just the gap.
Then, the client half-closes its end of the connection (telling the
server that it won't send more data, but will read more). The server
tries to keep sending more data.
Then the client resets the connection, setting its window to 0.
The server either doesn't get the reset, or is slow to react to it, it
keeps sending data, which pf blocks with the BAD state messages.
I'd say it's safe to ignore those BAD state messages. After the client
has sent a RST, there is no harm in not passing further packets.
You might want to investigate why
a) the client resets the connection (is the server sending a wrong
HTTP Content-Length: header, so the client thinks it got all data,
when the server thinks there should be more?)
b) why the server doesn't react to the RST by shutting up immediately.
c) does this pattern occur with all clients, or only with a specific
client?
Daniel
