Comments (26)
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
from chirpstack-network-server.
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.
from chirpstack-network-server.
sorry, typo
only 4 bytes
from chirpstack-network-server.
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 :)
from chirpstack-network-server.
@ivajloip
Do you mean that different nodes could have the same DevAddr?
from chirpstack-network-server.
That's my understanding. Note that currently the implementation does not support this.
from chirpstack-network-server.
@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.
from chirpstack-network-server.
Possibly, you could have different neighbouring NetID
s. 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.
from chirpstack-network-server.
@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.
from chirpstack-network-server.
@brocaar
So what is your opinion if DevAddr is not enough?
from chirpstack-network-server.
As long as the networks (with different NetID
s) 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).
from chirpstack-network-server.
@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?
from chirpstack-network-server.
@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.
from chirpstack-network-server.
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).
from chirpstack-network-server.
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 <[email protected] mailto:[email protected]> 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.
from chirpstack-network-server.
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.
from chirpstack-network-server.
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?
from chirpstack-network-server.
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.
from chirpstack-network-server.
Thanks for reporting this bug 👍 Will look into a fix!
from chirpstack-network-server.
@iBrick your issue has been solved and released as 0.10.1
thanks for catching the bug :-)
from chirpstack-network-server.
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?
from chirpstack-network-server.
I think this can help
http://portal.lora-alliance.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=1302
from chirpstack-network-server.
Thanks! Given
I think supporting multiple DevEUI
s on a single DevAddr
is the way to go.
from chirpstack-network-server.
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).
from chirpstack-network-server.
I'm currently working on refactoring the session storage so that a single DevAddr
can map to a set of DevEUI
items.
from chirpstack-network-server.
This has been implemented in LoRa Server 0.15.0. Please refer to the changelogs for details :-)
from chirpstack-network-server.
Related Issues (20)
- No answer to mac command LinkCheckReq when uplink use LR-FHSS HOT 7
- Network server does nothing HOT 1
- Tests stuck HOT 3
- ping PostgreSQL database error HOT 1
- ERROR: relation "code_migration" does not exist HOT 1
- Fail to receive LoRaWAN 1.1 confirmed downlink ack
- No LORAWAN Frames: level=error msg="gateway: handle gateway stats error" error="update gateway state error: object does not exist" HOT 4
- Uplink history initialization problem HOT 1
- Wrong test in func UpdateGatewayState to see if gateway coordinates should be updated
- Please close due to wrong repo
- Device specific installation margin
- External interface for band for ADR plugin creation HOT 1
- Adding MaxLoRaDR to the ADR HandleRequest to allow usage in ADR plugin HOT 2
- Azure IOT cbs negotiate claim error HOT 8
- Changing max DR in service profile has no effect on registered devices HOT 1
- LoRaWAN Relay TS011-1.0.0 HOT 1
- Base64 error: Encoded text cannot have a 6-bit remainder. HOT 1
- FCnt mismatch between GRPC API and WebInterface for the first packet HOT 4
- postgresql deadlock HOT 6
- Limit API Key scope
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chirpstack-network-server.