Misbehaving devices using up gateway downlink capacity

End Devices (Nodes)
1

I manage a gateway that is swamped by uplinks from a couple of devices trying to join with JoinEUI 24E124C0002A0001. This looks like Xiamen Milesight IoT Ltd devices. Almost every uplink gets responded to by a downlink - most likely the Join Accept. Because there are so many uplinks requiring a downlink, the gateway’s duty cycle is used up.

The gateway is in a relatively high location on a private farm, and these misbehaving devices seems to be somewhere outside the border. I can’t really move the gateway, as I need it at this location to cover the farm. Adding a second gateway to provide more capacity for a 3rd party also does not interest the gateway owner.

Do I have any options to stop these devices from using up my gateway’s downlink capacity? Or is there a way to look up who these devices belong to and ask them to cooperate - either by fixing the issue or by adding their own gateway?

Failed to schedule downlink for transmission by gateway
Schedule in Rx window 1 failed: Utilization 1.0% would be higher than the available 1.0% for priority HIGHEST

Screenshot from 2023-01-03 17-51-13
Screenshot from 2023-01-03 17-51-131380×825 131 KB

2

Perhaps reach out to Milesight (formerly Ursalink before merger couple of years back?) and ask if they can track through their sales channels given DEV EUI? Try Cheney Lee (Sales Director when Ursalink), or perhaps Rena (One of their Sales team) or the generic marketing team (IoT.Marketing@)… you never know…

Otherwise its directional antenna time and a RF Hunt! :wink:

2 Likes
3

It would have been great if TTS had a feature where one could block misbehaving devices.

Currently I’m considering moving the client to a private network and disabling downlinks via the packet broker. That should solve the problem too.

1 Like
4

Perhaps flag to Core team on #Support as device must be registered in TTN for it to be given Dev Addr and Join Accept… they should be able to finger th culprit owner and contact… :slight_smile:

Possibly yes - problem is experience on the Forum over the years suggests one man (or woman’s or…) normal operating device (in their eyes) = annoying use of GW capacity for another’s … with consequently lots of folk then just start blocking normal or possibly slightly mischeavous traffic at will breaking Community spirit and TTN Manifesto (open to all)… :frowning: :slight_smile: Folk asking “how do I block other users traffic at the GW/in Console” is all too regular a question - even if a foreign network traffic GW owners have no way of knowing if that foreign traffic isnt then correctly handled through roaming or PacketBroker arangements… :man_shrugging:

2 Likes
5

If something somewhere on the TTN/TTI network is creating rogue Join Requests, I suspect @adrianmares would love to use his ban hammer …

And I’m sure @johan would love to introduce Milesight to the concept of back off & jitter.

3 Likes
6

May I ask the brand of gateway you are using?

I have seen a Milesight node join and work for a while and the just go into join mode after a week or so, we could not put our finger on the issue.

We made changes on the gateway and the node joined again, with out us doing any thing to the node.

1 Like
7

How would you prevent that ‘feature’ being used to turn a free to use public service, into a private one ?

1 Like
8

Looks like the RSSI : 2 , can it be this high?

image

If it is at 2 it will cause channel bleed and will most probably never join.

image

1 Like
9

Maybe rather “flag” misbehaving devices. This should also show up on the metrics.

10

That’s a different bug:

11

The gateway (MikroTik WAP LoRa8) we had a issue with were adding extra servers, but we could not prove if this were the issue.

1 Like
12

But to the owners of the nodes, via the device\application console, not the Gateway …

2 Likes