I am trying to reproduce an issue that was found on another network server using chirpstack. The issue was on a variation of AU915 while the one I tried to reproduce on is EU868, it is not ideal but that is what I can use right now.
One of the sequences on the issue was the server sends these MAC commands in one frame:
- 3 LinkADRReq
- 1 DutyCycleReq
- 1 RXParamSetupReq
I can separately send those group of MAC commands using the python chirpstack grpc network server API.
... cmd_pack = ... # prepare command payload mac_cmd = ns_pb2.CreateMACCommandQueueItemRequest() mac_cmd.dev_eui = dev_eui mac_cmd.cid = 0x03 for bt in list(cmd_pack): mac_cmd.commands.append(bt.to_bytes(1, 'little')) response = stub.CreateMACCommandQueueItem(mac_cmd)
However, I found problems when I tried to send the following commands in one frame:
- Send 3 LinkADRReq + 1 DutyCycleReq
panic: interface conversion: lorawan.MACCommandPayload is *lorawan.DutyCycleReqPayload, not *lorawan.LinkADRReqPayload
- Send 3 LinkADRReq + 1 RXParamSetupReq
panic: interface conversion: lorawan.MACCommandPayload is *lorawan.RXParamSetupReqPayload, not *lorawan.LinkADRReqPayload
Send 3 LinkADRReq
This one works fine, i.e. the device and server continue to work after the command is sent.
Send 1 RXParamSetupReq + 1 DutyCycleReq
This one works fine, i.e. the device and server continue to work after the command is sent. Here I still set the
So my questions are:
- Is it correct that the
LinkADRReqwhile the payload contains different MAC commands (with their
cidspecified in the
- Could the panic issue from the network server that I encounter be specific for the EU868 that I currently use?
Currently, I am deploying the server by using chirpstack-docker from commit hash: