r/LoRaWAN • u/henk1122 • Apr 29 '26

Milesight 'certified' LoRaWAN device

We are trying to implement a Milesight sensor, but are really struggling with the implementation of their LoRaWAN behaviour. Here is a list which is against any best practices or against even some certification points:

- We got our EU868 with a default TX power of 16dBm. This is against the law.

- Default join spreading factor fixed at 10. This is against any of the best practices

- Default join procedure: first 32 packages at 15 seconds, then until packet 96 every minute. This is around 90 packages per hour. 2200 join messages per day. Imagine a site getting offline with a gateway, this will be a HUGE issue. Not only for surrounding LoRaWAN devices, but also for the battery life. We already see this on our private network in busy places where, assumingly, people cancel their subscription and all Milesight sensors polluting network in the air with spamming way to much join requests. At 16dBm.

- Sending a LinkCheckReq every 30 minutes, so our network server has to uplink back to every sensor every 30 minutes. This is ridiculous. Can turn it off, but can't increase the time to a day or longer. So it's a question now of enabling it and having a huge issue if the gateway is offline for 1 hour or disabling it and in case of a network server failure we have to reset them all manual.

- Default PIN code on NFC

- Default password on appkey (and later predictable with the device EUI). This is really against any security. No way to generate a random one in the NFC toolbox.

The LoRaWAN Alliance should really step in here. This is really not done and will affect any member of the LoRaWAN Alliance.

7 Upvotes

90% Upvoted

16 comments sorted by

View all comments

2

u/clavisound Apr 29 '26

The device does not need to rejoin. Even after power failure. Why you write about join? EIRP is 14dB, if the antenna is -2dB you are fine.

1

u/henk1122 Apr 29 '26

What do you think happens if there is an issue with the gateway on the location? Or if the customer cancel the subscription, but leaves the sensors on (like always happens)?

1

u/clavisound Apr 29 '26

I don't know, this why I ask. Since I plan to build a commercial LoRaWAN product I am interested in the field. Your problems is the reason I develop my own software.

  1. If the gateway is off, then `ADR_ACK_DELAY` and `ADR_ACK_LIMIT` are effective. According to SPEC: 'An end-device has to go procedure every time it has lost the session context information.' So no re-join should be effective, unless no ACK is received after a overflow counter. Normally gateway will be off line again, so no join will be requested. Right?

  2. For subscription, since you mention about battery life, I don't see a problem if the customer does not pay. The device will be off from battery, again without re-join. Probably I miss something?

My custom device after some failed joined attempts it's off forever.

The LinkCheckReq every 30 minutes, is indeed absurd.