Hi,
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
Results in:
panic: interface conversion: lorawan.MACCommandPayload is *lorawan.DutyCycleReqPayload, not *lorawan.LinkADRReqPayload
- Send 3 LinkADRReq + 1 RXParamSetupReq
Results in:
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 thecid
ofCreateMACCommandQueueItem
to0x03
(LinkADRReq
)
So my questions are:
- Is it correct that the
cid
parameter ofCreateMACCommandQueueItem
can beLinkADRReq
while the payload contains different MAC commands (with theircid
specified in thecommands
)? - 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: 2c9ee5e
.
Thanks,
Zul