Locating an unrecognised node via DevAddr

End Devices (Nodes)
1

This is a long shot, but is there an API to reveal the list of public Gateway EUIs (or Gateway IDs) that a particular DevAddr has been received at?
I appreciate that the DevAddr is not unique and this is a non-issue for known / owned nodes (since the information is available via MQTT with an appropriate subscription)

However, when I see persistent unrecognised DevAddr hitting one’s gateways it would be really useful to know what other gateways are hearing the same broadcasts, perhaps limiting the scope of the response by specifying a metre range from particular Gateway ID and/or a timespan window.

I would imagine that this information might be readily available, since for downlinks the TTN network services need to select the most appropriate (& probably nearest) gateway to transmit to the node with the DevAddr in question.

For those on a direction finding hunt, armed with a list of public gateways receiving the same node traffic, together with the respective SNR/RSSI data, the vague location of (especially rogue) nodes could justify further analysis before breaking out the DF equipment.

It doesn’t help that most of my “rogue” nodes tend to be non-TTN, such is life.

Any thoughts?

2

You can use the events interface gateway API to receive events when a packet is processed from a gateway you have access to. You need the gateway id and a corresponding gateway API key for this.
https://www.thethingsindustries.com/docs/reference/api/events/

So if you can create / ask for gateway API keys in your neightbourhood, you should be able to receive and cross-correlate the messages.

I’ve been working on a java application that gateway uplinks from multiple gateways (not yet completely done)

You could also implement this in python for example.

3

Thank you @bertrik but doesn’t your approach require access rights on the gateway(s) in the target area that the (rogue) node is broadcasting from?
I would think it unlikely that gateway owners would give away API keys to allow the correlation and traffic analysis (but I might be wrong!).
Maybe I’m misundertanding.

update

Just as an example, say I enumerate all the gateways within 25km of a specific point (i.e., my target area of interest), using (for example)

https://mapper.packetbroker.net/api/v2/gateways?distanceWithin[latitude]=51.57&distanceWithin[longitude]=-1.83&distanceWithin[distance]=25000

Then for each one of these gateways I determine the rights…

https://eu1.cloud.thethings.network/api/v3/gateways/{gateway}/rights

I typically get back {} or something like this…

{“rights”:[“RIGHT_GATEWAY_LOCATION_READ”,“RIGHT_GATEWAY_STATUS_READ”]}

Alas, not anything suitable to see the traffic :frowning:

But your ttn-gateway-collector project looks just like the sort of thing I need :wink:
Regards, Howard

4

When you have multiple gateways and those use Multi packet forwarder (on Balena) you can connect those gateways to another network like Chirpstack server. I monitor traffic this way with 15 gateways and can see where devAddr are stronger than others. From experience I know that triangulation on RSSI is difficult. (not accurate). I see no simple solution with TTN at this moment.

For the real-deal and going outdoors fox hunting, I built as single-channel gateway to report for JOINREQUESTS when trying to find nodes that ware not good commissioned. Fo rindpiration you can find the repo here: GitHub - pe1mew/PE1MEW_OTAA_Tracer: A tracker to locate LoRaWAN nodes that fail to personalise using OTAA.

5

Thanks for the feedback @pe1mew

…which is a shame because TTN hold the data that could be correlated to assist with node location.

Anyway, thanks for your link to your OTAA Join Request Tracer project. Interesting.
I’m encoraged to create my own mobile gateway of some kind to be able to do some DF fox hunting.

I have a few occasional rogue nodes within my gateway coverage that I don’t even know if they are in my own street running low power or much further away on high power! The main issue is they repeat at less then 10 second interval and typically without cycling through different channels in a well behaved manner. So I feel it’s time for a DF project :wink:

6

I understand. Whenever in the future I have a need to go out and search I would do that with a full gateway, a laptop and some dedicated software.

Curious to hear from you what your solution and results will be.

7

The Things Stack will not let you inspect traffic for end devices that you don’t own, and it will not let you read traffic on gateways where you don’t have the right to read traffic. This will also not be possible in the future.

You could however work together on this with your local community. You can create an organization for your local community, add your local community members, and give the organization (traffic read) rights on local community gateways.

If you want to inspect the raw data for multiple gateways, the best way is to open a single event stream for multiple gateways. You can already do this with ttn-lw-cli, so you don’t need to write a Java/Python app for that. I’d recommend to combine ttn-lw-cli with jq for some filtering, and processing of the raw event data.

As an example, the following command will…

  • subscribe to events from gateways foo, bar and baz (replace with your own gateway IDs)
  • select only the gs.up.receive events (for the time being, you need to do this with jq, but in the future, you can let the server do that filtering)
  • select only the UplinkMessages
  • Select the time, gateway_ids and dev_addr fields
ttn-lw-cli events \
    --gateway-id foo \
    --gateway-id bar \
    --gateway-id baz \
    | jq -c '
    select(.name == "gs.up.receive") | 
    select(.data["@type"] == "type.googleapis.com/ttn.lorawan.v3.UplinkMessage") |
    {time: .time, gateway_ids: .identifiers[0].gateway_ids, dev_addr: .data.payload.mac_payload.f_hdr.dev_addr}
    '
3 Likes
8

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.