LoRaWAN LoRaMac::schedule_tx compares wrong length in call to validate_payload_length

[garycolecd]

Description

In LoRaWAN the method LoRaMac::schedule_tx passes the MAC Payload length to validate_payload_length, causing the LoRaInterface::send to return with LORAWAN_STATUS_LENGTH_ERROR. It should pass in the length of the application payload.

Found in mbed-os-5.9.0

[ ] Question
[ ] Enhancement
[X] Bug

[hasnainvirk]

@garycolecd Can you please elaborate a little ? What data-rate you were using, what was the length of your packet ?

My wild guess is that this is not a bug. You are either trying to send more than the data-rate would allow or you are absolutely at the brink of being maxed out and there are some MAC commands pending.

Please bear in mind a few things:

• LoRaWAN packets are like datagrams (until now there is no fragmentation/sequencing defined by the spec)
• You cannot send more than the data-rate/SF setup for you.

It's recommended to leave a bit of slack for MAC commands (I am not sure about the exact number, but I think its 21 bits).

[garycolecd]

I discovered the issue transmitting 11 bytes at DR0. The method validate_payload_length reads from a region specific table (US915) that includes the application payload lengths, in which 11 is the limit (without MAC command data). The method LoRaMac::schedule_tx passed in the MAC payload length of 24 bytes in the variable tx_buffer_len and the method validate_payload_length looked up the DR0 limit of 11. The variable tx_buffer_len starts with the application buffer len, then gets updated with the FHDR and FPort length.

I did verify that no MAC command data was being sent, so the 11 bytes are available to the application.