Despite disabling frame counter checks, gateway traffic is not forwarded to device after restart

End Devices (Nodes)
1

I have a device that has been online continuously for around six months. It holds the counter in non-volatile memory so that it can resume after a battery failure etc. Today I rebooted the device and now the data does not get through to the application. The device is on the gateway, and I can see the counter value is correct, but nothing on the application console.

There’s almost certainly a bug in the counter handling on TTN side. I’ve tried setting/resetting the counter flags, tried switching between 16 and 32 bit counters etc in the hope that it would reset something on TTN side, to no avail.

It seems the only remedy would be to re-flash the device to reset the counter to 0, which is ridiculous.

2

As the problems seem to have started when you restarted the device, why do think the problem is at the server? Why did you restart in the first place? We’ll need many more details if you want help.

(There is a bug for ABP devices: when editing an ABP device in TTN Console, then TTN resets both the uplink and downlink counters. But you did not make any changes before the problem started, right? Also, see After resetting frame counters, payload is shown on gateway traffic but not in application - #12 by arjanvanb like already mentioned above as well.)

3

Hi Arjan,
I made no changes. The device has been running for over six months. I only powered it down to take it off the bench power supply so that I could put some batteries in it. The gateway sees the join and accepts the join. As far as I know, it’s still ‘joined’ to the network, but after one week still no data in the application. It uses OTAA, not ABP.
Regards
Mark

4

That just doesn’t make sense. For OTAA, a new join should reset the counters to zero. So, either persist the values and don’t do a new OTAA Join, or wipe all data and do a new join. Not some funny mix of the two.

5

Thanks for the reply. Well in that case it could be argued that my code is wrong, as it does not reset the counter to zero when it joins. However, it should not matter as I have counter checking disabled in the TTN console device settings. This is why I suspect a problem on the back end.

The current counter value is 45789 (I can see it on the gateway in the TTN console) but as I say, it shouldn’t matter as counter checking is disabled. Puzzled!

Regards
Mark

6

You should only disable the counter replay security during testing, and even then you should also implement the same in your device then, for the downlink counter.

However, 45,789 exceeds 16,384, which cannot be fixed by disabling the counter replay security. See: How much frame count deviation is allowed?

7

Hi Arjan,

I have 32-bit frame counters so does the deviation still apply?

But thank you - I was unaware of the deviation issue - will go and read it now. That might be the issue.

Regards

Mark

8 
const maxFCntGap = 16384

That could be it - I’ll investigate. Unfortunately I need to open the sewer in which the device is installed - not nice! (And yes, this device is still under long-term test - we’re happy enough with the software, it’s the environmental testing that takes a lot of time).

Thanks for the advice.

Mark

9

For a quick fix, you could use ttnctl to force TTN to know the true uplink counter (or at least a smaller value, that’s within 16,384 of the true value). See After resetting frame counters, payload is shown on gateway traffic but not in application. Your device will still reject any downlinks though, unless you know the last downlink counter as well.

10

Thanks for that. I’ve not used ttnctl before but from looking at the API reference it looks like I need the ttnctl devices set --fcnt-up command. Better get installing. Thanks a lot for the information.

Mark

11

Beware that you also should reset the RX2 settings to their defaults; in EU868 the RX2 settings are set to a specific value in the Join Accept. But until then the defaults should be used. (I’d just wipe all setting when you’re doing a new join.)