LoRaWAN: FRMPayload size validity #7459
Conversation
|
@0xc0170 The build failed for some reason. Could you restart ? |
| if (_ongoing_tx_msg.type == MCPS_PROPRIETARY) { | ||
| frm_payload_size = _params.tx_buffer_len; | ||
| } else { | ||
| frm_payload_size = _params.tx_buffer_len - LORA_MAC_FRMPAYLOAD_OVERHEAD; |
There was a problem hiding this comment.
overhead is a fudge factor for the get_max_payload having it pre-subtracted, so always needs to be applied, even for proprietary.
hasnainvirk
force-pushed
the
issue_7232_7432
branch
from
9af7bc1 to
df6a38a
Compare
|
@kjbracey-arm Please review again. |
hasnainvirk
changed the title
hasnainvirk
force-pushed
the
issue_7232_7432
branch
2 times, most recently
from
e87e73c to
b2bdf76
Compare
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.
timeout unit should be ms not micro second.
hasnainvirk
force-pushed
the
issue_7232_7432
branch
from
b2bdf76 to
ed9048f
Compare
|
@0xc0170 Need CI here. |
|
@hasnainvirk Will start shortly. We're looking into a test issue. |
|
/morph build |
Build : SUCCESSBuild number : 2590 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 2233 |
Test : SUCCESSBuild number : 2343 |
|
Pushing this out for 5.10. This PR's changeset is based off of this: #7430 |
LoRaWAN: FRMPayload size validity
Description
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 strip off the frame overhead from the payload length to get correct FRMPayload size and
hence do a successful comparison.
In order to have consistent frame overhead, we have opted to always include Port field in the
frame.
Pull request type