Fair use policy and device blocking?

End Devices (Nodes)
1

Hi,
I’m currently testing 2 new nodes, a TTN mapping node based on a t-beam module, and a heltek AC01 capsule node. Both nodes initially managed to send data to their applications in the TTN cloud, but now I am getting very intermittent data, despite the messages arriving at my gateway, as shown in the local gateway logs, and the TTN gateway logs, as shown on the console. At this point I don’t really understand why this is happening.

I realised that both nodes were initially sending messages too fast for the fair use policy (> 30s total/day) so I have reduced the messaging rate to an acceptable level, in case the devices had been blocked. But as far as I understand TTN is not blocking devices yet. Has blocking been turned on? The messages are being sent at SF7, and are 18 bytes (mapping) and 62 bytes (capsule) long at 10 min intervals, so they should be below the FUP limits. The airtimes are 52 and 118ms.

I’m hoping to test the nodes against another gateway if possible (very few gateways here in Iceland), and I have tried creating another T-beam device with a new device ID, but the data from this also stopped after an initial test of a few mins. I am also monitoring the app messages via the MQTT server, which has also stopped showing any incoming messages from the 2 applications

When monitoring via the TTN console, I see all the messages coming in to the gateway traffic logs (I assume this is actually showing packets from my gateway arriving @TTN), but no messages in the application data logs. What needs to be correct for packets to be passed on to the applications, just the defined device IDs, or the app and network keys? These are unchanged, since the last successful data transmission.

I’ll keep trying rebooting my gateway and creating test nodes, but I would like to find out what I’m doing wrong…

2

Policy is not currntly enforced though you should plan for the fact it could be at any time & without notice…short term excesses (provided within local radio regs) are usually forgiven for testing purposes only.

Have you been resetting devices or self reset/restart and with fcount re-starting? try disabling fcount in app console for short period of test (not recommended for long term as potentially allowed relpay attacks). If fcount below what NS recognises as last (higher) value packets will quietly be dropped…fact you can at least see them in GW traffic page is a good start and you can investigate from there…

3

I’m not a TTN network operator, but I think TTN is not enforcing the fair use policy (yet).

Things that could go try:

  • Perhaps upload message sequence numbers are being reused (restarting at 0). Messages will be rejected unless you disabled this in the application settings. I think you should be able to see this even in the TTN console gateway view (FCNT)
  • In the TTN console gateway view you should see that it was able to find a “broker” for you messages. If it finds 0, the message is dropped. Do you see this?
4

Hi,
Thanks for the speedy replies. Good point on the fcount, I have been resetting (and programming…) the nodes, so the counter had been resetting frequently. I’ll try turning this off for the devices.

The broker seems to be ok, I’m seeing brokers:1 on the forwarding info

5

Looking good, I seem to be getting data flow again, still waiting for the next Tx from one of the nodes. Feeling a bit stupid I didn’t try this before…

I’d best do more reading on the frame counters. When this is active, are duplicate frames rejected for all time, or is there timeout? Surely at some point the counter must roll over…

Many thanks for the wise words.

6

If you use OTAA, frame counters will be reset to 0 upon join, and that is OK.
Otherwise frames with lower cnt than expected are rejected. This is a security feature to avoid replay attacks, as far as I know. I don’t know how roll-over works to be honest. If you use a 32-bit count, rollover is really unlikely though.

7

Ah… Another reason I really should move my nodes over to OTAA. I avoided this in the beginning when I had a very simple homebrew gateway. Now I have a ‘proper’ gateway, I have no excuse, and it is time I learnt a bit more about how this works.

For the rollover, just did a quick calculation. It should be more than 78 thousand years before I see a rollover on a 32 bit counter, so I won’t worry about this for a while :wink: