FCnt mismatch between GRPC API and WebInterface for the first packet

[vasalj]

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

What happened?

I am trying to use gRPC API to send a downlink to the device. For the initial/first packet the down FCnt dosen't match the webUI FCnt.

devQueueServiceClient := asapi.NewDeviceQueueServiceClient(loraCommIface.grpcClient)
enqueueDevQueueItemReq := &asapi.EnqueueDeviceQueueItemRequest{DeviceQueueItem: devQueueItem}

if resp, err := devQueueServiceClient.Enqueue(context.Background(), enqueueDevQueueItemReq); err != nil {
        return
} else {
        fmt.Printf("Downlink message has been enqueued with FCnt: %d", resp.FCnt)
}

What did you expect?

The FCnt that comes from gRPC is 0 (The result of above print) but the FCnt that is really sent to the device is 1 (Because the acknowledgment of it also shows 1 rather than 0).

This issue doesn't occur for non zero FCnt (meaning: whatever value I get for FCnt using Enqueue() function call matches the one that I see on WebUI of Chirpstack)

Steps to reproduce this issue

Steps:

1. 2. 3. 4.

Could you share your log output?

Your Environment

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

[brocaar]

Yes, this is possible. Because since the implementation of LoRaWAN 1.0.4 mac-commands get priority over application payloads (per specification). Therefore it might be that the downlink with fCnt=0 is used for mac-commands only and the application payload is re-enqueued with fCnt=1.

ChirpStack v4 solves this issue by giving you an unique identifier (UUID) on enqueue, which is also provided on ack or nack for correlation.

[vasalj]

Thank you for the reply. For some reason, I cannot migrate to Chirpsatck V4 at the moment (I understand also you have already moved to V4 and you may not want to talk about the past!).

I just want to know if there is anyway I can get the real FCnt after re-enqueing is done by Chirpstack? (I send the downlink command with confirmation. Later I will use the FCnt to trace back the response/uplink of the device with the request that I originaly sent using downlink). If this behaviour is always happening for only first packet, then I can increment the FCnt which is result of Enqueue() by 1 when it is zero. I hope this problem doesn't happen for other FCnt numbers?

[brocaar]

The reason why this is happening (I expect) is because after activation, the NS sends several mac-commands to the device to synchronize all configuration. E.g. NewChannelReq mac-commands to configure all additional channels, leaving no room for additional payloads (either becase mac-commands > 15 bytes, or because the max-payload size does not allow sending mac-commands + app payloads together).

In most cases, this situation would only happen in the beginning, once all configuration has been settled this should no longer occur in most cases (unless you make config changes).

A workaround could be to wait until the first uplink with your enqueue. Of course migrating eventually to v4 would be better on the long run :-)

[vasalj]

You are right, after joining, NS sends some mac command with FCnt 0 (As you said, you give priority to mac commands based on specification). UUID in V4 will solve my issue.