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 ?
Med vänlig hälsning/Best Regards Jan Wester _________________________________ WHI Konsult AB Scheelegatan 11, 112 28 Stockholm, Sweden www.whi.se [EMAIL PROTECTED] +46 8 449 05 30 -----Ursprungligt meddelande----- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
