Hello Kersing, my gateway is a RAK 744. This unknown device is located in a area of say <>20-40km around (my antenna is outdoor), so may be difficult to chase even with a yagi antenna… It bothers as it pollutes my log every 7-10 sec. I assume my gateway transmits join requests (at least mine) as it is default public configuration (I can see other third parties devices transmitting data over if it can help).
Anyone knows if the “device ban” feature would be available at some point on the console? I have this guy sending a join request every 7 seconds, I guess it will never be able to join as the join process requires more time for acknowledgment. At least a way to send him an email …
I was asking about join response. In the TTN console you should be able to verify if any response packets are scheduled to the gateway. And your gateway does not transmit join requests, it might forward join requests to TTN, but as it is not a node it will not transmit (to the ether) join requests.
I tried to explain such a ban does not help. The device will still be transmitting and as such the transmissions will be received. The only change would be that you no longer see lines in your logfile. In the console you already have filtering options so it should not make too much of a difference.
That is assuming the device is registered on TTN. It might be for a totally different LoRaWAN provider…
You could post the data you see in the TTN console, may be someone recognizes her/his device eui? Of may-be one of the TTN admins can check if the device is registered in the database and try to contact the owner…
1 Like
This is what can be seen on the traffic, there is no scheduled reply apparently. What is weird is why would you send a Join command every 7 sec from the node side?
Yeah the only way to stop a device from using airtime is to power it off.
From the documentation:
Applications in LoRaWAN and The Things Network have a 64 bit unique identifier (
AppEUI). When you create an application, The Things Network’s account server allocates anAppEUIfrom the address block of The Things Network Foundation. This means that every application has at least anAppEUIthat starts with70B3D57ED. If you have your ownAppEUIs, you can also add those to your application.
So, 70B3D59520000000 is not generated by TTN. It might still be registered with TTN of course.
That not so weird (though: bad). A Join Accept in RX1 will be transmitted 5 seconds after the Join Request, and in RX2 after 6 seconds. So, after 6 seconds the node knows if it has received a Join Accept or not.
1 Like
prob this node is powered on the mains then, sending a join command at that rate drastically reduces the battery life I guess
It is possible. I hunted down a series of wrongly commissioned nodes using a Wemos-RFM95 node and an OLED display (former singe channel gateway).
The code can be found here: GitHub - pe1mew/PE1MEW_OTAA_Tracer: A tracker to locate LoRaWAN nodes that fail to personalise using OTAA.
You can drive around or use a yagi for your fuxhunt.
1 Like
Hi Remko, looks very good well done and I can see I am not the only one to be bothered 
That would be also a good feature to add by manufacturers on their gateways in order to do it from home (especially when we are all quarantined!)
Cheers
A fox hunt sounds exciting, something I haven’t done (the radio fox hunt, that is) in many years!
Just being silly, but I looked up the AppEUI and it appears to belong to a company named “Requea” in Lyon, France. Perhaps this info can make spotting the node a bit easier…
Yes that is very helpful. I did the same and in my case I had to look for Elsys sensors.
Hey Roseen where did you find the info concerning the AppEUI vs the name of this company Requea?? I want to contact them, I am curious about where their node is located as lyon is somehow quite far (<>60-70 km straight line)… and I want to shut down their join request to be frank! (I know sounds like I am a weirdo ) I have <>60-80k/month messages passing through my gateway, I would prefer the Bandwith allocated for useful stuffs.
Oh, that won’t help! They are just the manufacturer. It would be like calling Volvo when you see a speeding car.
My idea was that you could try to find out more about their nodes, what they look like and what they are used for, to make it easier to find the one that is bugging you.
3 Likes
You can use, e.g., 70B3D59520000000 | MAC address lookup report | MAC Address Vendor Lookup (like I linked to earlier above).
It seem they are an IoT platform. So, like TTN, the might have assigned the AppEUI to a user a device registered on their platform, not to an off-the-shelf device they sold to someone they don’t know. In theory, that would make it easy for them to contact the owner.
(That is, of course, if some other user did not randomly use an EUI-64 that does not belong to them.)
Thanks everybody for all the info!
I know this will go against your query florentcoste, but this is a LoRaWAN we all contribute gateway capacity in exchange for a free WAN infrastructure. You can create your own private WAN, and control the nodes that can connect.
It’s not complex, however its not simple. See here.
We all give up a little bandwidth in exchange for building a robust TTN network. There could be a time when one of your nodes will return data to you via someone else’s gateway.
And if everyone blacklisted every foreign node - because of a few bad apples, then the WAN infrastructure that TTN gives you (for free!!) will depreciate.
Instead of looking at your gateway data, look instead at your application data… That will only show you what belongs to you… Ignore the noise.
Consider the big picture… Who cares if someone is knocking on your gateways door?? I have multiple devices banging on my gateway… It doesn’t matter.
1 Like
This guy (apparently a company) is sending over a join request every 7 sec, 62ms airtime, so roughly 1% duty used for nothing (& this node doesnt seem moving, prob waiting for a private gateway passing by…doesnt make sense) . I understand that may sound like a drop of water but still this guy pollutes the surrounding leading in interfering with other potential users (I got nearly 100K messages/month in this area). What we do is clearly for the community but on the other hand I can see it has brought businesses : they dont share their network, they prob dont spend much time on a proper setup & they just ‘throw’ devices in the field. Although uncontrollable, ideally it shall be avoided.
1 Like
Aside: I don’t think we know who owns the device. But the AppEUI is owned by a company that seems to host a service like TTN. Contacting them might help finding the owner of the bad device.
The node being complained about isn’t “using” TTN anyway. That it shows up on a TTN gateway is essentially irrelevant - a tiny bit of back-haul traffic and server capacity gets spent passing the packet on and then discovering there is nothing to do in response.
Banning it at the gateway wouldn’t really change much - passing on traffic from foreign nodes is routine, and is not considered to be a problem. The actual problem would be th air capacity, but TTN gateway behavior has nothing to do with that.
Also most likely the reason it keeps issuing join requests is that nothing is responding to it - its strategy is of course broken to be continually issuing requests so frequently, but its traffic is essentially “is anyone there?”
With traffic that frequent you could potentially do some direction finding.
Good news, finally the company “REQUEA” handling this node replied today, they said this was an old node with a ‘bugged firmware’ and they have disabled it. Indeed they gave me the exact location and it was located in the alpes mountain 174km straight line from my gateway.
This node was emitting from 3800 meters altitude close to the “Refuge du Gouter”…Althought the relatively long distance the signal was still strong with lots of other gateways to be potentially receiving also. Cheers!
7 Likes