Native Ethernet UDP Packet Size

DaniO

Member
I'm trying to send 4098 byte packages over UDP. Packages with 2048 bytes or less arrive without a problem, but when I try to send larger packages they get truncated. The first 2048 bytes arrive and the rest disappears. I've adjusted the packet size in my script on the PC side and I tried to adjust the socketSize on the Teensy 4.1 using:

Code:
Ethernet.setStackHeap(1024 * 64); 
Ethernet.setSocketSize(1024 * 4); 
Ethernet.setSocketNum(6);
Ethernet.begin(mac);

Does anyone have an idea how to solve this?

Alternatively a less ideal solution is to break the 4098 byte package into smaller packages, however than I must be able to distinguish the different packages from each other on the receiving side. What would be a good way to do this?
 
Ethernet MTU is usually 1500 so I'm surprised even 2048 works.
Sequence and part numbers?
 
OK interesting, do you know how I can change the MTU?

Sorry I'm new to network communication, what do you mean by sequence and part numbers?

Thanks.
 
The MTU is the hardware limit...

Split your data into packets, each packet prefixed by a message sequence number and a part number, like
0,0 first part of message 0
0,1 second part of message 0
1,0
1,1
2,0
2,1

Then you can reassemble the partial packets correctly (and as a side-benefit fix duplicate and out-of-order delivery if you want - UDP does not
guarantee anything about delivery).
 
While the MTU is limited to 1500 bytes the stack supports IP Fragmentation so the MTU size isn't the actual limit to how big a packet can be by the time it reaches the user sketch. The config right now is setup for a max ip packet size of 32kB but the absolute max it can be set to is 64kB-1 or max unsigned 16 bit integer.

Considering you said it gets truncated to 2048 I went and looked to try and see why, I did find a bug that would truncate the UDP transmit to 2048 but it did not truncate the receive side. Though if you were trying to echo the data back to your PC script I can see why it would be truncated there. I committed the fix for the transmit so update the library and see if it fixes for you: https://github.com/vjmuzik/NativeEthernet
 
Hmm, I'd still be worried IP fragmentation isn't handled well - it looks complicated (IPv4 v. IPv6 issues) and its probably more reliable to avoid it, especially for UDP.
 
I can’t speak for how well it’s handled since I didn’t write it, but it’s a standard that’s been in use and supported for many years now so I suspect any issues have been ironed out. Personally I wouldn’t be worried about it wether for UDP or not, if your solution is to split a larger packet up into several smaller ones then that’s practically the same thing that IP fragmentation will already do for you automatically.
 
Its standard for full blown operating system TCP/IP stacks, that's not the same as being supported on
microcontrollers - corners are often cut on less resource-rich hardware (for instance its not considered a
problem on a full blown computer to dedicate a few megabytes to extra buffers in a device handler).

The ratio of available memory between a full blown computer and microcontroller is typically between
4 and 7 orders of magnitude...
 
Memory constraints can certainly be a concern, though as far as corners being cut I can't say what decisions were made for FNET, I just know that I haven't had any prior issues with using larger sockets as a result of IP fragmentation being turned on so I see no reason not to use it.
 
Back
Top