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

[Kieran Mansley]

On Thu, 2008-01-03 at 10:26 +0100, Jan Wester wrote:
> Hi
> I have checked my timer by using a LED and is called every 250ms (tcp_tmr)
> I also have a capture of traffic (ooseg.pcap) with dump of active pcbs
> (pcbs.txt)
> The lwip is on 192.168.0.1 with webserver using multisessions, the actuel
> page consists of 3 files (3 sessions), html, css and gif  

OK, that's interesting.  A quick look (so I might have got something
wrong) suggests that of the three connections, only one seems to end up
with out of order traffic: the connection between 192.168.0.1:80 and
192.168.0.47:1139.  However, it is 192.168.0.47 (i.e. *not* lwIP) that
is dealing with the out of order data as lwIP is the sender in this
case.  I had been assuming that we had some problem with lwIP's out or
order FIN processing, but that can't be the case in this example.  It is
this connection that is hanging around though in your dump of the active
PCBs.

Also, in all three connections the FINs are correctly ACKed, and there
are no retransmissions, which suggests that everything is fine.  If one
of the final ACKs was in fact lost, I would expect to see
retransmissions of the FIN, and so if you think that is likely the lack
of retransmissions would explain your problem.

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.

So, there is clearly something wrong here, but I'm not sure what.

Kieran