Enable relax frame-counter flag taken into account

[abouillot]

Hi,

I'm developing node stack and still in the early stages. I haven't yet implemented the persistent counter on the node, but it will be needed at some point. Therefore, I often restart the board and when using APB join mode, I always end up in invalid count wether the Enable relax frame-counter is activated or not for that node. It is usually 2 while receiving 1 - it's early stages.

Is this setting operational or not?

[brocaar]

Hi @abouillot, please note that relax frame-counter only kicks in when it receives a FCnt=0.

[abouillot]

Some stacks have an initial counter set to 1. I've changed mine and still receive the message: {"devEUI":"1100000000000011","type":"DATA_UP_FCNT","error":"invalid FCnt or too many dropped frames (server_fcnt: 2, packet_fcnt: 0)"}

When resseting the node's Fcnt on the server interface, the packet is accepted, but this is not practical.

[brocaar]

For the above example, did you activate the relax-frame counter? Please note also that changing this setting in LoRa App Server means you have to re-activate the node so that it provisions LoRa Server with this updated config.

The relax frame-counter option is a "hack" to work around this issue and is not safe (e.g. it opens the option for replay attacks). Regarding some nodes starting their frame-counter at 1, I think that is a bug in the firmware, as the specs states that after a reset the counters must be reset to 0:

After a JoinReq – JoinAccept message exchange or a reset for a personalized end-device, the frame counters on the end-device and the frame counters on the network server for that end-device are reset to 0

[minggi]

I have the same problem with my Adeunis RF LoRa Handtransmitter. The relax frame-counter is enabled. But it works only if I set manual the Uplink frame-counter to "0".

[brocaar]

Sorry guys, but I think there is no better way to handle this I think. Enabling the relax frame-counter introduces already a security risk (it enables replay-attacks). When your node sends a FCnt < expected FCnt the frame must be marked as suspicious, that is the whole reason why there is a FCnt.

When you reset your node (ABP) node, enable the relax frame-counter mode (knowing that you're introducing a security risk) and make sure the first FCnt=0 and that that frame is actually received by the network-server. That is the only way the relax frame-counter will kick in.

When you want to be secure, perform a new OTA or persist the node state / FCnt values before resetting.

[minggi]

But in this case I can't use the Adeunis device or my other LoRa devices.

I know, the relax frame-counter is a security risk, but there are no device on the market that can handle this better. Your LoRa Server works perfect for us, but this "problem" is a killer issue for me at the moment. We don't have this issue with other commercial LoRa Servers. I think they have another handling of this relax mode.

[brocaar]

@minggi could you elaborate why you can't use your devices? Most if not all devices support OTAA which is a secure way to reset the frame-counters, without the need of the relax frame-counter mode.

[minggi]

First: We don't use OTAA. I will analyse the whole process. Give me a few days.

[abouillot]

Is there a reason to not use OTAA? The implementation is pretty straightforward and transparent from the node side and backend application, and increase the security over replay attacks, among other.

I hardly believe Adeunis device doen't store it counter in a persistent way, preventing a normal usage in ABP mode.

I raised the initial issue while in early stage of developing the device, where the persistent storage isn't yet implemented, but this definitely should be done down the way.

The main issue I see with Brocaar implementation, is that the counter of the reference implementation from Semtech used 1 as initial counter value until recently and this might be present on all/most existing nodes deployed so far, as the implementation has been approved by LoRa alliance.

Maybe, and this is just a suggestion, a 'extra relaxed counter' option might be implemented to support the development stage, with all UI/UX warnings.

[brocaar]

@abouillot ah, I wasn't aware that this was actually implemented this way in https://github.com/Lora-net/LoRaMac-node. I've been testing with a node from IMST (which uses LMIC) and a node from Microchip (RN2483), both nodes start with 0 as the initial frame-counter.

Do you know this has been solved in the LoRaMAC-node by now?

[abouillot]

I raised on LoRaMac node after I raised the issue here. It has been integrated in master branch on Feb 23 https://github.com/Lora-net/LoRaMac-node/commit/e5277e2209fe833983e4ed7296f711ee0543f0c8, in 4.3.1 release.

[minggi]

It looks like the Adeunis RF device sending the first payload with a cnt "1" and not 0. Error after a device restart: lora-app-server.log: time="2017-03-06T06:32:25Z" level=error msg="invalid FCnt or too many dropped frames (server_fcnt: 72, packet_fcnt: 1)"