Hi,
is there a way to identify packages that arrived at the gateway ?
I’ve received a package from an App EUI and Dev EUI that are certainly not mine.
TTN is a community service, receiving packets at a Gateway from other peoples nodes is normal and to be expected.
1 Like
Of course, I’d be surprised if it didn’t happen.
And by any change do you maybe happen to have an answer to the question too ?
Someone calling themselves “Private” wants to figure out the owner of a device legitimately broadcasting that is being picked up by a gateway that entirely runs on a network provided for free by a commercial company - some irony going on here.
If you can figure out the device EUI you could see if that it registered to something that then gives you a clue - but that’s going to be just one tiny piece of the jigsaw.
Or you could get a Yagi and try some radio direction finding to do some triangulation.
Or you could live with it - even if your gateway & network infrastructure was private as opposed to TTN, your gateway would still receive the transmissions.
1 Like
What exactly do you mean by being able to ‘identify packages’ arriving at the Gateway ?
I just tried to figure out where the packages originated. From a geographical point of view. Like to figure out my gateway’s range. I don’t care who or what is behind it.
There is a thought though, how does the network prevent from let’s says questionable content use.
As a ‘shared spectrum’ environment you can’t - unless you implement a whitelist for Dev Addrs at GW (antisocial and against TTN manifesto) - anything ‘alien’ to TTN will be dropped at NS (unless authorised/routed through e.g. Packet Broker or another such exchange mechanism).
You can look at the Dev Addr in GW log for clues to host network - usually called out if you expand the log line and a LA registered network. For ref if you see Dev Addr starting 00 xx xx xx or 01 xx… that will be classed as an ‘experimental’ node and may not be specifically registered. If you see 26 xx… or 27 xx… that will be a TTN(or TTI)registered node.
e.g.
or
You can then always contact the host network to trace the end user (e.g. in case of abuse of local air time regs etc.), other than that find out ‘who’ is unlikely - though you can always post the dev Addr and ask if anyone knows or claims ownership. If node is registered against e.g. TTN Mapper that may be another route to identifying who owns…
1 Like
I`m only interested in lat and long, actually I don’t even need to know that either just how far it was away, that’s all.
But thanks for the answer and small tutor although I have slight different display with the dev and app eui and no network infos.
You can’t. However the amount of data a LoRaWAN node can uplink is very small compared to other technologies. And only the owner of an node should have access to the decrypted data which means it isn’t suited for sharing of illegal content as only a very limited audience will be able to access the small uplink data.
Using a Lora based network with one transmitter and multiple receivers where you don’t have to register an application with a central body (TTN in this case) which has to adhere to the Dutch telco laws regarding lawful data interception would be a far more likely way to share questionable content.
1 Like
Just for the sake of completeness:
Note that a DevAddr is not unique (like for the EU-region TTN only uses at most 4,096 different values for all ABP devices). Also, a DevAddr will change for each OTAA Join. (Though a device should not need to re-join very often, if ever.)
You’re seeing an OTAA Join Request, which apparently either is not handled by TTN as the device is not registered to TTN, or for which TTN has commanded another TTN gateway to send the Join Accept (if the request was received by multiple gateways). The DevAddr is only assigned after the join request is accepted by a network, so at this point TTN Console cannot show any network details. You will see the DevAddr for data uplinks.
If the device happens to use a TTN-assigned AppEUI, then it starts with 0x70B3D57ED. But a device can also use its own AppEUI when registering on TTN.
1 Like
Indeed and therefore it has to be a ‘dynamic’ whitelist and gets even harder and an even worse idea to try to implement 
One just has to accept its a broadcast/open comms methodology and recognise that ‘your’ nodes also benefit from being captured/passed on by others GW’s - a true community 
True - makes nailing a node that is ‘stuck’ issuing repeated JR’s a real pain to get the owner to ‘stop/fix’ it 
1 Like
So if I have this, is it possible to see, or derive an appx on the ‘how far away is that’ ?
@pe1mew’s tracer to the rescue: GitHub - pe1mew/PE1MEW_OTAA_Tracer: A tracker to locate LoRaWAN nodes that fail to personalise using OTAA. 
1 Like
Nope.
Thanks.
So I have to grab my mobile and some LoRa device and drive around a bit.
Ok all you guys, thank you for the answers.
Yes, and there’s an app for that: https://ttnmapper.org
Which if you choose a route around & about the hills & valleys, tall buildings and flat bits, go as far as you think you need to deploy nodes, loiter in the key areas, that will quickly give you data you know is reliable.
1 Like