Is where any example availble for defined of macros for lwip_platform_diag printout I have try def for lwip_platform_diag but it is problem to get it work and I found out it is problem with variable no of arguments, it works for one argument (only print format string) if the arguments consists of format string and a integer, the input parameter for the function is a value of the integer, should be a pointer ?
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 8 januari 2008 16:54 Till: Mailing list for lwIP users Ämne: Re: SV: SV: SV: [lwip-users] Re: TCP_SEG Leak ... 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. _______________________________________________ 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
