AppEUI required in device

cyclops · October 21, 2020, 8:55am

Hi,

I’m using the SodaqOne v3 with universal tracker.
This little device has some validation on the following parameters:

AppSKey / AppEUI           (app=): 00000000000000000000000000000000
NWSKey / AppKey            (key=): 00000000000000000000000000000000

The validation that is used can be found here: https://github.com/SodaqMoja/Sodaq_Universal_Tracker/blob/27a7dff910c59e5abe8fde70782d6d9303735a10/Sodaq_Universal_Tracker/LoRaHelper.cpp#L88

As far as i can tell, chirpstack doesn’t need a AppEUI (somebody has pointed this out to me before, but i can’t find that anymore).
I’ve therefor patched this manuelly like so: https://github.com/cyclops1982/Sodaq_Universal_Tracker/blob/27a7dff910c59e5abe8fde70782d6d9303735a10/Sodaq_Universal_Tracker/LoRaHelper.cpp#L88

I’d of course like to avoid patches, so is there a way to set a appEUI in chirpstack, even if it’s hardcoded and system wide?

bconway · October 21, 2020, 12:59pm

Can you put in valid values for AppEUI/AppKey on the device instead of mucking around with the validation?

brocaar · October 21, 2020, 2:07pm

I do not see any difference when I switch between the Sodaq source and your source (looking at the LoRaHelper::convertAndCheckHexArray). In general, can’t you just set the AppEUI to 0000000000000000?

Note: at the device-side, you must set a valid AppEUI / JoinEUI. It is just that there is no need to configure this at the ChirpStack side.

cyclops · October 21, 2020, 7:18pm

Ah, sorry! I pasted the wrong link.

github.com

cyclops1982/Sodaq_Universal_Tracker/blob/3f6d5611a039daf545abfde844592e804ddbed4e/Sodaq_Universal_Tracker/LoRaHelper.cpp#L88


void LoRaHelper::init(Sodaq_RN2483& rn2483, uint32_t(*getNow)())
{
    _rn2483 = &rn2483;
    _getNow = getNow;
};

/**
* Converts the given hex array and returns true if it is valid hex and non-zero.
* "hex" is assumed to be 2*resultSize bytes.
*/
bool LoRaHelper::convertAndCheckHexArray(uint8_t* result, const char* hex, size_t resultSize, bool allowZeros)
{
    bool foundNonZero = false;

    uint16_t inputIndex = 0;
    uint16_t outputIndex = 0;

    // stop at the first string termination char, or if output buffer is over
    while (outputIndex < resultSize && hex[inputIndex] != 0 && hex[inputIndex + 1] != 0) {
        if (!isxdigit(hex[inputIndex]) || !isxdigit(hex[inputIndex + 1])) {
            return false;

There’s an additional parameter to allow AppEUI’s that are all 0.

With regards to setting the AppEUI to 0, do you mean in the device or in chirpstack? I am probably blind, but i don’t see an option for that in chirpstack.

brocaar · October 21, 2020, 7:42pm

I mean setting it to all 0s at the device side.

cyclops · October 21, 2020, 9:28pm

So, by default (without my patch) the device’s code checks for that and it’s not allowed.

My patch works fine. I’ve been testing the device and all is ok. I would however like to avoid having a specific patch.
I don’t know enough about lorawan to know if this is just silly from the Sodaq implementation, of if it’s something that could also be fixed on the chirpstack side

eugenev · October 22, 2020, 7:50am

I suppose that must be reimplemented at the Sodaq application side. Thats right way.

brocaar · October 22, 2020, 10:49am

You could also set it to any other (random) AppEUI / JoinEUI value. As long as you have not configured any join-server with that specific JoinEUI, it will not break anything.

I have been using the Sodaq tracker code before, and had no issues using it. I’m not sure if I set the AppEUI to 0000000000000000 or something random, but there was no need to make any code changes.

cyclops · October 22, 2020, 7:37pm

I think i tried setting it to something and then i think i wasn’t able to join, but i will check this.

For now, it’s clear that my fix should actually be applied to the device and that changing chirpstack for this doesn’t make sense. Thanks for the help!