join refused: AppEUI for OTAA does not match device

[gerfen]

I have new class C devices which I have not been able to join to my gateway. I have double checked the AppEUI in the devices configuration[1] and in the device twins[2] multiple times. I have older versions of the same devices which do connect as expected with the same AppEUI and ApplicationKey.

This could be a issue with the devices but I wanted to see if there maybe some issue with the v1.0.2 release. I'm willing to upgrade to v1.0.3 if this issue has been addressed there.

Expected Behavior

The device connects to the gateway.

Current Behavior

The device does not connect to the gateway.

Device (Host) Operating System

Ubuntu 16.04

Architecture

amd64

Container Operating System

Linux containers

Logs

2020-05-11 21:05:40.186 Physical dataUp {"rxpk":[{"tmst":617733892,"chan":7,"rfch":1,"freq":903.700000,"stat":1,"modu":"LORA","datr":"SF10BW125","codr":"4/5","lsnr":8.2,"rssi":-103,"size":23,"data":"AExrbmlMQHJVllmWkxZh4SSAshyvEyU="}]}
2020-05-11 21:05:40.186 24E1611693965996: join request received
2020-05-11 21:05:40.186 24E1611693965996: querying the registry for OTAA device
2020-05-11 21:05:40.268 24E1611693965996: processing time: 00:00:00.0829052
2020-05-11 21:05:40.268 24E1611693965996: join refused: AppEUI for OTAA does not match device

Additional Information

[1] Image of the Ursalink configuration:

[2] IoT Hub Twins:

"desired": {
"AppEUI": "5572404c696e6b4c",
"AppKey": "**********",
"SensorDecoder": "http://decoder/api/DecoderUrsalinkUc1114",
"GatewayID": "",
"ClassType": "C",
"RX2DataRate": 10,
... elided for clarity
}

[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

[blackcrater]

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

[ronniesa]

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

[blackcrater]

DUMP 24E1611693965996:joininfo
(nil)

[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.

[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]

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.