Extended udp sockets only send at max 512 bytes

I create am trying to receive large udp payloads, however the 0xCE api frame only ever has up to 512 bytes.

Socket creation process:

  1. Create new UDP socket with api frame 0x40
  2. Bind socket to port 4445 with frame 0x46
  3. wait for api frame 0xCE

Then on my host machine I send a sequence of bytes to that socket with:
echo {1…256} | nc -u xbee3 4445

I observe the packet leave in wireshark with Len=916

However when the 0xCE packet arrives, the frame only has a length of 522 (10 bytes for packet + 512 data).

The same behavior happens with TCP socket data received with 0xCD.

According to the documentation, these frames should be able to receive 1500 bytes at a time.

Am I missing something?


I’m assuming this is an XBee 3 Cellular LTE-M/NB-IoT module. The limitation of 512 bytes is (indirectly) called out in the documentation for the 0x20 TX IPv4 frame: https://www.digi.com/resources/documentation/Digidocs/90002258/#reference/r_frame_0x20.htm?Highlight=512

Long story short, the u-blox SARA-R410M-02B modem is limited to 512 bytes per “read” call, for either TCP/TLS or UDP. This is why you see the upper bound of 512.

1 Like

Thank you for pointing this out. That answers that mystery!

There is another thing i have questions about.
When doing what I described above over UDP I only receive 1 0xCE frame of 512 bytes with the sequence {1…155}.

If i then send another data to that socket
ie. echo “hello” > nc -p 12345 -u xbee3 4445
I receive two 0xCE frames; one of 404 bytes containing the sequence {156…256} and one of 6 bytes containing "hello

If I send a larger payload instead,
ie. echo {1…256} | nc -p 12345 -u xbee3 4445

I still receive two 0xCE frames; one for 404 bytes containing the sequence {156…256} and one containing 512 bytes {1…155}. With the remaining data being held until additional data is received.

This behavior does not happen over tcp and only happens when done from Host machine -> xbee3

If i send the same payload from one xbee3 to another or xbee3 -> host, it fragments correctly (512, 404) and two 0xCE frames are emitted.

This same behavior happens if i send “hello” from a different host machine than the one used to send the initial {1…256} which tell me that its not my host machine waiting to flush the second half.


Hi Mitch,

It looks like for memory efficiency reasons, the XBee 3 Cellular LTE-M firmware can only properly handle received UDP datagrams of up to 512 bytes in size - at least, right now. I will submit a ticket to potentially look at improving on that in the future.

In our experience most IoT application designs that use UDP don’t even use messages that are that large. Since you’re just using shell expansion right now, I’m guessing you’re only playing around. Do you have any particular UDP-based protocol in mind?