Ask Your Question

Revision history [back]

Frames above 2000 bytes not acknowledged by receiver

I working on adding a jumbo frame functionality to my application. My problem is that I receive no ACK for frames with payload above 2000 bytes. My system looks as follows: the server sends requested measurement time to the client. The server side is an ARM processor with lwip implementation of tcp/ip stack and with enabled support of jumbo frames. The client side is a Python script on my PC with network interface having jumbo frames enabled.

With configuration as above and payload above default 1460 system works fine. I do run with payload of 2000 bytes without problems. The MSS on client side is 9158, WIN 64320. The server side is: MSS 2000 and WIN 8000. However, once I increase the MSS on server side above 2000 bytes communication collapses. On Wireshark I can see that first frame with length above 2000 doesn't get acknowledged by the client (PC side) and re-transmissions begin. The client and server are connected directly without a switch. I cannot upload a Wireshark file since I am a new member.

I will be thankful for any advice from experienced users. It looks to me that jumbo frame shouldn't be an issue, since I operate way above standard ethernet payload size without problem.

Thank you in advance.

Frames above 2000 bytes not acknowledged by receiver

I working on adding a jumbo frame functionality to my application. My problem is that I receive no ACK for frames with payload above 2000 bytes. My system looks as follows: the server sends requested measurement time to the client. The server side is an ARM processor with lwip implementation of tcp/ip stack and with enabled support of jumbo frames. The client side is a Python script on my PC with network interface having jumbo frames enabled.

With configuration as above and payload above default 1460 system works fine. I do run with payload of 2000 bytes without problems. The MSS on client side is 9158, WIN 64320. The server side is: MSS 2000 and WIN 8000. However, once I increase the MSS on server side above 2000 bytes communication collapses. On Wireshark I can see that first frame with length above 2000 doesn't get acknowledged by the client (PC side) and re-transmissions begin. The client and server are connected directly without a switch. I cannot upload a Wireshark file since I am a new member.

I will be thankful for any advice from experienced users. It looks to me that jumbo frame shouldn't be an issue, since I operate way above standard ethernet payload size without problem.

The cloud shark link (with tcp filter): https://www.cloudshark.org/captures/5bf2180b65cf?filter=tcp

Thank you in advance.

click to hide/show revision 3
None

Frames above 2000 bytes not acknowledged by receiver

I working on adding a jumbo frame functionality to my application. My problem is that I receive no ACK for frames with payload above 2000 bytes. My system looks as follows: the server sends requested measurement time to the client. The server side is an ARM processor with lwip lwIP implementation of tcp/ip TCP/IP stack and with enabled support of jumbo frames. The client side is a Python script on my PC with network interface having jumbo frames enabled.

With configuration as above and payload above default 1460 system works fine. I do run with payload of 2000 bytes without problems. The MSS on client side is 9158, WIN 64320. The server side is: MSS 2000 and WIN 8000. However, once I increase the MSS on server side above 2000 bytes communication collapses. On Wireshark I can see that first frame with length above 2000 doesn't get acknowledged by the client (PC side) and re-transmissions begin. The client and server are connected directly without a switch. I cannot upload a Wireshark capture file since I am a new member.

I will be thankful for any advice from experienced users. It looks to me that jumbo frame shouldn't be an issue, since I operate way above standard ethernet Ethernet payload size without problem.

The cloud shark link (with tcp filter): https://www.cloudshark.org/captures/5bf2180b65cf?filter=tcp

Thank you in advance.