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

[Jan Wester]

Hi
I believe it is something wrong on last ack on fin, in capture file the ack
is always where, but I using the callback routine for sent, and then it goes
wrong I don´t get any callback
Shall I turn on trace for TCP ? 


Med vänlig hälsning/Best Regards
Jan Wester

_________________________________ 
WHI Konsult AB
Scheelegatan 11, 112 28 Stockholm, Sweden
www.whi.se
address@hidden
+46 8 449 05 30

-----Ursprungligt meddelande-----
Från: address@hidden
[mailto:address@hidden För Kieran Mansley
Skickat: den 3 januari 2008 10:57
Till: Mailing list for lwIP users
Ämne: Re: SV: SV: [lwip-users] Re: TCP_SEG Leak ...

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 



_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users