Re: SV: SV: SV: [lwip-users] Re: TCP_SEG Leak ...

[Kieran Mansley]

On Tue, 2008-01-08 at 16:20 +0100, Jan Wester wrote:
> Hi
> I have study the problem more and I think the problem is dropped packets.
> Using multisession for web pages generate heavy network traffic and
> sometimes the packets is dropped, and often it happens on end of session,
> fin etc.
> Maybe the problem is if no ack is received on fin, will it be any resend of
> fin or what ?  

Yes, if the FIN doesn't get ACKed, the FIN should be retransmitted.  In
the trace you gave there was no retransmission of the FIN, and multiple
packets (all those sent after the FIN was received) ACKed it, so I would
expect at least one of those to get though.  If you think the FIN-ACK
was lost, then I would investigate why the FIN is not being
retransmitted by the tcp_slowtmr() routine.

The two odd things that I mentioned before (see below) don't fit with
that though, so I'm not convinced that a lost FIN-ACK is your problem.

Kieran


> One thing that does strike me as odd is that the connection is ending up in
> CLOSING.  It should, given that packet trace, go ESTABLISHED-
> >FIN_WAIT1->FIN_WAIT2->TIME_WAIT->CLOSED.  i.e. never go into CLOSING.
> 
> One more thing that is odd is the last packet on that connection (frame
> 65 in the capture file) has a relative sequence number of 8461.  It should
> be 8462 as the FIN had 8461.