ABP node stopped working -> Fixed by creating new ABP.. Why? :)

End Devices (Nodes)
1

Hi all! I have been playing with TTN for a week now and I have a working PROMINI (3,3v, 8mhz, 328) + RFM95 + u-blox GPS node. Everything is working as expected and I have been tracking my activity for a 2 days. The range is excelent btw, had some 10km+ frames near Lopik, NL (Gerbrandy tower) using a simple 86mm wire as an antenna.

I registered my device using ABP and I send 1 frame every minute (only while traveling ± 100 frame per day), packing the GPS data into 2x32bit integers thus sending 8 bytes per frame.

This weekend everything stopped working after one of my soldering joints to the RFM95 module broke. After resoldering the joint everything seemed to work (checked using serial monitor) but I did not receive any frames in the TTN console. I was afraid I bricked something leading to the antenna so I checked the 868mhz spectrum with an RTLSDR stick and everything seemed in order. Still no data om TTN though, not even while driving from Lopik to Utrecht (passing the Gerbrandy tower and having a LOS most of the trip)…

Today I added a new ABP device in the TTN cnsole and uploaded the new keys to my Arduino… And everything started working again! Does anybody know what might have happened? Is this expected behaviour using APB and would this be solved using OTAA? Could the node have been rate limited without warning?

I am very happy everything is working again but I’m not sure how to prevent this in the future. Does anyone have a clue?

1 Like
2

Hi Johan,

Did you switch on Relax Frame Count in the settings of the device in the TTN Dashboard or reset the frame counter manually after switching on the device after repair?
Otherwise the packets are ignored for security reasons, because the counter will start from zero again.

Success,
Nico

3

Hi Nico,

I did. In fact, i did just before leaving the office and breaking the soldering joint. I also toggled the Relax frame count to see what would happen

I’m not sure what the ‘Relax frame count’ option does. I will read up on it :wink: (and stop touching settings without understanding them)

Thanks!

4

Just a little follow up. I need to RTFM more :slight_smile: I jumped in without understanding the framecount and without realizing my device would reset the framecount every power-cycle thereby making TTN drop the first X frames. I reset the framecount in the TTN console almost every time I started a measurement so it sort of worked, and sometimes I missed a bunch of frames without understanding why.

I understand now, thanks again for the help!

5

As flipping the switch on the ‘relax frame counter’ imposes replay attacks and thus degrades security you could also use OTAA instead of ABD. When using OTAA, with each join (as I understood it correctly) the frame counter gets reset.
So you’ll keep your security up and won’t get troubles when de-powering your device.

6

Yeah, OTAA is the best way to go here. Storing the framecount between reboots could be an option but I guess that would mean a manual reset every 2^16 frames. I moved to OTAA last week and it looks promising. Sometimes the joining is a bit slow, and sometimes something goes wrong and it needs to rejoin (need to figure that out). But all in all, it works!

7

To find the (insecure) “Reset Frame Counters” option (previously known as “Relax Frame Count” and later on “frame counter checks”):

Console V3

For V3, at least for LoRaWAN 1.0.x ABP devices, “Reset Frame Counters” is in Network layer, Advanced MAC Settings (just below the ABP NwkSKey):

Reset Frame Counters
Reset Frame Counters1154×1272 90.9 KB

Don’t ignore the warning:

Warning

:warning: Resetting is insecure and makes your device susceptible for replay attacks

It seems that in V3 the V2 “Reset Frame Counters” link no longer exists, and the TTN downlink counter is reset automatically if needed.

Console V2

Just here for posterity and the links to help you solve problems.

  • First, read this full post, and its warnings below, and the warning TTN Console shows, so you understand what you’re doing!
  • Log in to the Console at https://console.thethingsnetwork.org
  • Go to your application
  • Click Devices, and find the specific device
  • Just to be sure†: write down the current values for “Frames up” and “Frames down”
  • Click Settings, and uncheck the checkbox:
    frame counter checks
  • In the command line interface, see the --disable-fcnt-check option.

