Receiving unexpected FCnt identifier for a 1.1.0 LoRa version node

ChirpStack Network Server
1

I have a node configured as 1.1.0 (B) both in the firmware and in the device profile in the application server.

My firmware is complaining that the server is sending downlink frames with FCnt identifier set to 3 (FCNT_DOWN) in contrast to allowed values for a 1.1.0 server that should be one of:

typedef enum eFCntIdentifier
{
    /*!
     * Uplink frame counter which is incremented with each uplink.
     */
    FCNT_UP = 0,
    /*!
     * Network downlink frame counter which is incremented with each downlink on FPort 0
     * or when the FPort field is missing.
     */
    N_FCNT_DOWN,
    /*!
     * Application downlink frame counter which is incremented with each downlink
     * on a port different than 0.
     */
    A_FCNT_DOWN,

    /*!
     * Multicast downlink counter for index 0
     */
    MC_FCNT_DOWN_0 = 4,
    /*!
     * Multicast downlink counter for index 1
     */
    MC_FCNT_DOWN_1,
    /*!
     * Multicast downlink counter for index 2
     */
    MC_FCNT_DOWN_2,
    /*!
     * Multicast downlink counter for index 3
     */
    MC_FCNT_DOWN_3,
} FCntIdentifier_t;

Received downlink frame:

downlink
downlink.PNG1101×719 40.5 KB

2

That’s a bit odd, as far as I can tell there is no such field in a LoRaWan 1.1 packet as an “FCnt identifier”, rather which downlink counter (network or application) fills that field is determined by the fPort being present and non-zero.

In the case you posted there is no fPort or application payload (only MAC commands) so it should be the network frame counter. Is there previous traffic to indicate that 0 is not a valid value for that?

You may need to be more specific about the firmware and context where this occurred.

3

Sorry, you are right. My firmware ST LRWAN 1.2.1 was misbehaving, in the MacCtx structure the Version was set to 1.0.3 while in CryptoCtx structure was set to 1.1.0.
A question arise: my node is working in OTAA, how the proper LoraWAN version should be configured in the node? The node should be forced to be 1.0.3 or 1.1.0 statically or some automatic configuration mechanism is failing?

Thx.

4

As far as I’m aware nodes should gracefully drop down to 1.0.3 mode if 1.1 on the server isn’t available.

Did you manage to get 1.1 working on the ST firmware? I tried configuring it to 1.1 but I was getting MIC errors in confirmed messages on the node.

5

once and for all 1.0.3 or 1.0.2 (with some flag enabled or disabled)

Example in lora.c:

/*!
 *  Select either Device_Time_req or Beacon_Time_Req following LoRaWAN version 
 *  - Device_Time_req   Available for V1.0.3 or later                          
 *  - Beacon_time_Req   Available for V1.0.2 and before                        
 */

#define USE_DEVICE_TIMING

Look at this link in key feature ==> https://www.st.com/en/embedded-software/i-cube-lrwan.html