Update LoRaWAN_End_Device.ino

[amalinda]

As per my testing with Network Server of thingpark, I noticed the nwkKey and appKey must be formatted as follows for the join request to be accepted.

I am not sure if this is the case for other network servers too. But I believe it should be because of LoRaWAN standard. Please ignore the content , its the formatting that is important.

uint8_t nwkKey[16] = {0x42, 0x31, 0x91, 0x44, 0x91, 0x31, 0x91, 0x44, 0x91, 0x11, 0x91, 0x44, 0x92, 0x33, 0x91, 0x96}; uint8_t appKey[16] = {0x42, 0x31, 0x91, 0x44, 0x91, 0x31, 0x91, 0x44, 0x91, 0x11, 0x91, 0x44, 0x92, 0x33, 0x91, 0x96};

state = node.beginOTAA(joinEUI, devEUI, nwkKey, appKey);

[jgromes]

I am not sure if this is the case for other network servers too. But I believe it should be because of LoRaWAN standard.

LoraWAN standard only mandates AES-128 encryption. That has 16-byte keys, it may very well be 16 characters long string, unless those are explicitly prohibited, which would be quite strange. As evident by the cast to uint8_t*, those strings are internally treated as 16-byte arrays.

I guess the one difference could be in the user interface of the network server - for example, TTN has the following input field for the keys in the web interface:

So you could argue that showing the string encoded as hex bytes would make it a bit easier to copy-paste them into the web interface and vice-versa ... but I fail to see much difference either way.

[amalinda]

Thanks for your response @jgromes . I understand what you mean and I do agree with you.
In my case, the problem was that representing the AppKey in terms of ASCII was difficult but Actility Thingpark required AppKey/NwsKey to be in hex. One challenge could be that certain hex values, e.g., 00 to 1F, and 7F , could be challenging to be typed as ASCII.

What do you think? If you still feel its not that important, I will proceed to close the pull request :-)

[jgromes]

Resolved by 95e3839

[jgromes]

@jgamage91 I decided to do this myself, seeing as it was mentioned in the main LoRaWAN issue by someone else.

[amalinda]

Happy to see the changes absorbed nonetheless :-)