Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ignore_frequency_for_deduplication setting as a stopgap #583

Closed

Conversation

danieroux
Copy link

For current data loss being experienced by us.

It defaults to false. If set to true, it will ignore the frequency on which the packets come in from the gateways. This allows a ghost packet to be gracefully collected as Just Another Packet to de-duplicate with.

Without this setting a ghost package gets in and overrides an established dev_addr. Leading to data being lost until the next JOIN request, with the edge device unaware that it has lost its JOIN status.

We have not been able to trace where the ghost JOINs come from. This stops those from being a problem for now.

…nt data loss being experienced

It defaults to false. If set to true, it will ignore the frequency on which the packets come in from the gateways. This allows a ghost packet to be gracefully collected as Just Another Packet to de-duplicate with.

Without this setting a ghost package gets in and overrides an established `dev_addr`. Leading to data being lost until the next JOIN request, with the edge device unaware that it has lost its JOIN status.

We have not been able to trace where the ghost JOINs come from. This stops those from being a problem for now.

- brocaar#557 (comment) is not what we are experiencing, our devices are far apart
- This fixes brocaar#566 for us
@brocaar brocaar closed this in 1b50594 Apr 27, 2022
@brocaar
Copy link
Owner

brocaar commented Apr 27, 2022

Thanks for taking the time to implement this workaround. However if possible, I would like to avoid merging workarounds. After digging a bit deeper in this, I might have found where the original issue comes from. As the device was not locked in the OTAA flow, there was a race-condition during which the same dev-nonce was accepted. This is fixed by the above commit. I have confirmed locally that when put the device antenna close to my gateway, that while two OTAA requests are received (1 + 1 ghost), only one is handled.

1 similar comment
@brocaar
Copy link
Owner

brocaar commented Apr 27, 2022

Thanks for taking the time to implement this workaround. However if possible, I would like to avoid merging workarounds. After digging a bit deeper in this, I might have found where the original issue comes from. As the device was not locked in the OTAA flow, there was a race-condition during which the same dev-nonce was accepted. This is fixed by the above commit. I have confirmed locally that when put the device antenna close to my gateway, that while two OTAA requests are received (1 + 1 ghost), only one is handled.

@brocaar
Copy link
Owner

brocaar commented Apr 27, 2022

Talking about ghost uplinks, GitHub posted my comment twice ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Duplicate dev_nonce's and data loss
2 participants