Like you wrote elsewhere: TTN deployed a fix to send commands on SF12 if a node is erroneously expecting RX2 to use the LoRaWAN default SF12 rather than the TTN EU868 SF9, and is not responding to the SF9 ADR command.
This specific node is now at SF8, since it received the new 22 bytes network settings on SF12 at 11:57 below, after the earlier 17 bytes message on SF9 did not make the node change its settings:
This particular device is not registered to TTN as far as I can see, so unfortunately there’s not much we can do except hope that it quickly runs out of battery.
I think all ttn gateways should blacklist such addresses in a way, that the gateway’s and backend’s processing power ist only minimally used… i consider this also as misuse of my internet and lan infrastructure if it is not blocked in the future…
The address itself is not the problem, it’s a perfectly valid address that could be registered to TTN.
Blocking devices by address introduces a DoS attack surface, as anyone can transmit data with the same address as an authentic device. The gateway won’t be able to tell the difference, and we don’t want to stop serving compliant devices if this happens.
Also, blocking traffic won’t solve the problem. The only real solution is to track down the device or the owner of the device.
The real problem is that no one is actually obliged to follow LoRaWAN spec (or TTN fair access policy). So a couple of dozens of LoRa (but not LoRaWAN) devices can practically block all the LoRaWAN devices in some km. around still being compatible with legal requirements. That was known from the very beginning.
So I’m really surprised with the news about LoRaWAN-based street lights control systems etc. LoRaWAN (and LPWAN at all) surely wasn’t designet for such critical apps.
Thats interresting. So an attacker who wants to take out a gateway for whatever reason only needs to bundle a few nodes, make each node use one of the lora frequencies and never change frequency and send long data with sf12 every few seconds to completely make a gateway inoperational by this kind of DOS atack…
LoRaWAN has always been a best effort technology, never intended for critical control. The same goes for e.g. WiFi. You can easily disturb all WiFi networks in a radius of a few miles if you really want to.
If criminal abuse ever happens, I think telco’s will be swift to locate and root out the cause. I think the chance of an accidental DOS attack is much higher, but that could be solved with additional gateways.
It’s enough (but illegal) to have eight transmitter to almost block a typical gw. Just set preamble length to max. possible value (64K symbols), SF12, max. power (you may find 500 mW modules on the market ) and start transmissions on each of eight channels.
And be surprised that transmissions on other spreading factors still make it to the gateway? LoRa allows for simultaneous tranmission on 1 frequency with different spreaing factors…
Putting a wideband “high” power signal with a bandwidth and frequency matching an application (like gps / gsm / FM radio / wifi ) will block that application. Receiver blocking by an in-band interferer is a problem for 95% of every wireless link on the world. This is why we have authorities and regulations to guide spectral usage, that is why there is a duty rule.
I am afraid that the only way to deal with is to accept it, this is the ISM band, you have to share it with others, you don’t own it.
I’m thinking about getting ten units. Street lights are Class C nodes, with ten transmitters I most probably can legally block their RX2 Oh, I even don’t need GWs, ten half-Watt modules are enough…