Devaddr got only 8bytes, wondering if it's enough

[yzk0281]

Devaddr got only 8bytes and each nodes need a unique Devaddr,
what if 8 bytes is not enough for all the nodes？

[yzk0281]

sorry, typo
only 4 bytes

[ivajloip]

Hi,
It actually has less as some bits are used for netID. As far as I know, the LoRa alliance says that this is not a problem as the real identification of the end-device is not only by DevAddr, but also by NwkSKey, which greatly increases the number of possibilities. I hope this reassures you :)

[yzk0281]

@ivajloip
Do you mean that different nodes could have the same DevAddr?

[ivajloip]

That's my understanding. Note that currently the implementation does not support this.

[yzk0281]

@ivajloip , I agree with you.
@brocaar In loraserver, we can see redis keys like "node_session_00983e58", if different nodes have same DevAddr then they'll have the same redis key, thus will cause problems.
Maybe only store infomation in keys like "node_session_DevEUI" could solve this confict?
DevEUI is a large number which is enough for all.

[brocaar]

Possibly, you could have different neighbouring NetIDs. I think the NetID (and thus the DevAddr pool within that NetID) can repeat, as long as two neighbours don't have the same NetID. Note that this isn't currently supported yet, as you'll start LoRa Server with a fixed NetID. From reliable sources I've heard that roaming is now a discussion topic within the alliance, there might be overlap with this topic I think...

@yzk0281 I need the DevAddr in Redis as this is the only lookup key I have when receiving an uplink packet :-) One possible way would be to assign gateways to different network segments so that based on the gateway receiving the packet, I know to which segment it belongs. With this, I could create a key like nwk_segment_X_node_session_00983e58. But again, I think this requires roaming in place, as your node might move from NetID A to B.

[yzk0281]

@ivajloip
could you give me some link where "the LoRa alliance says that this is not a problem as the real identification of the end-device is not only by DevAddr, but also by NwkSKey" ? I want to have a good look into this.

[yzk0281]

@brocaar
So what is your opinion if DevAddr is not enough?

[brocaar]

As long as the networks (with different NetIDs) are small enough so that each DevAddr pool will not exhaust, that could work. But again, it needs roaming in place as your node might move from one network to the other. I'm looking forward to hear if the LoRaWAN v1.1 specs will cover this. Before starting to work on this and implement my own solution, I'd rather wait for an "official" solution (given it is being worked on of course).

[yzk0281]

@brocaar @ivajloip
Thank you guys.
Currently I intend to ignore the NetID digits, thus I can have more than 4 billion different DevAddr.
If it still not enough, then I think I will make some modify to the LoRawan as follows:

I will take advantage of the extra 1 byte before FRMPayload for DevAddr, so that 40 bits in total for DevAddr, it is enough for all.
What do you think of it?

[ivajloip]

@yzk0281
I heard this during the All members meeting of LoRa Alliance in Munich, so I can not provide you with document that states this.

Second point, as long as no roaming is required for your network, you have no problem using all the 4 bytes (i.e. without netID) and this was also said during the Munich event.

@brocaar
To the best of my knowledge, the netID's are given by the LoRa Alliance and they will be very important for the roaming. There are some values that are left for test purposes only, but all other values will be given to some network operators (Orange, Deutsche telekom, etc).

Hopefully in a few months we will have access to the specification so that we can tackle those problems :) For now I agree that it is too early.

[nestorayuso]

This document explains the NetID allocation, and roaming impact, although not clearing the extra use of NwkSKey to unequivocally identify nodes.

https://es.scribd.com/document/317164891/20160603-NetID-Alloc-Policy-Application-1178-1

[ivajloip]

By the way, I found something that confirms my understanding about DevAddr uniqueness

The network session key (NwkSKey) is used for interaction between the Node and the Network. This key
is used to check the validity of messages (MIC check). In the backend of The Things Network this
validation is also used to map a non-unique device address (DevAddr) to a unique DevEUI and AppEUI
(see the Address Space page).

[pdemil]

Using the NwkSKey to map a non-unique device address (DevAddr) to a unique DevEUI is sufficient, if the NwkSKey is unique (as recommended).

On 05 Aug 2016, at 10:02, Ivaylo Petrov <notifications@github.com mailto:notifications@github.com> wrote:

By the way, I found something https://www.thethingsnetwork.org/wiki/LoRaWAN/Security that confirms my understanding about DevAddr uniqueness

The network session key (NwkSKey) is used for interaction between the Node and the Network. This key
is used to check the validity of messages (MIC check). In the backend of The Things Network this
validation is also used to map a non-unique device address (DevAddr) to a unique DevEUI and AppEUI
(see the Address Space page).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #56 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AD-3iCq_eCTomelwXHPS8w56_shrdbq7ks5qcu4RgaJpZM4JaNCs.

[iBrick]

Regarding non unique DevAddr I already found a problem in current loraserver architecture. It is possible to have several nodes with same DevAddr but different DevEUI. If you delete on of nodes all records from Redis for appropriate DevAddr are deleted as well.

[brocaar]

It should not be possible right now to have multiple nodes with the same DevAddr, as the DevAddr is part of the Redis key, so they would overwrite each other. Could you give a link to the code where you see the issue?

[iBrick]

As you said they are overwrite each other without notice. And it look like this afterwards:

So after creation of second node with same DevAddr data is overwritten in first one as well and then when I click Edit on the first one it open Edit page for the second.

[brocaar]

Thanks for reporting this bug 👍 Will look into a fix!

[brocaar]

@iBrick your issue has been solved and released as 0.10.1 thanks for catching the bug :-)

[iBrick]

Thank you very much for fixing!

I wanted to ask how do you build project. I'm new to Docker and what I do is build it with command 'docker-compose up --build'. It build the binary successfully but recipe for target 'serve' fail. I can use the binary locally afterwards but it doesn't start inside Docker.
Looks like it doesn't start because of missing params in Makefile 'serve' target:
./build/loraserver
I've added it like this:
./build/loraserver --net-id 010203 --band EU_863_870 --postgres-dsn "postgres://loraserver:loraserver@postgres_test/loraserver?sslmode=disable"

but still no luck as I get these errors:
"loraserver_1 | time="2016-08-12T07:15:20Z" level=fatal msg="controller-backend setup failed: backend/controller: connecting to broker failed: Network Error : dial tcp [::1]:1883: getsockopt:
connection refused"
mosquitto_1 | 1470986120: Socket error on client 97e8825b-19ad-4fc2-8047-eaf1ba7ec70d, disconnecting.
loraserver_1 | make: *** [serve] Error 1
loraserver_1 | Makefile:41: recipe for target 'serve' failed"

And what is the way to debug program inside Docker?

[brocaar]

After #68 I'll look into changing the way how the DevAddr is matched against the DevEUI. I'm thinking about changing the DevAddr related Redis key into a set of DevEUI items and then storing the actual node-session date in a DevEUI related Redis key.

[nestorayuso]

I think this can help
http://portal.lora-alliance.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=1302

[brocaar]

Thanks! Given
I think supporting multiple DevEUIs on a single DevAddr is the way to go.

[brocaar]

I forgot to update this issue after the 0.12.0 release:

please note that the node-session api since 0.12.0 now uses the DevEUI as session identifier. This doesn't resolve this issue, but see it as pre-work for implementing node-sessions by DevEUI instead of DevAddr (making it possible to handle duplicated DevAddr in the database).

[brocaar]

I'm currently working on refactoring the session storage so that a single DevAddr can map to a set of DevEUI items.

[brocaar]

This has been implemented in LoRa Server 0.15.0. Please refer to the changelogs for details :-)