Hello, I noticed recently in the traffic of my gateway (open to everybody) that a device obviously bugged keeps sending a join request every 10 seconds. Is it possible to ban this device from my gateway so that the bandwidth is kept for other relevant devices?
Sorry, the answer is yes and no, the only way to reduce the resource usage by that node is to find it and power it down.
Even if you could filter it at the gateway the node will still be transmitting and ‘consuming’ airtime where its transmissions will interfere with other nodes transmissions.
Does your gateway transmit join responses? In that case it would help if you could filter it as that would reduce transmissions from the gateway.
BTW it would help if you specify what kind of gateway running which software you have if you want people to answer questions regarding what is possible…
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.