LoRa App Server is acting as a default join-server. In the future LoRa Server will also support the DNS lookup meganism to perform the join-server address.
Hi all,
@brocaar, so LoRa App Server is acting as a default join-server. Then where can I find join server interface like web UI?
See the --js-bind config option for the join-server api port.
Thank you @brocaar . I think I need more study about the new LoRaWAN backend interface specification. 
Hi brocaar,
I am using Loraserver v 0.23.3 and Lora App Server v 0.17.1. My device join request causes error. I couldnt find any setting to set appeui. My other setting seems to be true. Lora server says:
level=info msg=“packet(s) collected” dev_eui=43…a1 gw_count=1 gw_macs=19…96 mtype=JoinRequest
The dev_eui in this message is same as my dev_eui setting. But the next message is an error:
level=error msg=“processing rx packet error: join-request to join-server error: response error, code: MICFailed, description: invalid mic” data_base64=“ADJoAPB+1bNwoXEJyYQY40Mfd5eAyeA=”
What can be the problem? How can I know what appeui/appkey/mic is calculated and it is not paired with the device message’s?
Best regards
There is no need to set the AppEUI / JoinEUI in LoRa App Server. If the entered details are set “correct” make sure they are also in the correct byte order (for some devices 0102030405060708 must be entered as 0807060504030201, see this example: https://docs.loraserver.io/lora-app-server/use/devices/).
My end device is RN2483. So the order is not reverse. The loraserver logs the device eui as expected
level=info msg=“packet(s) collected” dev_eui=43…a1 gw_count=1 gw_macs=19…96 mtype=JoinRequest
I can see it from the log. Where can I see the calculated AppEui and AppKey?
Or any more detail log for this error?
Some devices that are supposed to attach to my network already have AppEUIs programmed in, since the packets are being forwarded to their server from ours. Should I fret about this? I am already doing so I guess
-edit-
Perhaps I should start this as a new thread.
Hello @orne, I need your advice on how to provision a new device. I have read the documentation, but I can’t find where can I get the AppEUI after creating a device in UI.
As long as you’re not using a join-server (LoRa App Server acts as a default join-server currently, regardless of the AppEUI value), the AppEUI / JoinEUI (two names, same field) does not matter. E.g. you can leave this to 0000000000000000.
1 Like
Thanks, So if I understand well, this means that in the RN2483 module I will have to set 0000000000000000 (or whatever else) as AppEUI. Is that correct?
Yes, that is correct.
Thank you very much!
Dear Brocaar,
1 question though.
I’ve seen that you implemented some parameters here and there that are not used for now but will be enforced in near future (like datarate of channels in the loraserver toml config).
Why not doing the same for the JoinEUI?
After all, lora-app-server plays the role of join server for now, but in the future?
Wouldn’t it be safer to have a field in the device config page to set the appeui (not mandatory ).
Then in a future release when join server will be handled externally or by another process, that would prevent from re-provisioning all devices within a network (and it can easily be a lot)…
What do you think?
Well I think that when you are going to use a join-server in the future, you need to re-provision all your devices.
E.g. when using an external join-server, this join-server will be identified by a JoinEUI. So in order to let this join-server handle the join-request, you must set this JoinEUI of this join-server in your device.
So how this meganism will work in the future:
- Device sends join-request (containing DevEUI, JoinEUI, …)
- Network-server receives this (through the connected gateways), sees the DevEUI and knows this devices is provisioned
- In order to activate this device (over which the network-server has no knowledge as it does not have its root-keys), it will lookup the host of the join-server, using the JoinEUI (the Alliance defined a DNS meganism for this, e.g.
JoinEUI.domain.tld - Then it will forward the join-request to this resolved host to retrieve the join-accept (+ encrypted session keys)
- Once activated, it will forward the data to the already configured application-server (through the routing-profile, this is already provisioned by LoRa App Server).
For sake of simplicity, I skipped a few steps in the above example, but this is roughly how an activation through a join-server works, using the JoinEUI (previously known as AppEUI).
As you also see, the JoinEUI sent by the device defines the above path, and having this information at the application-server would not change anything. E.g. it is perfectly fine to change the JoinEUI within your device when migrating to a different join-server, without the application-server knowing this (there are some practical issues with the encryption of the session-keys), but for the join-request using a join-server meganism, it it is not relevant for the application-server to know the JoinEUI (I believe).
Hello, brocaar!
I did not learn the new specification yet, but I see it introduces some new features, like a Join-Server and gives a new name for AppEUI - JoinEUI. Also, it tells that the JoinEUI must be programmed in each device that uses the JOIN procedure. Since updating to release version I did not found this field in App Server, but as you commented above it is not a problem. As I understood, since the DeviceEUI is unique and separate JOIN-server is not used, there no way to add the same device to more than one application in the same App Server. So the server “knows” which application the node relates to, and JoinEUI is not used at all, at it is required only if the Join-Server is used, isn’t it?
Thanks in advance! 
Yes, that is correct. Only the device needs to know the JoinEUI 
You mean, the device needs to know the JoinEUI - just once during Join-procedure, because it does not know if the Join-server is used or not, therefore it have to send correct JoinEUI, is it right?
Probably, I understand. I made a simple test. I created a new application, new device and service profiles, reprogrammed the end-node with new DevEUI and set AppEUI to all zeros. My Application ID in the App Server is 6 (it does not match to JoinEUI). And it does not matter, do the App ID match to my JoinEUI or not, the server allows the device to join and shows me all the packets the device sends
But sometimes I see the error message in the logs during the join-procedure:
processing rx packet error: get device error: object does not exist
Is it normal?
It appears once or twice, but then the server allows the device to join and send Join-accept, and the device begins normal data exchange without errors and packet losing. I think it is not radio-path issue.
Offtop: By the way, it is very very convenient to use the packet logs (decoded) in the App Server UI! Good feature, thanks!
Hi @brocaar
I’m trying connect my first node (mdot), my gwy (multitech conduit) is already connected to my loraserver, I’m trying to connect the mdto using this guide: https://www.loraserver.io/lora-app-server/use/devices/ but I’m a bit confuse about the APPEUI/JOINEUI, I don’t know what I have to set in that line, also I tried to read the lora alliance backend interface but the document doesn’t exist now.
If you can explain what I should configure there, or tell me where I can find more information about it, I would appreciate it.
As long as you are not using an external Join Server (which is the default), you can leave this blank / 0000000000000000 on your device. The purpose of the JoinEUI is to resolve (through DNS) which Join Server holds the root-keys and should process the Join Request.