Whitelist vs Node-list vs Session list

[Ismo Penttinen]

Devices are whitelisted in lora-network-server.conf.

When we are clearing node-list with lora-query utility, devices are still sending messages and lora-network server sends acks to devices. Vise versa lora-network-server logs failed message (session keys)…

How we reset session-keys?…

yrs.
Ismo

[Ismo Penttinen]

And we have 2.0.19 lora-network-server. We have also cleared session list.

We are wondering why lora-network-server send acks? our device will rejoin if there is no ack in /up/ -message.

yrs.
Ismo

[Jason Reiss]

What commands are used to clear the list?
Can you show failed message (session keys)? What is failed?
What end-device is being used?

[Ismo Penttinen]

There are devices in three different lists:
* node-list, lora-query –node-list
* session-list, lora-query -x session list
* device-list, lora-query -x device list
* whitelist in configurations /var/config/lora/lora-network-server.conf

How to add device with whitelisting?
how to remove device with whitelisting?

Now lora-query -x device add … does not add device to lora-network-server configuration’s whitelist.

I assumed that if there are no devices in session list. There should not become log like this:

7:10:40:371|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
7:10:40:371|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|CRC-ERROR
7:10:41:705|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
7:10:41:708|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-27-80-f5 VALUE: 45

• This reply was modified 6 years, 9 months ago by Ismo Penttinen.

[Jason Reiss]

The whitelist provides unique DevEUI/AppKey pairs (Authentication), the device list provides known devices joined via whitelist or NetworkID/NetworkKey AppKey authentication (Registration), and the session list contains DevAddr, keys and counters (Activation).

The whitelist of devices is not dynamic, there are no commands to add device records, it is part of the configuration of the network server, it is a static list. This way all registration information DevEUI/AppKey and NetworkID/NetworkKey (Authentication) used for devices to join the network is kept separate from the dynamic information in the database (Registration, Activation).

With AEP firmware devices can be added to the whitelist through the GUI. In mLinux they can be added to the configuration manually.

The log looks correct for a system with no devices. I would expect all packets to contain unknown device addresses.

[Ismo Penttinen]

Hi.

if you add a device only to configuration whitelist. Is it enough or do you have to add them manually to session and to devicelist ???

And if you remove a device from Whitelist. do you have to remove it from session and devicelists.

yrs.
Ismo

[Ismo Penttinen]

And we are using mlinux.

It seems once, that lora-network-server sent ack -signal to the device, which was not in session list …

[Ismo Penttinen]

Problems still exists… if device is whitelisted, lora-network-server does not send join-accepted message… we have 50 devices, 20 did not get join-accepted.

[Ismo Penttinen]

11:16:33:958|WARNING| Response packet dropped, could not schedule : 02-cb-a9-3d
11:16:33:959|WARNING| Cannot unschedule join response, tossing packet

[Jason Reiss]

How many devices are trying to join at once?
Do they retry after a failed join attempt?
Is the retry successful?

[Ismo Penttinen]

hi.

We have six devices.

It seems that lora-network-server keeps device sessions alive, although we have deleted the device from whitelist and restarted lora-network-server.

The do not retry cause lora-network-server sends ack to they messages.

yrs.
Ismo

[Jason Reiss]

The session is a DevAddr (4-bytes) sent in each packet, session keys and counter values. If the end-device knows the DevAddr, sessions keys and counters by creating a valid packet with authenticated MIC it will be accepted by the network server.

To remove a device from the network server list of joined devices remove the session or the device using lora-query. Either method should cause the

# lora-query -x device delete <DEV-EUI>
or
# lora-query -x session delete <DEV-EUI>

Backup the database to force a write to flash. The database is backed up periodically, on restart of the network server or a soft reboot. If changes are not backed and power is lost, i.e. plug pulled, the device will return from the old backup.

# lora-query -x database backup

The whitelist is a set of credentials DevEUI/AppKey for end-device to join the network via OTAA. If an end-device sends a Join Request using the DevEUI and the associated AppKey with authenticated MIC it will be accepted by the network server and a session will be created for the device. The NetworkID/NetworkKey can also be used to authenticate a Join Request.

To dis-allow a device from joining via OTAA remove the DevEUI/AppKey from the whitelist or change the NetworkID/NetworkKey, depending on the method used by the end-device to join the network.

For more detailed information about OTA join and LoRaWAN sessions please refer to the official specifications.
https://lora-alliance.org/resource-hub

Please let us know if you have further questions.

[Ismo Penttinen]

We have still problems….

suddenly lora-network-server started to fill log with:
12:40:7:52|WARNING| NULL message pulled from mqtt queue

and in the end, lora-network-server stopped to communicate with devices. We reboot Conduit and communication started…

There was also messages that queue was full. We tried to clear queue with /lora/<deviceid>/clear mosquitto topic.. no success..

and question: why command “lora-query -x packet queue ” shows messages to be queued with old timestamp. If you tried to delete these records with mosquitto topic, no success. But if you use:

lora-query -x packet queue delete 37-41-50-0d-00-65-00-60

queue record is removed…

We have 40 devices connected, but it seems that it is too much for Conduit… sad.

We are using mosquitto to connect lora-network-server.

[Jason Reiss]

Was the topic exactly as posted? ‘/lora/<deviceid>/clear’
It should be ‘lora/<deviceid>/clear’ without the initial ‘/’ character.

If queue_full is being seen there are more downlinks being scheduled than can be sent. The gateway is able to received up to 8 packets at a time but can send only one.

How often are uplinks being sent from the end-devices?
How often are downlinks expected to be sent to the end-device?
Are ACK’s being requested in the downlink?

• This reply was modified 6 years, 9 months ago by Jason Reiss.

[Ismo Penttinen]

without / and tried lora-query too… still problems..

We are now testing with 6 devices…

Now lora network is jammed. Lora-network-server log:
– lora-network-server restarted
– mosquitto restarted
– conduit restarted…

9:28:26:80|INFO| GW:00-80-00-00-a0-00-20-80|UDP-TX|JSON-SIZE:312
9:28:26:83|WARNING| GW:00-80-00-00-a0-00-20-80|TX-ACK|ERROR: {“txpk_ack”:{“error”:”TOO_EARLY”}}
9:28:34:109|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
9:28:34:123|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 02-8f-33-88 VALUE: 45
9:28:37:973|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
9:28:37:979|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-f9-56-48 VALUE: 45
9:28:40:417|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
9:28:40:577|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-1f-ac-83 VALUE: 45
9:28:51:672|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
9:28:51:675|INFO| ED:37-41-50-0d-00-48-00-44|CHECK-PKT|FCNT: 00000004 LAST-FCNT: 00000004 Duplicate: yes
9:28:51:675|INFO| ED:37-41-50-0d-00-48-00-44|CHECK-MIC|ADDR: 03-44-fa-e1 passed
9:28:51:675|INFO| ED:37-41-50-0d-00-48-00-44|PER|0.000000%
9:28:51:676|INFO| ED:37-41-50-0d-00-48-00-44|FCTRL|ADR:1 ADRACK:0 ACK:0 CLASS:A OPTS:0
9:28:51:676|INFO| ED:37-41-50-0d-00-48-00-44|SCHED-TX|Use RX1 TOA:255 ms
9:28:52:432|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-TX|IP: 127.0.0.1:49856 CH: LC2 DEV: 03-44-fa-e1 FCNT: 0000000c REPEAT: 0
9:28:52:436|INFO| ED:37-41-50-0d-00-48-00-44|SCHED-TX|Q-SIZE: 1 PKT-ROOM: 115
9:28:52:445|INFO| Update DC Band: 1 Duration: 205 time-on-air available: 390 ms
9:28:52:445|INFO| GW:00-80-00-00-a0-00-20-80|UDP-TX|JSON-SIZE:312
9:28:52:449|INFO| GW:00-80-00-00-a0-00-20-80|TX-ACK|OK
9:28:58:382|INFO| GW:00-80-00-00-a0-00-20-80|FRAME-RX|Parsing 1 packets
9:28:58:386|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 02-8f-33-88 VALUE: 45

mosquitto_sub -v -t “#”:
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)
lora/37-41-50-0d-00-54-00-60/queue_full (null)
lora/37-41-50-0d-00-54-00-60/clear (null)

[Ismo Penttinen]

and… after clearing whitelist… and restarting lora-network-server:

we have 5. devices.

2 pc tries join..

and 3 devices:

10:23:24:172|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-44-fa-e1 VALUE: 45
10:23:35:704|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-f9-56-48 VALUE: 45
10:23:48:835|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-44-fa-e1 VALUE: 45
10:24:0:364|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON: Message received from unknown device 03-f9-56-48 VALUE: 45
10:24:13:494|WARNING| GW:00-80-00-00-a0-00-20-80|FRAME-RX|REJECTED|REASON:

why i can see these??.. there are no sessions…

[Piia]

Hi!

We have still problems with lora network server 2.0.19.

First we aren’t able to clear lora device queue with mqtt: ‘/lora/<deviceid>/clear’. This doesn’t work. We have to use lora-query -x .. utility.

Second lora network server crashes sometimes. E.g. yesterday it crashed and the last lines from lora network server log:

21:12:11:420|WARNING| Device queue is full
21:12:11:424|WARNING| Device queue is full
21:12:11:434|WARNING| Device queue is full
21:12:12:711|WARNING| Device queue is full
21:12:12:873|WARNING| Device queue is full
21:12:12:907|WARNING| Device queue is full
21:12:12:914|WARNING| Device queue is full
21:12:12:948|WARNING| Device queue is full
21:12:12:952|WARNING| Device queue is full
21:12:13:168|WARNING| Device queue is full

Problem seems to be that already whitelisted devices won’t join properly after lora network server crashes and is restarted. Devices send join request but lora network server won’t send join accept.

“Problems still exists… if device is whitelisted, lora-network-server does not send join-accepted message… we have 50 devices, 20 did not get join-accepted.”

How we can fix this?

Regards Piia

[Jason Reiss]

Piia, can you open a ticket at support.multitech.com and share a full log and configuration.

I can recreate the issue with clearing the queue via MQTT.

How often does your application queue messages for downlink?

[Author]

Posts