> > All of these FINs go through, but never receive an ACK (why?).
>
> Because the other side sucks and decided to violate the TCP RFC by fast
> closing connections without waiting proper session shutdown to free
> sockets quickly and since that is not enough they even decided to not
> send a RST back to such FIN packets. So you lose, live with it there is
> nothing you can do against this. The Internet is full of such suckers.
Is there a way to make sure that thsi is what's happening?
> At the same time firefox seems to be a snail and needs a lot of time to
> figure out that a connection got half closed. Keepalive at its best.
With 'set optimization conservative', all the timeouts get
bumped to much bigger values; I no longer see the blocked FINs.
But that's not because they have more time (if the other side
never ACKs my FINs, they will lose state at some point),
but the application (firefox) now sends its FIN much faster,
and it gets ACKed. What does 'optimzation conservative' do
besides bumping up the timeout values. How does that influence
running applications (wrt how they close connections)?
> > Then, these FINs start to get blocked. First such is
> >
> > 13:10:28.363318 mac.stare.cz.54748 > www.ihned.cz.www: F 637:637(0) ack 518
> > win 65535 <nop,nop,timestamp 743723615 3992488807> (DF)
> >
> > The corresponding line from 'tcpdump -e -i pflog0' is
> >
> > 13:10:28.363655 rule 15/(match) block in on vr1: mac.stare.cz.54748 >
> > www.ihned.cz.www: F 4189102151:4189102151(0) ack 1081156646 win 65535
> > <nop,nop,timestamp 743723615 3992488807> (DF)
> >
> > (I am assuming it is the same packet, as the timestamp differs by
> > less then a milisecond.)
> >
> > The first FIN we tried to send was at 13:08:21; tcp.closing is 900s;
> > (tcp.closing: The state after the first FIN has been sent.) So we
> > are well within the timeout.
>
> You sure that your state is in the closing state and not in FINWAIT or
> CLOSED? The first FIN will move the state to closing and the other side
> sending the 2nd FIN will move the state to CLOSED (IIRC)
I am not sure. But the first FIN is sent by the other side (moving the
state to closing), we ACK it, and send our FIN (moving the state to
finwait?), which never gets ACKed.
> so you will end up with a much shorter 90s timeout.
This is indeed the first packet that goes over 90s:
the first (remote) FIN came at 13:08:07
the last FIN we send that goes through is 13:09:24 (i.e. 77s later)
the first FIN that is blocked is at 13:10:28 (i.e. 141s later)
But where does the 90s limt come from? Without further
configuration, pf has a tcp.finwait of 45s.
> The first FIN we tried to send was at 13:08:21; tcp.closing is 900s;
> (tcp.closing: The state after the first FIN has been sent.) So we
> are well within the timeout.
I am probably misunderstanding something.
"tcp.closing: The state after the first FIN has been sent."
That does not mean the first FIN _we_ sent. The first FIN
was sent by the other side, at 13:08:07.
The state we are in now _is_ tcp.closing, right? The first FIN has been
sent. It's not "tcp.finwait: the state after both FINs have been exchanged",
right? Because the FINs have not been exchanged - our FIN has not been ACKed.
Or does pf consider this finwait already, because we have acked the remote
FIN, and sent our FIN?
Either way, this packet is not the first one to go over tcp.finwait = 45s.
(And it is well withnin tcp.closing = 900s.) So why is this the first
one that got blocked?
Thank you for your time
Jan
