join refused: AppEUI for OTAA does not match device about iotedge-lorawan-starterkit

[blackcrater]

Result:
devEui 24E1611693965996 key 6iDkK3bHz01Oi/q+dR1ij46guoyoPovmWkj23Lyt+lE=

[blackcrater]

DUMP 24E1611693965996:joininfo
(nil)

[NiklasEderoth]

Hi, we got it working when both appkey and appeui where set to AA0000...0000AA.

[ronniesa]

Sorry it did not catch our eyes at first but the problem is that the AppEUI must be all uppercase so:
Not allowed: 5572404c696e6b4c
Allowed: 5572404C696E6B4C
Both device and registry must be uppercase and please restart the ntwrkserver or clear the cache and also clear the redis cache.

Let us know if it fix the problem we may need to specify it on the doc.

[ronniesa]

1.0.3 should not affect this. It is mostly around using the latest SDKs and latest IoT Edge

Just as a quick test try using symmetrical value for eui, appeui and appkey like CC0000..0000CC to exclude little vs big endian issues.

[gerfen]

Thanks for the suggedtion. I tried using aaaaaaaaaaaaaaaa and got the same error. I cleared the redis cache and rebooted the gateway after setting the appeui and still got the same error. Any other ideas?

[NiklasEderoth]

I got the same issue.

[ronniesa]

Can you create a quick c# console app and try this:
You need to add the nuget package: Microsoft.Azure.Devices 1.20.1

    static void Main(string[] args)
    {
        FindDevice();
        Console.ReadLine();           
    }

    static async void FindDevice()
    {
        //please change the connection string with your iothuboner connection string, it should look like this with values instead of xxxxxxxxx
        RegistryManager registryManager = RegistryManager.CreateFromConnectionString("HostName=xxxxxx.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=xxxxxxxxxxx");

        var device = await registryManager.GetDeviceAsync("24E1611693965996");

        var key = device.Authentication.SymmetricKey.PrimaryKey;

        Console.WriteLine("devEui {0} key {1}", device.Id, key.ToString());
    }

It should output the deviceEui and the primarykey

[ronniesa]

Can you please go in redis console in the azure portal and type DUMP 24E1611693965996:joininfo

[blackcrater]

Ronnie, note that the latter likely returned nil because at the time I ran the redis DUMP command, the device was out of range of the gateway. Additional relevant properties on the device object:

IoT Hub: Device EUI 24E1611693965996

Status: Enabled
Connection state: Disconnected (as of 2020-05-13T20:37:24.7998258Z)
Last activity: (none)
ETag: "OTQ4MjI3MjQx"
Scope: ms-azure-iot-edge://blyn-yh-gateway-south-637103868866876239
Primary authentication key: 6iDkK3bHz01Oi/q+dR1ij46guoyoPovmWkj23Lyt+lE=
Secondary authentication key: wvLyLBp8lm1nzwvqvj1YhGLPC0Ty0BAbXfl3T6Gn9RM=

[ronniesa]

the DUMP command was just to be sure that there is no data in the cache. We also know that the device is in the registry and that the code to retrieve the device and key works. We are further investigating.

[ronniesa]

The reason to use a mirrored key e.g. AA00..00AA is to avoid the issue that some device are little endian and some big. But of course you can try straight and reversed like AA00..11BB in BB11..00AA.

But it is important all keys must always be uppercase we do not support lower case values.

[gerfen]

@ronniesa Thanks for the response. I'll will update the keys as you suggest. Unfortunately the device manufacturer set both the AppKeys and the AppEUI using lower case so I will need to configure a lot of devices manually. :(

I am curious as to why the comparison of the strings does not ignore case? Is this a performance issue or is there some other technical reason?

Thanks!

[gerfen]

I have an update... I only needed to make the AppEUI and AppKey uppercase in the devices twins to get the devices to join my test gateway. We'll be making changes to our custom CLI to ensure the keys are set correctly in the twins when onboarding devices. Thanks for the assistance.

[ronniesa]

Is not a string comparison but the keys are use for cryptographic work. The data is encrypted by the device with the key uppercase even if in the device is typed in lower case. We felt it was more correct to have they key in all places always uppercase but in fact it can lead to this issue.

We will consider doing a ToUpper() when we read the keys from the registry in a future version.

Thanks for the feedback and glad that we could find the issue.

[gerfen]

@ronniesa I'll close this issue. Thanks again.