FreeRTOS + lwIP TCP sending more bytes

I am using FreeRTOS with lwIP. It is working properly. I am able to send from the ZCU104 to a PC via Ethernet messages. However, when I send a large buffer (>1500) I can see it on wireshark that the package is split. The issue is that I am sending 1500 bytes and I can see two pacakges. One with 1446 bytes and the other one with 130, meaning I have 76 extra bytes.This is the code I use:

unsigned char mybuffer[1500];
for(int a=0; a<1500; a++)
     mybuffer[a] = 0x12;
n = lwip_write(publisher->subscribers[publisher->requestTopic].socket_to_SEND_fd, mybuffer, 1500);

To make sure what is being sent, I hardcoded what I am sending with a known value (0x12). The first 1446 bytes are 0x12, however, the remaining ones are:

12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12
12 12 12 12 12 12 48 00 00 00 cc cc cc cc cc cc
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cd cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc cc cc cc cc cc cc cc cc cc ec cc cc cc cc
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
cc cc

These are the remaining 130 bytes, where the first 54 ones are the 0x12 as expected. Then, the rest you can see 48 00 00 00 which is in little endian which is 0x48=72, the number of extra bytes that I have (plus these 4 bytes to specify the “extra” bytes). Regardless the number of bytes I send, I always get these 72 extra bytes. Why is that? How can I avoid these extra bytes and just send the number of bytes that I want?

Thanks

lwIP is not [edit](mistakenly wrote ‘now’ instead of ‘not’)[/edit] our code, and I’ve not used it in a long time, so I would like to suggest posting your question to the lwIP mailing list rather than the FreeRTOS forum might solicit a more knowledgeable answer. It is not really clear what your question is though - is it just that the data is split into two packets - which would be expected using any TCP stack - or that you see junk at the end of the packet?

This mailing list you mean?

It is that the second packet adds more bytes that it should, which is with junk. As it has more bytes than it should, my receiving end complains that I am sending extra bytes and does not do what it should with the data but drops it and I cannot proceed. In fact, it complains I have 72 extra bytes.

This list also looks pretty up-to-date: https://savannah.nongnu.org/bugs/?group=lwip

It is normal of course that the 1500 bytes will be transmitted in two transfers, but it is indeed strange that an extra 72 bytes are appended. Are you using lwIP on both ends?

I am using a PC with linux on the receiving end (ROS, which is well tested). I have the feeling I read something about padding so there is a 32 byte alignment of data (I cannot find that again).

Yes it also made me think of padding, but your TCP packets are both long enough: they do not need padding.

I haven’t heard about a 32-byte alignment.

Can you attach a (zipped) PCAP file that shows the conversation?

I cannot upload files as I am a new user. However, it is uploaded here: https://we.tl/t-qFSmWBqwwD

Thanks for the help @htibosch !

it is uploaded here

Thank you. Yes strange, the 1500 bytes are sent plus an extra 72 bytes.

Ethernet packets smaller than 64 (or 60) bytes will be padded. The pad bytes are normally all zero and they’re not included in the length fields.
Your second packet says: 130 bytes, which includes the extra bytes.

In your case, none of the packets need padding.

Are you using the latest stable release of lwIP? And if so, you could contact them and ask for help.

I am running lwIP v1.4.1

You might want to try their latest 2.1.1 release before complaining.

Good luck with it.

Problem solved. lwIP was sending the correct number of bytes. I found another bug which affected this.

Thanks @htibosch for the help.

I’m gad that you’ve solved the problem, and thanks for reporting back.

I’m always curious what caused the problem, and how you’ve solved it, even if it was a stupid typo. Could you write that? It might help other people who face the same problem.

Thanks, Hein

I had to send the first 4 bytes the total amount of bytes that would follow. My error was that I was sending those 4 bytes with the wrong amount. Completely unrelated to lwip

Thanks for telling this. It can always be helpful for others who are on the same track.
Regards, H