Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Native Ethernet UDP Packet Size

  1. #1
    Junior Member
    Join Date
    Jun 2021
    Posts
    7

    Native Ethernet UDP Packet Size

    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?

  2. #2
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,235
    Ethernet MTU is usually 1500 so I'm surprised even 2048 works.
    Sequence and part numbers?

  3. #3
    Junior Member
    Join Date
    Jun 2021
    Posts
    7
    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.

  4. #4
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,235
    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).

  5. #5
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    822
    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

  6. #6
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,235
    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.

  7. #7
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    822
    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.

  8. #8
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,235
    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...

  9. #9
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Posts
    822
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •