Disable device whitelist on 1.4.6

[inigo fernandez]

Hello,

I’ve updated the firmware of my Conduit AEP to the 1.4.6 version. I would like to know if there’s some way to disable the device whitelist feature.

I have tried the following ways:
1- GUI. I didn’t find any option to do it
2- Modifying by hand the /var/config/lora/lora-network-server.conf file, putting “false” in the whitelist “enabled” option:
"whitelist" : {
"devices" : [
{
"appeui" : myAppEui,
"appkey" : myAppKey,
"class" : "A",
"deveui" : devEuiOfDevice
}
],
"enabled" : false,
"maxSize" : 2000
}

I’ve tried both with the lora-network-server running and while it was stopped (/etc/init.d/lora-network-server stop|start|restart), neither work.

3- Sending HTTP requests to modify the value of the “enabled” option, both with PUT and POST methods


admin@mtcdt:~# curl 127.0.0.1/api/loraNetwork/whitelist/enabled -X PUT -d '"false"' -H 'ContentType: application/json'
{
"code" : 400,
"error" : "path [loraNetwork/whitelist/enabled] leads to an incompatible element. Path Element Type [BOOL] Update Data Element Type [NULL]",
"status" : "fail"
}

admin@mtcdt:~# curl 127.0.0.1/api/loraNetwork/whitelist.enabled -X PUT -d '"false"' -H 'ContentType: application/json'
{
"code" : 400,
"error" : "Relative path [whitelist.enabled] does not lead to an element to update within model [loraNetwork]",
"status" : "fail"
}
admin@mtcdt:~#curl 127.0.0.1/api/loraNetwork/whitelist/enabled -X POST -d '"false"' -H 'ContentType: application/json'
{
"code" : 400,
"error" : "Path [whitelist/enabled] does not lead to an array",
"status" : "fail"
}
admin@mtcdt:~#curl 127.0.0.1/api/loraNetwork/whitelist.enabled -X POST -d '"false"' -H 'ContentType: application/json'
{
"code" : 400,
"error" : "Path [whitelist.enabled] does not lead to an array",
"status" : "fail"
}


on the other hand, the GET method works as expected:

admin@mtcdt:~# curl 127.0.0.1/api/loraNetwork/whitelist/enabled
{
"code" : 200,
"result" : true,
"status" : "success"
}


Is it possible to deactivate it somehow?

Thanks

[Jason Reiss]

With whitelist disabled how do you expect end-devices to join the network?

An empty whitelist would have the same effect as disable.

This will work.
admin@mtcdt:~# curl 127.0.0.1/api/loraNetwork/whitelist -X PUT -d '{"enabled":false}' -H 'Content-Type: application/json'

If using the NetworkID/NetworkKey end-devices are accepted regardless of whitelist as the end-device has the correct credentials.

Whitelist is a method to allow unique deveui/appkey pairs.

• This reply was modified 5 years, 11 months ago by Jason Reiss.
• This reply was modified 5 years, 11 months ago by Jason Reiss.

[inigo fernandez]

Thanks for the quick reply.

Devices implement the LoRaWAN 1.0 protocol, and they join the network via OTAA, using each their HardwareEUI as DevEUI, and common AppEUI and AppKey (shared, same for all end-devices). I’ve seen that sharing AppKey is not good practise, I’ll change it.

The OTAA join was working well with firmware 1.2.2; whitelist was active but empty. After updating to 1.4.6, the end-devices (the code on them didn’t change) were having trouble joining the network (the module said “denied”). I think the reason is the code they were using was trying to OTAA too often, without checking if they were already logged in (if there’s any LoRaWAN error, login again). It was not a good practice, but it worked: firmware 1.2.2 accepted the login if the network server already had a session tied to them. Apparently 1.4.6 is more strict, and it doesn’t always accept the logins of the devices when they already have an active session.

Making less join requests with an empty whitelist solved my issue. I guess sometimes devices don’t get accepted on the network because they’re using the same AppKey.

By the way, just for your information, the command you suggested doesn’t work either:

admin@mtcdt:~# curl 127.0.0.1/api/loraNetwork/whitelist -X PUT -d '{"enabled":false}' -H 'ContentType: application/json'
{
"code" : 400,
"error" : "path [loraNetwork/whitelist] leads to an incompatible element. Path Element Type [OBJECT] Update Data Element Type [NULL]",
"status" : "fail"
}
admin@mtcdt:~#

[Jason Reiss]

Header should use Content-Type
A hyphen was missing. I edited the original post.

[Jason Reiss]

It is better to have the whitelist enabled with an empty array.
A disabled whitelist will enable http requests to a remote join server.

[inigo fernandez]

Thanks for both clarifications

[Author]

Posts