:warning: Disabling frame counter checks drastically reduces security and should only be used for development purposes.

:warning: This only affects the counters on the server side, hence only affects the uplink frame counter; if you ever reset the counters in TTN (see also the next warning) then you’ll need to implement something similar in your device for the downlink frame counter. (Note that downlinks include MAC commands, like used for ADR, and ACKs for confirmed uplinks.) For V3, see below.

:warning: Simply just changing this setting for an ABP device will reset the frame counters in TTN. (Due to a bug for ABP devices, even just changing its description will already reset the counters!) So, the downlink counter will be reset to zero when changing this setting.

Even when the frame counter checks have been disabled, a device will no longer work when it resets after already having used values larger than 16 bits (65,536 and up). In that case, TTN will not be able to validate the MIC. And as a DevAddr is not unique, TTN needs a valid MIC to find the device. (An uplink only holds the LSB 16 bits of the frame counter. For the MSB the server will try the last known value and the next value, to validate the MIC.) (TTN first checks the 16 bits counter, regardless any MSB it knows, so that’s a happy accident in case the device has been reset to zero.)

Also note the “reset frame counters” link next to the last known counter values in the Console. If you really know what you’re doing then you can use this to make the TTN backend set both the counters back to zero when needed, without the need to disable the frame counter checks. Beware that resetting the downlink counter requires your device to do the same, for otherwise the device will ignore any downlinks that use numbers that are lower than the downlink count it knows. (Just the opposite of how TTN will ignore low values for uplink counters.) Also, despite the incomplete warning, if the uplink counter already exceeded 16,384 then TTN will not accept any uplinks after resetting the counter without resetting the device as well. You might want to write down the last known values for both “Frames up” and “Frames down” before resetting anything.

Frame counters
Frame counters1120×264 48.1 KB

:warning: All the above is only about the counters. But a device may have lost much more state after a reset, such as network settings (including the channel mask as sent in the initial ADR Request for US915 and AU915, which is only sent once ever for ABP), ADR state, and pending confirmations. To ensure that TTN does not assume any state that the device has already lost, fully re-registering the device may be better.

† If you messed up, then there’s a small chance that ttnctl might help to make TTN use the true counters again.

3 Likes
8

@JohanAdriaans,

I was working with the same setup Arduino Pro mini, RFM95 and Ublox, but I couldn’t get it working. Could you share your sketch,

Regards,
Marco

9

Great topic, I’ve been working on it too and it seems to be working but I don’t get a valid GPS signal (number of satellites = 255…). I’ll share the code this evening. The node did work if I recall it right.

It would be great to build a few of those them as permanent ttnmapper nodes for members driving a lot.

10

Hi Marco,

Sure, the repo is a bit messy. It’s a work in progress :slight_smile: Here it is: https://github.com/Teumaat/ttn-tracker

PS: I use http://platformio.org/ instead of the arduino IDE so the project structure might not work in the ardiuno IDE.

1 Like
11

Hi Johan,

Great, thanks for sharing!
I’ve never heard about platformio or Atom but that looks fine…all day learning :grinning:

1 Like
12

That’s even faster! Thanks!

13

Well, I’ve been reading posts like this, this other one and the specification 1.0 (line 640) and I’m not sure about what frames are, are they like the physical LoRa packages?

And actually mustn’t I reset the frame conter for APB devices? because I’d say the behaviour in my case is the oposite one, I mean, apparently I’m not receiving data in the application side when I not reset it.

In fact, and due I’m still reserching my device remains usually shutdown, so … this causes that behaviour that I’m talking about and when I turn on the device I’m apparently not receiving data in the application side until I reset the frame counter (I’m not quite sure of this latter, though; it’s just my perception)

Could you clarify my how “dangerous” is to reset that frame counter when you are working with ABP devices? (according to the specification)

Thank you all.

14

I guess you mean LoRa packets. I’m sure other sources can explain better, but I’d say that in LoRaWAN the data part in each transmission is called the frame. So, each uplink and downlink holds such frame, and for each new transmission their frame counter needs to be incremented.

