class-c downlink queue processing issue. NS sends mac-commands but never reach payload data.

[fancar]

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

What happened?

ns keep constantly sending downlinks to class-c device, which is offline if a message in the device queue for the device is present. It happens because every iteration ns sends mac-commands in frame payload, not application data. So the task won't be removed from the queue during ACK.

What did you expect?

ns shell not send mac-commands at all.

Steps to reproduce this issue

Steps:

1. add a new class-c device.
2. Switch it off after it sends the first uplink.
3. put a message in a queue.
4. in case if ns will decide to send a >15 bunch commands in the frame payload, you will see the loop: ns sends downlinks every 2 seconds (lock time).

Could you share your log output?

Your Environment

Component	Version
Application Server	v3.13
Network Server
Gateway Bridge
Chirpstack API
Geolocation
Concentratord

[fancar]

The note I've found in TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification

2285
A Class C downlink SHALL NOT transport any MAC command. If an end-device receives a
Class C downlink containing a MAC command, either in the FOpts field (if FPort is either
missing or > 0 ) or in the FRMPayload field (if FPort=0 ), it SHALL silently discard the entire
frame.

If it's still relevant, then the solution is just removing setMACCommandsSet from scheduleNextQueueItemTasks

[brocaar]

Thanks @fancar , the above commit fixes the issue.