I have the same problem in Augsburg. Gateway gets every 6 seconds. a request.
Can you prevent that?
Can you provide any additional identifying information?
Oh wow, I was expecting join requests, that just looks like ABP spam.
We might be able to circle the location of the transmitter a little. Here in Kriegshaber the packages hit with “rssi”: -103, “snr”: 3.8.
How about you?
is also above, -118, -8.5
Doing measurements with a directional antenna on multiple locations may help find the location of the source (but does not prevent the flooding itself).
is also above, -118, -8.5
Yes, I saw it , but where is the Gateway?
@TobiasAlora
Is your Gateway the new one between the Kobel- and the Holzweg? Then unfortunately our gateways are very close together. So the change to determine the direction of the transmitter is very low.
It would be interesting to build a mobile LoRa sniffer with which you could circle the transmitter. Is there such a thing already?
1 Like
is in Gubener Str. I’m already thinking about switching to indoor.
Apart from the fact that this device is probably exceeding the limits set by law, where’s the problem with regard to your gateway? A packet every 6 seconds will hardly cause any load on your gateway. It could probably handle dozens if not hundreds of packets per second.
Looks strange that you where flooded from Russia.
But it looks that somebody bring some thing online with a russian dev_adress.
All TTN dev_adress started with 26 or 27, and this one with 17, if you look to this page. https://www.thethingsnetwork.org/docs/lorawan/prefix-assignments.html you see everthing starting with 0x16/0x17 could be Russia: EveryNet (0x0b).
And without romming on lorawan you recieve them but you can do nothing with them.
Or some one has make a failure in programmering their device.
regards
I have used a single channel gateway that was modified to trace OTAA join requests. In this case I successfully hunted for some devices that ware wrongly commissioned and sent continously OTAA join requests. The code base can be used for your case:
Let’s please educate the users on the forum by not calling it gateway. 
Single Channel Packet Forwarders (SCPF) are obsolete and not supported
If the packets come this frequently, it should not be much complicated to make a cross bearing with a Yagi or similar antenna and a wide band scanner or gateway from some higher points of the city. Maybe it’s a GPS tracker in a car or truck. I guess I would find such a transmitter within 2-3 hours with this 6 seconds period and 1.6s. Maybe you could ask a local ham radio guy, they often like to hunt such “foxes” and have the equipment as well.
1 Like
Sorry @bluejedi but in this case NO . I do adocate the use of multi-channel gateways for that purpose, but not in this case. This way was the the quickest and simplest way to receive uplink packets and sniff them. Yes because of the use of a single RFM95 for this trick I miss 1/3rd of my join request packets. Therefore the royal way is to use a concentrator board and sniff all packets. btw: did you notice that the gateway function was NOT the primary objective?
Let the code example inspire and be the source of new knowledge.
Yes, i did use a single channel gateway for my code base and found the nodes that troubled our gateways within 1 hour. It saved me weeks of development of new code.
Please don’t call a SCPF a gateway. That’s what the topic title is trying to say.