RAK2245 RasPi3 Hat TTN Not Connected

[descartes (Nick McCloud)]

@mpmackenna

I think I would know if someone was breaking into my house and setting up a TTN gateway.

Kids? Significant other? Grandma? Maybe they are all next door laughing their a55 off?

[arjanvanb (Arjan)]

@descartes

cheat sheet on the URLs you use for diagnosis

Not really, except for Determine which gateway is used by a given node - #12 by arjanvanb. And the forum’s bookmarking functionality helps, but I’ve started using that too late. So it’s mainly search for keywords I remember…

[mpmackenna]

@arjanvanb @descartes This device seems to have fallen over since I powered down my device. I would say the evidence is starting to mount. My gateway is going by an alias. Its some sort of undercover rogue agent.
https://www.thethingsnetwork.org/gateway-data/gateway/eui-b827ebfffee6cbe6

[descartes (Nick McCloud)]

Whilst it fills me with a random range of uncomfortableness but given that the EUI is generated from the Pi’s MAC address so isn’t a “real” one and if you change Pi, it won’t change in the config, let’s try changing your EUI on the device to the one that TTN thinks you have.

Or, if you have the patience, re-install the whole gateway just in case you have multiple Pi’s and we have some re-generation of the EUI issue going on.

[arjanvanb (Arjan)]

@descartes

the EUI is generated from the Pi’s MAC address

…which it probably has multiple? Like WiFi and ethernet?

@descartes

If you try and create a new gateway

Can you actually still register the 6cbe6 one? Probably not, given it has a description from somewhere.)

[mpmackenna]

@descartes @arjanvanb I powered the device back on. Then I updated the global configuration and restarted the packet forwarder. I noticed the device started updating again. I then went to register a gateway with b827ebfffee6cbe6 as the EUI and this time it accepted it without issue. The gateway is now showing up in the console with EUI of b827ebfffee6cbe6 and it shows as connected. I also still have the old not connected gateway too. I figure I will just leave that one in case it somehow one day magically reverts to that value. I believe I do have both Ethernet and WiFi configured on that pi. I didn’t realize the EUI was based on the interface’s MAC address. I am betting that is how I got one EUI registered and another one that was actually working based on how traffic was routed. Thank you both for all of your help! I guess I am going to move on to configuring my node and learning how to use the MQTT API. Thank you again, it is much appreciated!

[descartes (Nick McCloud)]

You’re welcome!

[arjanvanb (Arjan)]

Aside, right now, status still fails for both gateways, but info works, for both, as in:

• ttnctl gateways info eui-b827ebfffee6cbe6 (with owner details)
• ttnctl gateways info eui-b827ebfffeb39eb3 (no owner)

(I assume that my EU868 settings for ttnctl should also work for ttnctl gateways status eui-b827ebfffee6cbe. Oh well. Maybe it will take some time.)

[mpmackenna]

@arjanvanb Seems to be working over here. Perhaps there is some sort of replication that occurs cross region? Thank you.

mike@tincan 11:15:24 0 :~$ ttnctl gateways info eui-b827ebfffee6cbe6
INFO Found gateway

      Gateway ID: eui-b827ebfffee6cbe6
  Frequency Plan: US_902_928
          Router: ttn-router-us-west
     Auto Update: on
           Owner: mpmackenna
    Owner Public: yes
        Location: (41.560351, -90.517387, 205)
 Location Public: yes
   Status Public: yes

           Brand: RAKwireless
       Placement: indoor
     Description: mikes-tincan
      Access Key: omitted

[arjanvanb (Arjan)]

Yes, you’re showing info. But the following, using the undocumented status (which can often be used when TTN Console shows gateways as being disconnected), still fail for me:

• ttnctl gateways status eui-b827ebfffee6cbe6
• ttnctl gateways status eui-b827ebfffeb39eb3

[mpmackenna]

@arjanvanb

Yes, you’re showing info . But the following, using the undocumented status (which can often be used when TTN Console shows gateways as being disconnected), still fail for me:

Ah, I see. I misread your command the first time. I am also getting failed when I run the status command. Does the status command require that ports are forwarded or anything like that for the gateway to respond? I don’t have any of that setup at this time. Thank you.

[arjanvanb (Arjan)]

As far as I know, ttnctl does not cmmunicate with the gateways directly. Surely the EU868 gateways that I manage do not have any incoming ports open from the internet, but surely status works just fine. Like:

• The Things Gateway, using MQTT: ttnctl gateways status arjanvanb-gw-1
• Kerlink IoT Station, using Semtech UDP forwarder: ttnctl gateways status eui-0000024b080606d8

[cslorabox]

@mpmackenna

I didn’t realize the EUI was based on the interface’s MAC address.

It often is, because that’s unique, but it doesn’t have to be

I am betting that is how I got one EUI registered and another one that was actually working based on how traffic was routed.

Probably. Seems like a case of scripts running amok and doing the generation step at multiple times, then changing the configuration files without making it clear they’ve done so.

These days I simply install the two repositories needed - the packet forwarder and the lora hal on which it depends, set the config file, and add an OS-appropriate way of running it as a daemon (systemd, init.d, procd, whatever)