Home/Support/Support Forum/How to get correct MTU size for LTE Cat-1 UDP packets

How to get correct MTU size for LTE Cat-1 UDP packets

0 votes
I am trying to UDP stream a bunch of 64 data packets very fast using a cellular xbee. The xbee is combining my 64 bye packets together to create a larger packet...which is fine, however, the data portion of the packet is 1500 bytes which larger than the allowable value of 1472 for a network (28 is reserved for the header info) with a MTU of 1500 bytes. As such, my linux kernel is outputting a bunch of errors which look like 'UDP, bad length 1500 > 1472' and is dropping the packets. anyone run into this before? I think I need to lower the MTU on the xbee, but I don't see a way to do this directly from the xbee firmware. Perhaps go into bypass mode and using the telit AT commands to change the MTU to something like 1400???? But will that value get saved?

Any help would be appreciated.
asked Sep 25, 2019 in XBee Cellular by JRDavisuf New to the Community (0 points)

Please log in or register to answer this question.

1 Answer

0 votes
Are you using transparent mode, API mode, or MicroPython?

It sounds like you are using transparent mode, since you claim the XBee is combining the packets together to make a single larger packet. If this is the case, then I would suggest you use API mode instead if that is possible, since with API mode you can control the size of the UDP packets more precisely. Transparent mode is really designed as a serial line replacement tool; I assume you are using transparent mode because if the ATRO "packetization timeout" is not observed between your 64-byte packets, the XBee treats the input as a single datagram.
answered Sep 26, 2019 by tckr Veteran of the Digi Community (368 points)
Yes, sorry, should have mention that I'm trying to do this the easy way :) ... aka transparent mode.

I am observing the ATRO time.  In fact, just now for testing, I put in a 5ms delay (smaller times didn't seem to affect things much) before I put a packet on the UART.  At 115200 baud, this should be well above 3 character times (< 1 ms)...And my packets are still being combined together...although now they are averaging about 1000 bytes, which does fix my > 1500 byte problem reasonably well.

To get actual the UDP packet to be the actual size of the data packet I'm putting on the UART, I need to drop by Sample Rate to 8 hz.

So at this point, I'm not sure that ATRO is actually doing anything at all.

I'll look into the API mode, however, I'm not entirely clear on where the packet combining is happening since the ATRO doesn't seem to be adhered too...such that, I could see the API mode combining packets too if its the actually cellular chip that's combining things packets together.
I'm not sure why you're observing the ATRO behavior that you are reporting, but the only things which influence how data is grouped together in transparent mode are ATRO (silence time), ATTD (text delimiter - should be set to 0 in your case, which is the default), or, if there is no silence time seen, then reaching the maximum size for a packet, which for UDP in our system is 1500, OR finally we will send the "packet" if you enter command mode using +++. (Of course, respecting guard times for the +++ escape sequence will likely trigger the RO timeout anyway.)

Using API mode will completely prevent the packet combining. When using transparent mode, to send, let's say, "hello" to port 0x5678, you need to configure:
- ATAP 0
- ATIP 0
- ATDE 5678
then send in "hello" and wait at least the ATRO silence time.

In API mode, you would send a complete API frame that contains all of that information, including the size of the payload, as follows:

7E 00 11 20 01 0B 16 21 2C 56 78 00 00 00 00 48 65 6C 6C 6F AE

You can use XCTU's Frames Interpreter to parse that frame, but rest assured that API frame says to send "hello" to port 0x5678.

Hopefully from this information you can see why I pointed out that transparent mode is designed as a serial line replacement tool.

If you find that using API mode as described here still results in large/too-large UDP datagrams arriving at your server, then there must be some server or network equipment between the XBee and your server recombining datagrams.