Hi!
From what I can see on my gateway data, some devices uses much more than the DC they should respect.
About a message of 26 bytes every 3 seconds using SF11… giving an airtime of 823ms/message and giving a total airtime per day of more than 23 k seconds per day.
Is there any way to report this kind of abuse ?
Just block the device. You’ve obviously identified it and know its DevEUI otherwise how would you know it is a single device.
Andrew
I don’t have the devEUI because they seems to use ABP (no joins and counter going back to 0 every 24 hours).
I know they are the same from devAddr + SNR/RSSI 
Implement a black list in the poly packet forwarder?
I don’t see why blocking/blacklisting would help (unless the gateway is on some metered connection).
If the DevAddr is a TTN address (starting with the hexadecimal 0x26 or 0x27) then it would be nice if TTN can block this; this would be a good use case for the Fair Access policy.
If the DevAddr is not TTN, then assuming the gateway forwards to TTN, then the packet will be dropped anyway. So filtering in the gateway has no effect.
The most significant 7 bits of a DevAddr are known as the NwkID, and match the least significant 7 bits of the NetID (network identifier). TTN currently uses NetID 0x000013, hence its NwkID is the binary %0010011.† I assume there is some overview of assigned NetIDs or NwkIDs, so we might be able to match the 7 MSB of the abusive DevAddr to one or more specific LoRaWAN networks, and complain there.
So, to repeat the question:
(As an aside: a hardcoded SF11 is not allowed either, so their provider should take some action…)
† Just to verify: hexadecimal 0x26 is binary %00100110, and 0x27 is %00100111, so both indeed start with the 7 bits NwkID.
If the sender rely on specific GW, preventing its data flow might help him realise there is an issue somewhere. Probably useless but might work.
I disagree. Like I wrote before, assuming the gateway is only forwarding to TTN: if the sender uses a TTN DevAddr, then I’d prefer TTN takes some action instead. If not a TTN user, blocking adds nothing. And like you’re suggesting yourself: if the sender happens to be in reach of multiple TTN gateways, then blocking on one is certainly not useful.
My idea is not to avoid having my gateway using a lot of bandwidth or anything.
It’s just that it goes against LoraWan “laws” and I was wondering if there was any king of organization or something that we could contact to report this. I guess I’ll try with http://www.ibpt.be/ - The Belgian institution for telecom.
The fact is that the company running those nodes (about 25) is operating their own single chan, uplink-only gateway and when I contacted them, they clearly told be that they don’t care about limitations, norms, and everything related to best practices.
So to keep a good network quality and sustainability in this region, I’m looking how to report this to have them changing their config.
That’s a bold statement for devices that can easily be located. Go harvest some hardware 
And How do you know to who this device belongs to ? I have 3 gateways and one of them in Antwerp is getting data from a device every 10 seconds. (Device ending with 30001)
If it is the same devAddres, it is not always the same device, when i’m testing production samples they all have the same ID. before i go to final programming.
I do have many contacts with the BIPT, and they will not spend time on ISM bands unless there are many complaints, they are to busy wit GSM and 5 ghz radar problems at this time.
This is interesting to know…
Only the LoRaWAN network operator can (emphasis mine):
Device Address Assignment
The Things Network Foundation has received a 7-bit device address prefix from the LoRa Alliance. This means that all TTN device addresses will start with
0x26or0x27(although addresses that start with these might also belong to other networks with the same prefix). Within TTN, we assign device address prefixes to “regions” (for example, device addresses in theeuregion start with0x2601). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in theeuregion start with0x26011) or to shard devices over different servers.
[…]
It’s good to keep in mind that device addresses are not unique. We can (and probably will) give hundreds of devices the same address. Finding the actual device that belongs to that address is done by matching the cryptographic signature (MIC) of the message to a device in the database.
You’d need a list of NetIDs (or simply a list of LoRaWAN operators in your region) to find the LoRaWAN provider(s) that might be handling a given DevAddr. If it’s not a private network to start with.
So, there are 25 nodes on the same channel, with 25+% duty cycle each? 
BTW, which exactly frequency do they use?
And to find the DevAddr: you can see that in the gateway’s “Traffic” page in TTN Console, or get it from a raw packet using an online decoder.
For future reference, in reference to @affoltep seeing a node “which sends almost every 5 second with an airtime of 1.6. second (29bytes, SF12)”, Johan wrote about the Fair Access Policy in Slack yesterday:
@johan [9:26 PM]
Nothing regarding FAP is implemented yet
We’ll starting monitoring soon though
And here is a list of NetIDs @johan posted on Slack, enhanced with the two possible prefixes for the DevAddr, which match the 7 bits NwkID:
NetID, DevAddr MSB, location(s): name
0x00,0x00/01, Local: Experimental nodes0x01,0x02/03, Local: Experimental nodes0x02,0x04/05, World: Actility0x03,0x06/07, Europe: Proximus0x04,0x08/09, Europe: Swisscom0x05,0x0a/0b, Singapore, indonesia , Australia, Africa , India: SingTel0x06,0x0c/0d, Europe: La Poste0x07,0x0e/0f, Europe: Bouygues Telecom0x08,0x10/11, World: Orbiwise0x09,0x12/13, U.S: SENET0x0a,0x14/15, Europe: KPN0x0b,0x16/17, Russia: EveryNet0x0c,0x18/19, Africa: FastNet0x0d,0x1a/1b, World: SK Telecom0x0e,0x1c/1d, World: SagemCom0x0f,0x1e/1f, Europe: Orange France0x10,0x20/21, Italy: A2A Smart City0x11,0x22/23, India, Sri Lanka, Nepal, Bangladesh and the Maldives Islands: TATA Communication0x12,0x24/25, World: Kerlink0x13,0x26/27, World: The Things Network0x14,0x28/29, Germany, Switzerland, China: DIGIMONDO GmbH0x15,0x2a/2b, World: Cisco Systems0x16,0x2c/2d, China: Computer Network Information Center & Chinese of Sciences Guangzhou Sub-center (CNIC)0x17,0x2e/2f, World: MultiTech Systems0x18,0x30/31, World: Loriot0x19,0x32/33, World: NNNCo0x1a,0x34/35, World: Flashnet0x1b,0x36/37, World: TrackNet0x1c,0x38/39, World: Lar.Tech0x1d,0x3a/3b, World: Swiss Led0x1e,0x3c/3d, CIS, Europe: Net8680x1f,0x3e/3f, Italy: Axatel0x20,0x40/41, Germany: Telent (Netzikon)0x21,0x42/43, World: Patavina Technologies0x22,0x44/45, North America: Comcast0x23,0x46/47, Australia, New Zealand: Ventia0x24,0x48/49, World: Gimasi0x25,0x4a/4b, World: Talkpool0x26,0x4c/4d, Italy: Telemar0x27,0x4e/4f, World: MCF88 SRL0x28,0x50/51, Malaysia: VADSLYFE0x29,0x52/53, World: GIoT0x2a,0x54/55, World: M2B Communications0x2b,0x56/57, China: ZTE0x2c,0x58/59, Australia: Airlora0x2d,0x5a/5b, World: Rai Way0x2e,0x5c/5d, World: Levikom0x2f,0x5e/5f, South Africa: Comsol Networks0x30,0x60/61, World: SoftBank0x31,0x62/63, World: Inmarsat0x32,0x64/65, World: Gemalto0x33,0x66/67, China: Alibaba Iot BU0x34,0x68/69, Russian Federation: ER-Telecom Holding
Remember that when the list grows, multiple networks might use DevAddr starting with the same NwkID.
And @htdvisser also wrote on Slack:
Unfortunately many networks still allow registration of DevAddrs that belong to other networks, so it’s not 100% accurate
But I’m sure they’ll stop doing that soon enough when the LoRa Alliance starts threatening to take away their allocations entirely
let items = [
[0, 'Local', 'Experimental nodes'],
[1, 'Local', 'Experimental nodes'],
[2, 'World', 'Actility'],
[3, 'Europe', 'Proximus'],
[4, 'Europe', 'Swisscom'],
[5, 'Singapore, indonesia , Australia, Africa , India', 'SingTel'],
[6, 'Europe', 'La Poste'],
[7, 'Europe', 'Bouygues Telecom'],
[8, 'World', 'Orbiwise'],
[9, 'U.S', 'SENET'],
[10, 'Europe', 'KPN'],
[11, 'Russia', 'EveryNet'],
[12, 'Africa', 'FastNet'],
[13, 'World', 'SK Telecom'],
[14, 'World', 'SagemCom'],
[15, 'Europe', 'Orange France'],
[16, 'Italy', 'A2A Smart City'],
[17, 'India, Sri Lanka, Nepal, Bangladesh and the Maldives Islands', 'TATA Communication'],
[18, 'World', 'Kerlink'],
[19, 'World', 'The Things Network'],
[20, 'Germany, Switzerland, China', 'DIGIMONDO GmbH'],
[21, 'World', 'Cisco Systems'],
[22, 'China', 'Computer Network Information Center & Chinese of Sciences Guangzhou Sub-center (CNIC)'],
[23, 'World', 'MultiTech Systems'],
[24, 'World', 'Loriot'],
[25, 'World', 'NNNCo'],
[26, 'World', 'Flashnet'],
[27, 'World', 'TrackNet'],
[28, 'World', 'Lar.Tech'],
[29, 'World', 'Swiss Led'],
[30, 'CIS, Europe', 'Net868'],
[31, 'Italy', 'Axatel'],
[32, 'Germany', 'Telent (Netzikon)'],
[33, 'World', 'Patavina Technologies'],
[34, 'North America', 'Comcast'],
[35, 'Australia, New Zealand', 'Ventia'],
[36, 'World', 'Gimasi'],
[37, 'World', 'Talkpool'],
[38, 'Italy', 'Telemar'],
[39, 'World', 'MCF88 SRL'],
[40, 'Malaysia', 'VADSLYFE'],
[41, 'World', 'GIoT'],
[42, 'World', 'M2B Communications'],
[43, 'China', 'ZTE'],
[44, 'Australia', 'Airlora'],
[45, 'World', 'Rai Way'],
[46, 'World', 'Levikom'],
[47, 'South Africa', 'Comsol Networks'],
[48, 'World', 'SoftBank'],
[49, 'World', 'Inmarsat']
];
function hex(val, len=2) {
return ('0'.repeat(len) + val.toString(16)).substr(-len);
}
console.info('> _NetID, DevAddr MSB, location(s): name_');
console.info('>');
for (let [netId, location, name] of items) {
// nwkId = 7 LSB of NetID:
let nwkId = netId & 0b01111111;
// ...and nwkId = 7 MSB of DevAddr:
let devAddr = nwkId << 1;
console.info(`> - \`0x${hex(netId)}\`, \`0x${hex(devAddr)}/${hex(devAddr+1)}\`, ${location}: ${name}`);
}
Thanks for the overview @arjanvanb ; this is way more useful than my copy paste.
The LoRa Alliance aims not to issue NwkIds that are overlapping in a region. The world allocations, including ours, should be unique globally. Note that parties need to be a Contributor member to get world allocations - we still need to upgrade - otherwise uniqueness is not guaranteed. The idea is that when the NwkId rolls over, from 128, the NwkId skips as long as there’s overlap in the region. Trashcans activated on a nationa Combian network can share address space with a national German network, but device adresses starting with 26 or 27 will be The Things Network’s as our allocation is global.
Note that there’s no such thing as a LoRa Police enforcing things like addressing and duty cycle, but it’s good to follow standards for the sake of the community, the LoRa ecosystem and certification.
I added @arjanvanb’s list to the wiki: https://www.thethingsnetwork.org/wiki/LoRaWAN/Address-Space#address-space-in-lorawan_devices_prefix-assignments
another one to report (ID assigned as “experimental”). seen at GW zh-affoltern (B827EBFFFED390B0)
I suggest again instantiating a help-line (not called ttn police ;)) to take care of such reported issues.