[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [lwip-users] TCP transmission issue, with linux server.

From: B B
Subject: RE: [lwip-users] TCP transmission issue, with linux server.
Date: Tue, 11 Aug 2009 09:58:59 +0200

Hi David,
Thank you for your reply.
I completely agree that my application should cope with data being sent in arbitrarily sized blocks.
My application is now capable of handling this. But that was only a part of the solution for me.
I had to change the value of TCP_WND also. Which was changed from 1500 to 1436. So that TCP_WND = TCP_MSS = 1436.
This was done to avoid too much data management on the unit.
I have tested this both against our windows and linux server, and this works.
This issue is therefore resolved.
best regards,

Date: Mon, 10 Aug 2009 10:29:25 +1200
From: address@hidden
Subject: Re: [lwip-users] TCP transmission issue, with linux server.
To: address@hidden

In this particular case, packet 9 (from Linux) acknowledged the data your LWIP device sent in packet 8, so packet 10 does seem odd. The Linux system must have had some reason it wanted to send data at that point. Perhaps the application wrote the data in two or more separate write calls, and Linux decided to transmit some of it just before the last block was available.
Another possibile explanation: I note that your LWIP device is advertising a window size of 1500, and the Linux system sent 750 bytes. The fact that this is half the window size seems to be too much of a coincidence. Perhaps the Linux TCP/IP stack has a rule that it will never send a block of data which is greater than half the window size. You could test this by increasing your advertised window, e.g. to 3K instead of 1.5K.
IP reassembly won't  make any difference - you aren't getting IP fragmentation. This is a simple case of TCP sending a block of data which is less than MSS.
In general, your application should able to cope with receiving arbitrarily sized blocks of data via TCP, and reassembling received data as required if you need logical blocks of data of a certain size. There are many reasons why TCP might deliver data in blocks smaller than MSS.
----- Original Message -----
From: B B
Sent: Friday, August 07, 2009 9:04 PM
Subject: [lwip-users] TCP transmission issue, with linux server.

Hi all,
I am using 1.3.0 stable, and I am experiencing a problem, when my unit is communicating with a linux server.
I am using the netconn api and using the TCP protocol.
So far we have been running test up against a windows server, which have been trouble free.
The problem is that the windows server is sending MSS size frames to the unit, but the linux server is splitting the frames.
I have tried to enable ip reass. But this didn't help.
I have attached the packet capture. The problem is frame no. 10. This is an ack packet with 750 bytes data.
I would have expected it to be a PSH, ACK packet with 1436 bytes of data.
Has anyone encountered an simillar issue, or can anyone explain to me, why the linux and windows behave that differently and what a solution might be to this ?
best regards,

See all the ways you can stay connected to friends and family

reply via email to

[Prev in Thread] Current Thread [Next in Thread]