and another one. seen at GW funlab (B827EBFFFEA00A83)
In Haarlem I’m seeing abuse too, but it’s not actually the uplinks on SF12 I’m worried about. (If all is well then I won’t be using SF12 at all, and gateways can decipher simultaneous messages on the same frequencies if they use different spreading factors. Of course, maybe they cannot handle all 6 SF on all 8 channels at the same time, which for EU868 would be 6 × 8 = 48 simultaneous messages.)
However, I see TTN sending downlinks for many of those requests. (These are unconfirmed uplinks. Given the length, the responses may very well be ADR-related messages.) And those downlinks make gateways, being half-duplex, stop receiving on all channels:
(As an aside: for screenshots, you can easily filter the traffic by entering the DevAddr in the filter box.)
Good that you noticed. This indeed seems to be the backend desperately trying to get that device off SF12 using ADR. Not sure why it just keeps doing that even when the device doesn’t respond… I’ll look into that.
1 Like
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:
Still then, new abuse or bug: the node is not doing any channel hopping anymore 
Any chance you can find an updated list? (Apparently some parking sensor is using 0x70.)
Updated the list with three new allocations. 0x70 is not allocated yet.
This guy is using up its 30sec airtime per day every 3 minutes… in zurich, switzerland
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.
2 Likes
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.
4 Likes
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…
1 Like
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.
2 Likes
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.
I know that. It’s not me who installed these street lights 
Really? Yes, I’m sure they will try, but…
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…
All the eight phys. demodulators will be busy. You can try. That’s well-known “problem” of SX1301/08.
1 Like
The above message is actually for you. Yes, LoRa itself allows that waht you said. But currently existing HW implementation has some weaknesses.
1 Like
Or this forum can make a community activity of it 
. First one to locate the culprit gets a TTN gateway, backer edition.
2 Likes
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.