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

[Jan Wester]

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
address@hidden
+46 8 449 05 30

-----Ursprungligt meddelande-----
Från: address@hidden
[mailto:address@hidden 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users