fCnt resets when restart node

Hi!
I have a device with OTAA activtion, after Join it works perfect, but after I restart it - the fCnt is 0 again (I`ve tested this device with other server - it works perfect, fCnt not reseting). What the reason can be? Can it be caused by wrong base station config?
I will be glad to any help

PS: Also works properly with TTN server - frame counter doesnt resets

If i’m not mistaken, FCnt should reset in every join-accept for OTAA.

When you restart your device and it re-activates, then resetting the frame-counters is expected behaviour as @Rafael_Albarello already mentioned.

Yes, but my device saves session in EPROM, so, when the device turns on - for the first uplink it uses old keys (try to connect as ABP device). And, as I say it works with The Things Network lora server, but on the same device and the same base station fCnt resets after I turn off device. I know how it sounds :slight_smile: but it is what I see.
Here live frames after join:

And here after device reboot:


And log from first uplink after reboot:
{ "uplinkMetaData": { "rxInfo": [ { "gatewayId": "8cf957ffff800399", "time": null, "timeSinceGpsEpoch": null, "timestamp": 4001634644, "rssi": -54, "loraSnr": 9.8, "channel": 6, "rfChain": 1, "board": 0, "antenna": 0, "location": { "latitude": 0, "longitude": 0, "altitude": 0, "source": "UNKNOWN", "accuracy": 0 }, "fineTimestampType": "NONE" } ], "txInfo": { "frequency": 869100000, "modulation": "LORA", "loRaModulationInfo": { "bandwidth": 125, "spreadingFactor": 12, "codeRate": "4/5", "polarizationInversion": false } } }, "phyPayload": { "mhdr": { "mType": "UnconfirmedDataUp", "major": "LoRaWANR1" }, "macPayload": { "fhdr": { "devAddr": "0061b443", "fCtrl": { "adr": true, "adrAckReq": false, "ack": false, "fPending": false, "classB": false }, "fCnt": 0, "fOpts": [ { "bytes": "Ag==" } ] }, "fPort": 2, "frmPayload": [ { "bytes": "QKQlSMOgwwRz9cgRyCcNE11usf02b8ivRHghbNqlkQ==" } ] }, "mic": "869db67b" } }

And for example logs from another Lora server -

here device was rebooted 2-3 times.

Maybe I can show some other logs to say what happens? Just say!

When the device resets its frame-counters but does not perform a new OTAA, then you run into the issue that LoRa Server rejects all frames until the frame-counter did increment to the frame-counter known by LoRa Server. This is how it should be to implement a secure network.

Some networks, LoRa Server included, do provide an option to disable this frame-counter check. This can be enabled per device in the LoRa App Server interface.

Yup, I know about it. I need to have frame counter on, because in order to have stable delivery my device sends 3 uplinks with same counter, so I need frame counter to receive only one uplink.

But also if I turn off counter - there is another problem with response to MAC LinkCheckReq message, I already asked about it here (I thought it was about rx delay, but you showed me that it’s not. By the way I steel can’t understand the problem)

@brocaar, to conclude all higher: you think that the problem is in the device software, right?
Or maybe you have an idea where I’ll have to search?

When you reset the device and it keeps the session-keys, but resets it frame-counters, then yes that is a problem with the device.

Ok, thanks! I’l check device more attentively

@brocaar, hi again! I made some investigation and found out that there are some strange things in loraserver downlinks when it responses on MAC commands.
(I’m using 1.0.2 spec of lorawan)
Now I can see all PHYPayload on my device - uplinks and downlinks, so:

Here are Uplinks and downlinks from other server


Look at the FHDR part - according to spec. - 4 bytes are devAdr
Now loraserver:

Here i can’t see devAdr in downlinks
BUT!
If I send downlink by hands via API - message is in correct format with devAdr on it’s place

When you look at the PHYPayload received by your device, then the device could also be the issue :slight_smile: You have to look at what LoRa Server sends to the gateway/..../tx topic. You’ll find the base64 encoded PHYPayload in these messages.

Oh, you a right - I looked in the base station logs and in gateway tx topic, messages are correct.
But it’s still magic… when downlinks sends manually with lorasaerver all ok, when MAC messasges - fail(despite the fact that message sent from bs correctly)
and with TTN works fine… uh

I would look into the mac-commands which are triggering your issue. TTN might not send the same mac-commands that LoRa Server sends and one of them could potentially cause this issue at the device side.