I think that’s exactly what is described in this topic? Just in case you did not read it, from the TTN documentation:

Frame Counters

Because we’re working with a radio protocol, anyone will be able to capture and store messages. It’s not possible to read these messages without the AppSKey, because they’re encrypted. Nor is it possible to tamper with them without the NwkSKey, because this will make the MIC check fail. It is however possible to re-transmit the messages. These so-called replay attacks can be detected and blocked using frame counters.

When a device is activated, these frame counters (FCntUp and FCntDown) are both set to 0. Every time the device transmits an uplink message, the FCntUp is incremented and every time the network sends a downlink message, the FCntDown is incremented. If either the device or the network receives a message with a frame counter that is lower than the last one, the message is ignored.

This security measure has consequences for development devices, which often are statically activated (ABP). When you do this, you should realize that these frame counters reset to 0 every time the device restarts (when you flash the firmware or when you unplug it). As a result, The Things Network will block all messages from the device until the FCntUp becomes higher than the previous FCntUp. Therefore, you should re-register your device in the backend every time you reset it.

As for just the counters, the last sentence can also be circumvented by resetting the counters in TTN Console. However, after a reset the device will probably have lost much more state (such as network settings, ADR state, pending confirmations, …), so re-registering ensures TTN and the device are fully in sync again.

Or to avoid any manual intervention, your ABP device needs to preserve its state between restarts. Or it should use OTAA for which after an OTAA Join both the device and TTN are in a known state. (And then the device should only do a new join a few times in its lifetime.)

2 Likes
15

Then, It isn’t dangerous but necessary? :thinking: I was confused by that paragraph starting at line 640 in the specification

Thank you @arjanvanb :wink:

16

Note that you’re linking to the 1.1 specification:

4.3.1.5 Frame counter (FCnt)

…

ABP devices have their Frame Counters initialized to 0 at fabrication. In ABP devices the frame counters MUST NEVER be reset during the device’s life time. If the end-device is susceptible of losing power during its life time (battery replacement for example), the frame counters SHALL persist during such event.

This is about the device, not about the network or TTN Console. And indeed it’s true.

Also, only resetting the counters in TTN Console just does not take into account any other state that TTN or the device might have, so: might be troublesome. Even more, only resetting the counters will likely not be supported in TTN V3, wrote @htdvisser on GitHub in November 2018:

I don’t think the v3 console should just copy the “reset frame counters” functionality in its current form. Instead it should have functionality to inform the network server about what’s actually going on: an ABP device device completely lost its state. This state is more than just frame counters, as the device also lost its MAC state and radio parameters.

However, the TTN Community network and many devices are at 1.0.2, which is not that explicit yet. Although it already states:

4.3.1.5 Frame counter (FCnt)

…

The end-device shall not reuse the same FCntUp value, except for retransmission, with the same application and network session keys.

…which has been emphasised in 1.1:

The end-device SHALL NEVER reuse the same FCntUp value with the same application or network session keys, except for retransmission of the same confirmed or unconfirmed frame.

No, it should not be necessary for a certified ABP device that properly persists its state. Resetting the counters has always only been a courtesy of TTN Console for development purposes.

Also, it is dangerous, as explained in the documentation I quoted earlier. Also, it’s is dangerous as resetting the counters in TTN Console also resets the downlink counter that TTN will use, implying that you should reset your device as well. So, randomly clicking it without even resetting your device might introduce problems with the downlinks. Finally, like described above, it only resets the counters, not any other state.

I’d say: go OTAA, and never disable the security checks, nor ever manually reset the counters.

2 Likes
17

well, for now I’m not doing downlink transmissions, so I guess that’s because is not being a problem for me resetting the counters, but of course in a future I’ll consider to go OTAA.

Thank you again @arjanvanb and sorry for getting up this old post.

18

Note that even if your application does not use downlinks, the network communication might still need them, like for confirmations and ADR, if enabled on the device.

That’s not a problem , I feel.

1 Like