Im trying to keep this short, so may miss some details and/or things I have tried and reviewed.
I have my own custom loraWAN Server Application. When using the Seeed E5 boards I can connect and exchange data just fine. But its currently using ABP, i.e. I store the keys in the device by hand. For home/learning it works fine.
In this setup I need to encrypt and decrypt packets as well as generate the MIC (aes128 cmac) and check/apply, so I am very happy I know how all that works… as its working…
My issue i am currently stuck on:
I would like to now move to OTAA Join. Seems simple enough.
Again since this is my home server setup and more for learning, I have a lot more flexibility that I can tighten over time. e.g. At the moment I don’t vet/filter the node trying to connect, I simple allow any connection (Yeah not perfect, but the node still needs to know the AppKey to create the MIC and the encryption, so not as open as you might first think…
When I tell the E5 node to join, i can see the packet go to the gateway, then forwarded to my server software. My software then checks the MIC (which passes every time; so the code to check and the AppKey MUST be correct). then extracts the values from the Join Request.
I then build the Join Accept Packet as per 1.0.1-1.0.3 (and have tried all 3 versions on the E5; That packet is then sent back to the node via the gateway. The node, in debug mode, does show the correct “packet”; but then I get a “Join Failed”
Since the packet does get to the node without any errors then I know all the radio side should be ok. e.g. error correction, SF, data rate etc… as if any of those where wrong, the packet should appear broken in some way… its not, its perfect as per what I sent.
If I take that Join Accept packet from the node logs, I can decrypt, check the MIC and verify by hand all the data is correct… yet it fails to join.
Given the current challenge (fail to join) we can rule out anything past that, like the derived keys.
My understanding for the Join Accept Packet.
1 Byte : 0x20 - Join Accept Packet ID
12 Bytes (as per the docs) of Accept Data (which I feel could almost be anything at this point).
so the MIC is calculated over those 13 bytes.
The 12 Bytes + 4 Byte Mic (16 Bytes) is then “encrypted via the AES decrypt call” such that we end up with
0x20 <16 Bytes Encrypted Data>
Note: I have left some detail out, but happy to dive in as needed.
I also note that we used decrypt, to “encrypt” the data, as the node only needs/uses the encrypt function. So it would then “encrypt” to get back to the clear text… this is as per the docs I can find.
At this point I cant work out why it wont accept the join.
To me, since the packet does get all the way back to the node, all the comms are ok.
I know the MIC and Encrypt/Keys are correct.
so
one of the following is where Im at:
- I am building the Join Accept Packet wrong!
- Some data in my Join Accept Packet is critical and I have it wrong.
- the Node itself has some other setting I need to tweak to work as expected.
Sorry for the long post, Just wanted to give enough background.
Does anyone have any ideas why the E5 module is not accepting my Join Accept Packet.
If someone does use the E5 and does not mind sharing, could I get a copy of your AppKey and the Join Accept packet as seen in transit (e.g. at the node or gateway).
i.e. I would really like to see an actual working packet both in clear and encrypted.
Any known bugs/tweaks with the E5 (I have seen some threads talking about things, but missing the actual data… like the RXDelay setting sent back is not inline with what the module thinks it should see)
Happy to follow up with more detail as needed.
Thanks.
edit:
This is the node that is not accepting the Join Accept packets
