[riot-notifications] [RIOT-OS/RIOT] pkg/semtech-loramac: fix deadlock when sending unconfirmed messages (#11535)
notifications at github.com
Thu May 16 19:03:23 CEST 2019
One way you could do it is to read `McpsInd` flag from `LoRaMacFlags` variable (which [strangely is not static][loraflags]). This flag indicates that an `Indication` event will be trigger soon.
But in fact, the real problem is to use `Indication` event for confirming an uplink. I found some other potential bugs that can occur by doing so.
For example a single message (even `CONFIRMED`) we sent can produce two data responses if the LoRa server has two downlinks to make. It will send it a first downlink containing the first message data, an Ack and `FramePending` set to `true`. The `semtech_loramac` package will automatically make a second uplink (because of `FramePending`) and the LoRa server will send its second downlink. As `semtech_loramac_recv` now only returns when this second message is received, data from the first downlink will be lost.
Also, I noticed in LoRaMAC-node source code that there is a case where `Indication` [event is not called][ind-skip] (even with `CONFIRMED` message). It happens when the LoRa server send again a `CONFIRMED` downlink because it didn't received an Ack from the device. In that case, the application will be stuck forever on `semtech_loramac_recv`.
One way to solve all of these problems is to use `Confirm` event (and not `Indication` event) to confirm that an uplink has been sent, as expected by LoRaMAC-node.
For handling downlink data, we can imagine that the application could define a receiving thread or a function called when a downlink message arrives (triggered by `Indication` event from LoRaMAC-node). That's what is done in [GNRC LoRaWAN][gnrc].
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications