Avoid duplicate uplink sequence numbers when receiving bad MIC or add… #22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ress in confirmed transmits. If during a confirmed message transmission we receive a downlink frame with either an address not matching ours, or an incorrect MIC, control is returned to the user application with an error status, and the upLinkCounter is not incremented. Thus, the next uplink frame is sent with the same sequence number, and likely discarded by the receiving server. The fix involves discarding the invalid downlink and continuing the retransmission of the uplink frame until either a downlink response/ack is received, or the retry count is reached.
|
Note this patch also applies to Release 3.3. |
|
Calling the rx2 timer callback will not have the correct timing. The window will be opened when the timee r expires. |
|
We will investigate the issue. |
|
Hi Jason, yes, good point - the rx isn't really needed, but it makes sure all the proper callbacks get invoked. Regards, |
added 2 commits
November 4, 2015 16:53
…when receiving bad MIC or address in confirmed transmits." This reverts commit 50e057a.
The uplink counter would not be incremented if, during a confirmed uplink transmission, the mac receives a frame with an invalid address or mic error. In addition, no further retransmissions would occur after such a downlink. This change should address the above two issues.
|
May we ask you to follow the coding conventions in place. Please use spaces instead of TAB characters. Your modification should look like to the following: }
else
{
/*
* For confirmed uplinks, ignore MIC and address errors and keep retrying.
*/
if( ( LoRaMacEventInfo.Status == LORAMAC_EVENT_INFO_STATUS_MIC_FAIL ) ||
( LoRaMacEventInfo.Status == LORAMAC_EVENT_INFO_STATUS_ADDRESS_FAIL ) )
{
AckTimeoutRetry = true;
}Instead of: } else {
/*
* For confirmed uplinks, ignore MIC and address errors and keep retrying.
*/
if ((LoRaMacEventInfo.Status == LORAMAC_EVENT_INFO_STATUS_MIC_FAIL) ||
(LoRaMacEventInfo.Status == LORAMAC_EVENT_INFO_STATUS_ADDRESS_FAIL)) {
AckTimeoutRetry = true;
}Once we have tested this fix we will merge it. Thanks. |
|
Sure, no problem. Thanks, |
|
Applied on V3.4.1 version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…ress in confirmed transmits.
If during a confirmed message transmission we receive a downlink frame with either
an address not matching ours, or an incorrect MIC, control is returned to the user
application with an error status, and the upLinkCounter is not incremented. Thus,
the next uplink frame is sent with the same sequence number, and likely discarded
by the receiving server.
The fix involves discarding the invalid downlink and continuing the retransmission
of the uplink frame until either a downlink response/ack is received, or the retry
count is reached.