Since yesterday I monitor a node (Dev Addr: 260B3023) that transmitts a confirmed uplink with 27 bytes every minute with SF12/125kHz. The confirmation is accompanied by a 12 bytes downlink (I don’t see this download in the V2-console, maybe it’s V3?).
These downloads exeed the duty-cycle of my gateway (EU868 DE-Cologne East).
The duty-cycle of a gateway doesn’t seem to be limited by TTN or by the gateway (Dragino LIG16) itself.
Is there a possibility to exclude or blacklist these misbehaving nodes?
1 Like
To my knowledge you can’t. Ok, in reality you can but you shouldn’t. The TTN must handle this or the authorities (if he is breaking the law).
For TTN something is on the way.
Only CONFIRMED uplinks? Absurd.
With a directional antenna and a little leg work, you may be able to find the location, or enough of a location that you can do a leaflet drop.
Or we could ask @laurens or @htdvisser if they are able to make enquiries as this is clearly an egregious breach of the FUP, assuming from the Dev Addr that it is a TTN / TTI user.
The problem is that it’s allegedly causing the gateway to break the regulations.
Architecturally, it’s true that this should be handled at the network level. But as long as the network is going to ask gateways to violate regulations, refusing to forward confirmed uplinks would be a reasonable defense measure until that’s fixed.
Waiting for someone else to do something isn’t technically an option.
It is causing the gateways to break the regulations. The technical solution is to switch off the gateway. But this cannot be in the sense of the community.
In V3 there is a checkbox concerning this problem - but it doesn’t seem to work.
Technically you can modify the gateway to drop packets of specific device addresses. This will stand until the device changes device address next OTAA and is therefore not the right approach.
I doubt if the gateway is breaking law when TTN server is controlling the downlink duty cycle for the gateway.
One last thing is to start a small fox-hunt to locate the device. From personal experience I know it can work: We had a number of wrong commissioned devices in our community that kept sending join requests. For this I modified a single channel gateway to report signals that met the criteria of the devices. The code is here and might inspire you to adapt it or build a different solution yourself: GitHub - pe1mew/PE1MEW_OTAA_Tracer: A tracker to locate LoRaWAN nodes that fail to personalise using OTAA.
4 Likes
imho the TTN-server is not controlling the duty cycle of a gateway, neither in V2 nor in V3. But I agree that it should.
My last fox-hunt is abt. 25 years ago on 80m. I think it can be hard to find a fox that is transmitting every minute for 1.5 seconds.
I am using a Dragino LIG16 as gateway and I am not able to modify its firmware. But maybe @edwin is.
In V3 you can check with CLI
This is from my GW. It was on V2, reverted only for you to V3 to show you the stats. So you can’t see the ‘airtime’ calculations.
ttn-lw-cli g get-connection-stats nfuse-sx1308
{
"connected_at": "2021-03-29T06:56:40.663826583Z",
"protocol": "udp",
"last_status_received_at": "2021-03-29T07:01:40.661756640Z",
"last_status": {
"time": "2021-03-29T07:01:40Z",
"boot_time": "0001-01-01T00:00:00Z",
"versions": {
"ttn-lw-gateway-server": "3.11.3"
},
"ip": [
"ERASED"
],
"metrics": {
"ackr": 0,
"rxfw": 0,
"rxin": 1,
"rxok": 0,
"txin": 0,
"txok": 0
}
},
"last_uplink_received_at": "2021-03-29T07:04:57.313285416Z",
"uplink_count": "2",
"sub_bands": [
{
"min_frequency": "863000000",
"max_frequency": "865000000",
"downlink_utilization_limit": 0.001
},
{
"min_frequency": "865000000",
"max_frequency": "868000000",
"downlink_utilization_limit": 0.01
},
{
"min_frequency": "868000000",
"max_frequency": "868600000",
"downlink_utilization_limit": 0.01
},
{
"min_frequency": "868700000",
"max_frequency": "869200000",
"downlink_utilization_limit": 0.001
},
{
"min_frequency": "869400000",
"max_frequency": "869650000",
"downlink_utilization_limit": 0.1
},
{
"min_frequency": "869700000",
"max_frequency": "870000000",
"downlink_utilization_limit": 0.01
}
]
}
1 Like
At which frequency are the downlinks transmitted? If at 869.525 that would be in the 10% allowance part of the frequency band. In that case you are probably exceeding allowed transmission time. (And unless there is an issue in V3 you won’t be exceeding allowed transmission time if you keep the check mark set the right way)
The downlinks are transmitted on the same frequency as the uplinks. Therefore only 1% duty cycle is allowed. After abt. 20 confirmed uploads of this node my 36sec (per hour) are consumed.
In the V3 console (the LIG16 is in V3, my LPS8 is in V2 but indoor) I checked the box “Duty Cycle Enforced” but this seems to be ignored.
@clv : thank you for your investigation, I never saw “downlink_utilization_limit” before.
1 Like
Sounds like you need to file an issue for the V3 stack that the duty cycle for gateways is’t being enforced. @htdvisser is there a known issue with duty cycles for gateways not being observed?
Unless a gateway owner explicitly disables duty cycle enforcement, The Things Stack (v3) is very strict in enforcing the duty cycle, so I can hardly imagine that any gateway on v3 would transmit more than it’s legally allowed to. Important to add here is that changes to the “enforcement” checkbox are applied the next time the gateway (re)connects.
There is a difference in implementation between v2 and v3 that may cause some confusion here. V2 used a 1-minute duty cycle enforcement window, so if you look at a 10-minute time period, it would never exceed the duty cycle. V3 uses a 1-hour window, which allows bursts (that’s useful for for firmware updates over the air). If you’re then looking at a 10-minute window during such a burst, it may look like the gateway exceeds the duty cycle, but if you look at the full hour, it will not.
5 Likes
If I understand that right, there must and can not be used more than 36 seconds in one hour for one gateway.
Is this sufficient for 40 receptions/ transmissions in one hour like this:
“3/29-10:59:03 Data Confirmed Up LoRa 868.1 SF12 BW125 4573 Dev Addr: 260B3023, Size: 27”
“03/29-10:59:03 Data Unconfirmed Down LoRa 868.1 SF12 BW125 4560 Dev Addr: 260B3023, Size: 12”
Maybe this not only a misbehaving node but also a misbehaving gateway?
Using https://avbentem.github.io/airtime-calculator/ttn/eu868/27 I get 79 seconds of uplink airtime and 59 seconds of downlink airtime.
It may be worth cycling the power on the gateway so it has definitely setup on the NS for enforcement.
But still egregious enough in my opinion for someone to see if they can identify the miscreant from the TTI side of things. If we can’t police our own network and the authorities do, we’ll end up with far less gateways.
1 Like
I rebooted the gateway several times. But nothing changed.
Then, after a few hours the downloads were reduced to 6 per hour. It uploads still 40 confirmed messages per hour.
When a V2 gateway forwards to V3 and gets downlink requests in response, how is the tracking of total duty cycle accomplished?
When your gateway reboots/reconnects it loses its state (including the recent transmissions that are used to compute duty cycle), so if your gateway reboots frequently, that could also be an explanation.
All gateways connected to TTN (v2 with v3 forwarding or v3 directly) are compliant with the 1-hour duty cycle limits. Downlinks from either v2 or v3 will get rejected if the total duty cycle is at the limit.
Um, no, it would appear that it was re-booted solely for the purpose of getting the duty cycle to work.
What does a gateway need to contribute to the NS’s computation of duty cycle - as it’s the NS that commands all the downlinks, it knows everything …
Are we given to understand that TTI aren’t invested in helping track down this miscreant using their network?
Given the Dev Addr listed above (Dev Addr: 260B3023) TTI team should be able to identify the node(s) registration in the back-end - reuse means there may be several as address pool is constrained, from that list TTN user should be identifiable and its then a process of elimination to find the most likely person - in Cologne area?.. a quick email to say “oi mate your node is mis-behaving, please check” should be straight forward 
(Or to several potential users if there are options that might fit)… @htdvisser can this check and contact be done? Perhaps put them in contact with @wolfp to see if they can co-ordinate and solve any systems issues, assuming there are no privacy issues…pehaps refer them to this thread and ask them to get onboard and solve?
The Things Stack knows, but it doesn’t persist this state. So when the gateway reconnects, this is reset.
This takes at least a few hours. Per end device that someone misconfigured on a free service. I really don’t know how you expect the TTI team to become the global LoRa Police and to set a precedence on hunting down misbehaving end devices.
We are working on detecting misbehaving devices automatically and take action. See Handling Non-Compliant End Devices · Issue #3864 · TheThingsNetwork/lorawan-stack · GitHub
1 Like