LoRaWAN LoRaMac::schedule_tx compares wrong length in call to validate_payload_length #7232
Comments
|
@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:
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). |
|
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. |
It was pointed out in ARMmbed#7432 and ARMmbed#7232 that the stack was comparing frame payload size with the allowed payload size in a wrong manner in shcedule_tx(). We must strip the overhead from the frame before comparison. We did have a similar check in prepare_ongoing_tx() API which would correctly analyse the situation but a check was needed in schedule_tx() as well. The reason is that the schedule_tx() API can be called automatically by the stack if the user intiated requested was not promptly entertained because of duty cycle restriction. Now, the datarate can change here (for CONFIRMED messages if the ack was not received after retries max out). That's why a test for validity was needed. We now perform a comparison using _ongoing_tx_message structure which contains the actual FRMPayload size. For proprietary type of messages only MHDR and Port field is used so we shouldn't add MAC commands and other overhead into them. In order to have consistent frame overhead, we have opted to always include Port field in the frame.
It was pointed out in #7432 and #7232 that the stack was comparing frame payload size with the allowed payload size in a wrong manner in shcedule_tx(). We must strip the overhead from the frame before comparison. We did have a similar check in prepare_ongoing_tx() API which would correctly analyse the situation but a check was needed in schedule_tx() as well. The reason is that the schedule_tx() API can be called automatically by the stack if the user intiated requested was not promptly entertained because of duty cycle restriction. Now, the datarate can change here (for CONFIRMED messages if the ack was not received after retries max out). That's why a test for validity was needed. We now perform a comparison using _ongoing_tx_message structure which contains the actual FRMPayload size. For proprietary type of messages only MHDR and Port field is used so we shouldn't add MAC commands and other overhead into them. In order to have consistent frame overhead, we have opted to always include Port field in the frame.
It was pointed out in ARMmbed#7432 and ARMmbed#7232 that the stack was comparing frame payload size with the allowed payload size in a wrong manner in shcedule_tx(). We must strip the overhead from the frame before comparison. We did have a similar check in prepare_ongoing_tx() API which would correctly analyse the situation but a check was needed in schedule_tx() as well. The reason is that the schedule_tx() API can be called automatically by the stack if the user intiated requested was not promptly entertained because of duty cycle restriction. Now, the datarate can change here (for CONFIRMED messages if the ack was not received after retries max out). That's why a test for validity was needed. We now perform a comparison using _ongoing_tx_message structure which contains the actual FRMPayload size. For proprietary type of messages only MHDR and Port field is used so we shouldn't add MAC commands and other overhead into them. In order to have consistent frame overhead, we have opted to always include Port field in the frame.
Uh oh!
There was an error while loading. Please reload this page.
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
The text was updated successfully, but these errors were encountered: