Feature: limit number of concatenated MAC commands

brocaar / chirpstack-network-server

ChirpStack Network Server is an open-source LoRaWAN network-server.

https://www.chirpstack.io

MIT License

1.5k stars 548 forks source link

Feature: limit number of concatenated MAC commands #426

Closed jbiveroni closed 4 years ago

jbiveroni commented 5 years ago

Is this a bug or a feature request?

Feature - see also #420

What did you expect?

We have issues with AS923 devices using the RN2903 for AS923 (seems to be non-compliant). It is not coping well with downlinks containing multiple MAC commands. However, if we limit the number of MAC commands per message to 1, it works (validated on Actility network). I assume that this could affect other users as well.

Could that be implemented as a device profile setting? MaxConcatenatedMACCommands=1

Maybe also: Enable/disable individual MAC commands? See #420

Can your issue be reproduced?

Yes

brocaar commented 5 years ago

Could you define:

It is not coping well with downlinks containing multiple MAC commands

What happens in such a case?
Does this also include multiple mac-commands of the same type?
Have you already reported this issue to Microchip?

Ideally I would not include such feature into the code-base as the issue is clearly with the device. A workaround is fairly easy, e.g. you could edit this function https://github.com/brocaar/loraserver/blob/master/internal/downlink/data/data.go#L724 and make sure only none or one ma-command block is set to ctx.MACCommands (note that a single item could contain multiple mac-commands of the same type, e.g. needed when re-configuring the channel-mask, you either want them all or just drop all of them!).

jbiveroni commented 5 years ago

In the case of receiving a block of multiple MAC commands, the RN2903 AS923 firmware would crash, e.g. become unresponsive.
Not sure what happens if we have e.g. a block of LinkADRReqs only. Need to test that.
Not reported to MCP so far (firmware is not official, we expect no support).

I understand that including such a feature is not a major concern. But I thought some MAC-command tweaking could be interesting for others, too.

Anyway, thanks for the great work! I am really impressed.

brocaar commented 4 years ago

I will close this issue. Adding support for limiting the number of mac-commands will add some unwanted complexity to the code that should not be needed. In the last release I did include a feature which limits the scheduling of downlinks after receiving x nACKs. This should solve some issues for some devices.

The Microchip RN devices are a pain, it is not only the RN2903 AS923 firmware. I have seen quite some other issues with these devices, which I have reported to Microchip.