Thanks for the response. In this case it appears that with prolonged gateway outage, our module is backing off and correctly following the LoRaWAN spec and enabling all channels for transmission. The problem is that we are then only getting roughly 1 in 8 packets received since we’re operating on a single sub-band (US915 sub-band 4)
When the gateway is back online the LinkADRReq bit is set and Chirpstack does send a channel mask to the device, but this is only with chMaskCntl 1 enabling sub-band 4 as per our .toml file, but not sending chMaskCntl 7 which would disable the rest of the unused channels. So the modules continue to transmit on all channels.
We inquired with other network server vendors (Tektelic for example, who provides our gateway) and have confirmed that on their network server, the LinkADRReq response does in fact send chMaskCntl 7 to clear the other channels. Chirpstack seems to only do this on the initial JoinAccept.
This is described in more detail about a year ago in issue 558 (LinkAdrReq command to use ChMaskCntl 5 (US915 Region) · Issue #558 · brocaar/chirpstack-network-server · GitHub) by another user. It seems that they have also tested with other network servers and they all seem to send chMaskCntl 7 before setting the correct channel masks in the LinkADRReq download. In the issue on github, it seems like there was a little bit of back and forth conversation regarding the interpretation of the LoRaWAN spec and what (if anything) the NS should do in this case. We are fairly convinced that the NS should clear the channels and set the correct channels as per the .toml file in the LinkADRReq downlink packet as is the case with other network servers.
As you mentioned, the only way to detect this issue is with an increase in packet loss. We took a loss rate of 80% and assumed that these modules were affected. We then used the NS API to manually push two MAC commands to the downlink queue (chmaskcntl 7 and chmaskcntl 1 0x00FF while also setting DR0) and have successfully brought these modules back to 0 packet loss, however continuously checking for this case isn’t an ideal long term solution. I was hoping we could quickly fix this this as part of an ADR plugin, but it doesn’t look like we have access that kind of low level MAC command in the ADR plugin. Best case we have the behaviour corrected in Chirpstack in the LinkADRReq downlink. I’m hoping this can be done as part of an official release as opposed to a custom branch.
Thanks again for your assistance.