Open avbentem opened 7 years ago
(thank you for the detailed report; I'm scheduling time in September to work on this; apologies for the delay)
(I wish I could downvote for unneeded apologies! ;-) )
Note that the above example is for EU868 in LoRaWAN 1.0.x; other regions and versions might need a different decoding.
Like US915 (which support a whopping 64 channels) does not support CFList in 1.0.x, but does in 1.1; see page 15 of https://lora-alliance.org/sites/default/files/2018-05/lorawan-regional-parameters-v1.1ra.pdf
Can I have code for ABP, I need this because I am using ABP.
@nvdak, this issue does not apply to ABP.
(For ABP, the DevAddr and the secret AppSKey and NwkSKey are fixed, and are simply copied/programmed into the device after registering/activating it on the network. Like for www.thethingsnetwork.org such registration/activation would use the TTN Console website, or the ttnctl
command line interface. After copying/programming the fixed details into the device, there are no join messages to be decrypted/decoded at all.)
lora-packet shows incorrect details for a Join Accept:
Without first decrypting the message, the following lines in
_initialiseFromWireformat
are not quite valid: https://github.com/anthonykirby/lora-packet/blob/53190fa4b9b2920c31187f8e39adb7d72c8cc6b0/lib/packet.js#L138-L149I guess
toString
should only print the message type, without any of the erroneous details: https://github.com/anthonykirby/lora-packet/blob/53190fa4b9b2920c31187f8e39adb7d72c8cc6b0/lib/packet.js#L408-L414Background
For a not-encrypted Join Request like
00DC0000D07ED5B3701E6FEDF57CEEAF0085CC587FE913
lora-packet correctly shows:For a matching response,
204DD85AE608B87FC4889970B7D2042C9E72959B0057AED6094B16003DF12DE145
, it currently erroneously suggests:This is wrong as the Join Accept payload (including its MIC) is encrypted using the secret AppKey (not to be confused with the session AppSKey, which is actually derived from the Join Accept). When decrypted using AppKey
B6B53F4A168A7A88BDF7EA135CE9CFCA
, the above Join Accept would yield:(The Things Network has been assigned a 7-bits "device address prefix" a.k.a. NwkID
%0010011
. Using that, TTN currently sends NetID0x000013
, and a TTN DevAddr always starts with0x26
or0x27
.)When the DevNonce from the Join Request is known as well, then the session keys can be derived:
Example to derive the values
The following working example can also be seen at https://runkit.com/avbentem/deciphering-a-lorawan-otaa-join-accept