V3 Gateway Console not GW-GPS-Information are shown in the Console

E_T · March 11, 2021, 3:57pm

Hallo,

there is the option to take the GPS-infos from the GW to fill in the GPS-Position in V3-GW-Console:

Location → Update from status messages

In the status package there are the information, but not shown in the console!

{
  "name": "gs.status.receive",
  "time": "2021-03-11T13:45:47.295329707Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "xxxxxxxxxxxx",
        "eui": "xxxxxxxxxxxxxx"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.GatewayStatus",
    "time": "2021-03-11T13:45:47Z",
    "boot_time": "0001-01-01T00:00:00Z",
    "versions": {
      "ttn-lw-gateway-server": "3.11.2"
    },
    "antenna_locations": [
      {
        "latitude": xx.606757,
        "longitude": x.321227,
        "altitude": 100

What must i do that the GPS-Position from the GW are shown in the location-window for the GW?

E_T

joey_ho · April 16, 2021, 2:32am

I have the same question too.
I’m using the Semtech Packet Forwarder to connect to TTN Stack v3.

And I’ve setup the “Location source” with the “Update from status messages” option.
But the location of the gateway can be updated automatically even the “gateway status” was forwarded to TTN.

Does someone has the solution?
Thanks!!

icepicknz · November 6, 2021, 1:03am

I too am looking for this, I just migrated 3 gateways and have another 5 to move.
Did you find a solution to this?

arjanvanb · November 20, 2021, 6:14pm

Same here, for a Kerlink still running the 2015 V2.2 firmware, using the Semtech UDP protocol:

Like the posts above, it has “Update from status messages” enabled. But note the help text:

GPS location not for UDP

When checked, the location of this gateway will be updated from status messages. This only works for gateways connecting with authentication; gateways connected over UDP are not supported.

TTN Mapper is showing it nicely though:

TTN Mapper

Regardless, I now just disabled that checkbox and copied the coordinates and altitude from the message into Console, as it is in a fixed location anyhow.

Full status message

{
  "name": "gs.status.receive",
  "time": "2021-11-20T18:01:13.006943520Z",
  "identifiers": [
    {
      "gateway_ids": {
        "gateway_id": "eui-0000024b080606d8"
      }
    },
    {
      "gateway_ids": {
        "gateway_id": "eui-0000024b080606d8",
        "eui": "0000024B080606D8"
      }
    }
  ],
  "data": {
    "@type": "type.googleapis.com/ttn.lorawan.v3.GatewayStatus",
    "time": "2021-11-20T18:01:12Z",
    "versions": {
      "ttn-lw-gateway-server": "3.16.0"
    },
    "antenna_locations": [
      {
        "latitude": 52.3817,
        "longitude": 4.62978,
        "altitude": 20
      }
    ],
    "ip": [
      "redacted"
    ],
    "metrics": {
      "ackr": 100,
      "rxfw": 0,
      "rxin": 0,
      "rxok": 0,
      "txin": 0,
      "txok": 0
    }
  },
  "correlation_ids": [
    "gs:conn:01FMZ5D56KJKNT9TZ73R5YJ40X",
    "gs:status:01FMZ84SHENKTZADK661PXFW6X"
  ],
  "origin": "ip-10-100-12-248.eu-west-1.compute.internal",
  "context": {
    "tenant-id": "CgN0dG4="
  },
  "visibility": {
    "rights": [
      "RIGHT_GATEWAY_STATUS_READ",
      "RIGHT_GATEWAY_STATUS_READ"
    ]
  },
  "unique_id": "01FMZ84SHE23A64PVTG9SDNGD3"
}

E_T · November 20, 2021, 9:00pm

Same with Dragino-GW!

kersing · November 20, 2021, 10:49pm

Not allowing unauthenticated UDP packets to update the gateway location might be considered a security feature as there is no way to validate the information is provided by a gateway itself and not by an imposter. (Which happend a few years back)

E_T · November 21, 2021, 7:30am

True, but even the user can simply enter incorrect position data!
So how likely is it to transmit position data incorrectly, and what impact does it have on the functioning of the network?

arjanvanb · November 21, 2021, 8:46am

It’s not about the gateway sending wrong information itself (or the owner making a mistake), it’s about someone using a script to set wrong location for other people’s gateway(s). Which has happened.

Yesterday I could not find the screenshots of that abuse (probably not posted in the forum but on Slack, no longer available). But it had the same effect as TTN Null Island, Atlantic Ocean - #4 by arjanvanb and Shenzen the new Null-Island? Dragino Owners please change the geolocation of your gateways! (Those examples are not related to non-authenticated UDP.)

arjanvanb · November 21, 2021, 11:57am

Oh, what are the chances! It seems somehow TTN’s Slack is running a free trial right now, making all old messages temporarily available again. (Also PMs, even if you start a “new” PM thread with someone not in the list of recent PMs.)

The massive fake locations happened April 5th, 2017:

@jpmeijers April 5th 2017, 4:23 PM

@htdvisser etc, it seems like a lot of the gateways are reported to be at location “gps”:{“latitude”:50.008724,“longitude”:36.215805} by the noc.
Seems like it started happening at 2017-04-05 12:00:31 UTC
Jumping around between the correct and the false location.
Perhaps someone in the Ukraine found a way to send status messages with a wildcard gateway EUI?

@htdvisser 5:32 PM

how many is “a lot of the gateways”?
Because we’ve seen some cases where different gateways use the same EUI, and depending on the last one to send a status message, the coordinates change
And does this only happen in the data the NOC returns or also in the data ttnctl returns?

@gonzalo 5:54 PM

we noticed the same with some gateways in Switzerland, gateways that were working fine before

@htdvisser 6:09 PM

ok, and where was that? Just NOC or also ttnctl, uplink, …?

@jpmeijers 6:24 PM

I just checked the noc. Was more than 800 gateways affected this afternoon

@htdvisser 6:27 PM

okay… Then I guess someone found the big vulnerability in the packet-forwarder protocol
Took them long enough

@jpmeijers 6:35 PM

Hehe indeed
You can still see 39 affected gateways on the noc

@htdvisser 6:38 PM

Those are probably gateways that don’t send their location themselves
then the NOC just keeps the last known status

This was mitigated quite rapidly for V2 back then:

@htdvisser April 6th, 2017 9:26 AM

I just wrote some stuff to make this more difficult in the future: Lock gateways to IP address and port · TheThingsArchive/gateway-connector-bridge@20e5912 · GitHub
Spoofing a gateway EUI is easy
Spoofing a source IP address is more difficult
Spoofing the exact port number the gateway is using, is just pro level

But apparently TTN decided to just not accept coordinates from non-authenticated status updates in V3. Makes sense.

(Not seeing a nice screenshot in Slack either though. Maybe it only existed in my mind.)

Also, in 2017:

@htdvisser April 10th 2017, 7:19 AM

We’d love to drop the Semtech protocol. It’s unreliable, insecure and causes many many problems on our servers, but unfortunately it’s installed on virtually every LoRa gateway, so we can’t drop support any time soon

jpmeijers · November 22, 2021, 5:22am

The behaviour that I have seen with the “Update from status message” setting was slightly different. Gateways running UDP Semtech forwarder:

Setting off + location set on console: manual configured location is available on mapping APIs.
Enable setting: the location of the gateway is set to 0,0 automatically and the mapping APIs reports the gateway at 0,0
Disabling the setting requires to set the gateway location again.

This does feel like a bug, but maybe the “clearing” of the location when this setting is enabled is intended.

The current behaviour is a little unintuitive, but I don’t mind having to set the gateway locations by hand on the console. Only using manual set locations can be more reliable as one eliminates some variables like GPS drift.