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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
