Console & CLI flush pending confirmed downlink from MAC state

[descartes]

Summary

If firmware has a remote "reboot" command and the operator sends this as a confirmed downlink, both the device & stack end up in a perpetual loop as the downlink doesn't get ack'd so the stack resends the downlink, repeat ...

Why do we need this?

So when an operator fails to follow instructions, we can get them out of the mess

What is already there? What do you see now?

I tried adding a downlink to the queue with replace - didn't clear the expected ack, wasn't really expecting it to. I tried a reset with --mac-state.pending-application-downlink but that didn't do what we needed I tried resetting the MAC state but that means the join session was lost & we had to wait for the device to realise it was offline.

What is missing? What do you want to see?

CLI option to flush the entire downlink state

This may exist but I can't see which field is the way to go

Environment

TTS CE

How do you propose to implement this?

Sorry, above my pay grade

How do you propose to test this?

Once it's implemented

Can you do this yourself and submit a Pull Request?

No

[neoaggelos]

Hi @descartes,

Can you check if the following command does the trick:

$ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink

[descartes]

Will do - will need to setup a test device so will be a couple of days

[neoaggelos]

Closing the issue, please re-open if https://github.com/TheThingsNetwork/lorawan-stack/issues/4289#issuecomment-865297441 does not solve your issue.

[descartes]

@neoaggelos, forum poster speeded me up, tested, all good, thanks.

[jpmeijers]

Description

I had a similar issue where an end device did not acknowledge the downlink, even though it received it. It's a COTS device, so I do not know which LoRaWAN stack they are using. But it seems like there is a bug where it does not handle confirmed downlinks.

I ended up having a confirmed downlink being sent after every single uplink.

My expectation was that if I clear the downlink queue using ttn-lw-cli device downlink clear, or sending a new downlink from the console while choosing "replace", it will stop sending the original confirmed downlink. It did not.

Forum search later found these two comments by @descartes: https://www.thethingsnetwork.org/forum/t/how-to-clear-downlink-queue-programmatically/49212/6 https://www.thethingsnetwork.org/forum/t/abp-disable-mac-sending-of-commands/51276/26

So I did a: ttn-lw-cli device set --application-id redacted --device-id redacted --unset mac-state.pending-application-downlink

I'm waiting for the device to send another uplink to confirm this worked, but the description by other users indicate this is the cause for the problem I am seeing.

Request

For me it does not make sense to have two commands to clear downlink messages. Shouldn't the standard downlink queue clear command also clear the mac state pending downlink?

[jpmeijers]

Closing the issue, please re-open if #4289 (comment) does not solve your issue.

Please re-open. We don't have permissions to do it ourselves.

[jpmeijers]

$ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink

I've tried this again now, and it does not seem to clear the stuck confirmed downlink message.

1. Device sends uplink, downlink is queued.
2. I run the command in cli and see "Update end device ["network_server_address"]" in the console.
3. The device sends an uplink and the downlink is queued again.

[nicocarv]

Hello,

We had the same issue, the following command doesn't do the job: $ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink

[adriansmares]

Hello,

We had the same issue, the following command doesn't do the job: $ ttn-lw-cli dev set $application $device --unset mac-state.pending-application-downlink

The commend that you have quoted and the command which you have ran are different - are you sure you ran the one you quoted ?