RE: [lwip-users] Window memory leak from retransmitted packets

[David Ward]

The problem is still there... :(


I get the Duplicate Acks much less frequently, but the Window buffer
still 'leaks'

Wireshark dump excerpt below
SERVER == 192.168.1.100 is the Xilinx ML506 board with a microblaze
running lwip v1.3 
CLIENT == 192.168.1.103 is a Windows PC running a Java client
appliaction (and Wireshark)

The Java App is designed to only send a packet in resposnce to a message
from the server   
 

45464   518.638702      192.168.1.103   192.168.1.100   TCP     1269 >
8000 [PSH, ACK] Seq=595249 Ack=247891 Win=64385 Len=24
45465   518.658427      192.168.1.100   192.168.1.103   TCP     8000 >
1269 [PSH, ACK] Seq=247891 Ack=595249 Win=65535 Len=10
45466   518.658443      192.168.1.103   192.168.1.100   TCP     1269 >
8000 [PSH, ACK] Seq=595273 Ack=247901 Win=64375 Len=24
45467   518.664511      192.168.1.100   192.168.1.103   TCP     [TCP Dup
ACK 45465#1] 8000 > 1269 [ACK] Seq=247901 Ack=595249 Win=65535 Len=0
45468   518.664520      192.168.1.103   192.168.1.100   TCP     1269 >
8000 [PSH, ACK] Seq=595297 Ack=247901 Win=64375 Len=48
45469   518.670598      192.168.1.100   192.168.1.103   TCP     [TCP Dup
ACK 45465#2] 8000 > 1269 [ACK] Seq=247901 Ack=595249 Win=65535 Len=0
45470   518.670605      192.168.1.103   192.168.1.100   TCP     [TCP
Fast Retransmission] 1269 > 8000 [PSH, ACK] Seq=595249 Ack=247901
Win=64375 Len=24
45471   518.678368      192.168.1.100   192.168.1.103   TCP     8000 >
1269 [PSH, ACK] Seq=247901 Ack=595345 Win=65463 Len=10
45472   518.678477      192.168.1.103   192.168.1.100   TCP     1269 >
8000 [PSH, ACK] Seq=595345 Ack=247911 Win=64365 Len=24
45473   518.698326      192.168.1.100   192.168.1.103   TCP     8000 >
1269 [PSH, ACK] Seq=247911 Ack=595369 Win=65463 Len=10

Dave

-----Original Message-----
From: David Ward 
Sent: 22 June 2009 16:23
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Window memory leak from retransmitted packets

Quick update, still testing

I did find that the Xilinx Webserver was very buggy, I did in fact start
with the Xilinx examples, but then relied heavily on the lwip examples
to fix the bugs. 

Before upgrading the whole Xilinx EDK, I decidded to try a shortcut and
replaced the Xilinx lwip sources with the latest lwip 1.3 source.  To my
surprise it compiled and, and as of now the server has been working for
just under an hour with no duplicate acks, or window buffer leaks.....

I need to perform more tests to ensure that all is okay

Many thanks to all who replied to my call for help!

Thanks

Dave  

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
David Ward
Sent: 22 June 2009 14:42
To: Mailing list for lwIP users
Subject: RE: [lwip-users] Window memory leak from retransmitted packets

With  TCP_QUEUE_OOSEQ = 0  the link is established but my tacp_Recvd()
callback never fires.


I have checked the xilinx documentation for lwip 2.00.a (dated Jan 2007)
and it appears that Xilinx are using lwip stack version 0.7.2 !

Thanks for your help

Dave 


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Kieran Mansley
Sent: 22 June 2009 13:04
To: Mailing list for lwIP users
Subject: Re: [lwip-users] Window memory leak from retransmitted packets

On Mon, 2009-06-22 at 12:32 +0100, David Ward wrote:
> Hi
> I wonder if anyone can help with a lwip problem on a Xilinx ML506 
> Virtex 5 evaluation board with a microblaze processor and Xilinx Lwip 
> 2.0

Any idea what version of lwIP that corresponds to?  We're still on 1.3.0
as the most recent release.

> We are using the raw packet implemetation with a single TCPIP socket 
> link between a windows PC and the development board. I have based my 
> code on the Xilinx web server examples.
> 
> Our link connects and runs for a while, then fails.
> Investigating with wireshark shows that on occasion lwip fails to ack 
> a packet or two causing the PC to perform a fast re-transmission, lwip

> transmits an ack and the link re covers, except that our window size 
> has reduced by the size of the re-transmitted packet. It is this 
> 'window buffer leak' that causes the link to fail eventually.
> 
> Is there anything I am missing, or that I need to do to clear out 
> duplicate packets?

You could try disabling TCP_QUEUE_OOSEQ and see if your problem goes
away.  If it does, that suggests packets aren't being from from the out-
of-order segment list.

Kieran



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

This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal.


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

This e-mail and any attachments may contain confidential and
privileged information. If you are not the intended recipient,
please notify the sender immediately by return e-mail, delete this
e-mail and destroy any copies. Any dissemination or use of this
information by a person other than the intended recipient is
unauthorized and may be illegal.