AppEUI == 0 issues with TTN V2/V3 migration

Arduino LMIC
1

See arduino-lmic #759.

I saw an issue with using AppEUI==0 for uplinks when migrating a V2 device to a US V3 app, using a V2 gateway.

I set the AppEUI of the device to zero to move it to V3 (also adding it on the V3 console).

Device claimed to be joining (in the serial logs). But the TTN V2 console for the gateway didn’t show any uplinks. After a lot of headscratching, changed the AppEUI to 1 in the device… and things worked immediately.

I suspected an LMIC bug, because I remembered others reporting this problem. But I’ve tested with an RWC5020B network emulator, and all is well. I also checked with @tanupoo’s lorawan-parser, and all was well.

So now it appears either to be a gateway problem or a TTN V2 problem. I will continue investigations and post results here.

2

Just curious,
Did you only change AppEUI (to 0) on the (previous) V2 device or were there more changes involved?
What version of LMIC was used?

Only “Joining” or also “Joined”?
Did you see any join requests from the device arriving on the V2 gateway?
And join accept?

3

I’ve confirmed that this seems to be a bug with the Multi-Tech Conduit gateways. Things work fine with AppEUI==0 when using TTIG. The issue is that the Conduit does not forward a join request with AppEUI==0. It seems to discard it in internal processing. This is with the Kersing packet forwarder. AppEUI==0 works fine with a RedwoodComm gateway analyzer and other gateways. It’s unlikely to be a hardware problem in the MultiTech. It’s too hard to build the Kersing packet forwarder, so have not tried to debug it. The code is a combination of stuff from various repositories, so it’s not very convenient to analyze either. It’s easy enough to use AppEUI==1 so that is what we’re doing not.

4

From the author of the Kersing packet forwarder:

5
  • using the TCP transport, I think – will have to recheck.
  • yes. we now have more data - the really old gateways communicating with the fully legacy Semtech transport don’t show this problem. (In the conversion from V2 to V3, I had one in the lab, and tested a number of devices for production. Join Requests were forwarded by the TTIG and the one gateway running the legacy transport; not by any of the others. Subsequent messages were forwarded by all the gateways in the lab.