End device gets ack on transmission after it was deleted from loraserver

ChirpStack Network Server
1

I have got a little bit strange problem with my end device (using rn2483, latest firmware).

  1. The device joined the network and operates normally as intended.
  2. Some time later I delete the device from the loraserver.
  3. When the device transmits a new package (mac tx cnf 1 it will get back an ack from loraserver, even after the end device is not in the database any longer.
  4. I register the end device gets in loraserver again
  5. When the end device transmits I still do not get the packets, as expected.

Why is the loraserver answering with an ack after the end device was deleted ? I’d expect some info about no being joined any longer and being required to rejoin.

Further information:
I can restart lora-app-server and loraserver but the behaviour persists.

2

Are you running the latest stable version (LoRa Server v1.0.0)? In earlier versions, there was a bug and because of this, the device-session was not cleared.

3

I am running
loraserver 1.0.0-4-g316001a
lora-app-server 1.0.1-14-gf1bea3d
and
lora-gateway-bridge 2.4.1

4

Could you please try to reproduce the issue using the provided pre-compiled binaries?

5

Sure, tomorrow I will use the precompiled binaries.

6

I’ve tried to reproduce, but I’m unable to. When the device is activated, you will see the lora:ns:device:XXXXXXXXXXXXXXXX key in Redis. When you delete the device, this key is deleted from Redis. Without this key, LoRa Server is unable to authenticate the uplink frame as the security context is lost.

You can view all Redis keys using the redis-cli utility. See also: https://redis.io/commands.

7

Thank you. No acks coming back using the precompiled version. I will have a more thorough peek at it later.

Having a look at redis-cli I confirm the lora:ns:device:xxxxxxxxxxxx key gets deleted. What remains is a lora:ns:device:mac:pending:X key.

Now I only need to find out how to properly detect the deletion in my end device so it can conduct a new rejoin. I’ll probably trigger it after a certain amount of mac_err_tx (missing ack).

8

The lora:ns:device:mac:pending:X is not a problem. It will expire automatically and is only used when an uplink ACK is received on the related mac-command (e.g. to find out the requested data-rate on ADR). When you re-activate your device and the ADR engine kicks in, this key is overwritten before an ACK would happen :slight_smile: