Node messages show in gateway console but not in application

[emacee]

Hi all,

This issue seems similar to earlier topics but in those topics no solution seems to be given.
The problem is that I’ve created a new application for a new node that I purchased (TTGO T-Beam).
The node connects through ABP and has worked this morning (when it was first installed).

The serial console of the node shows that the device sends it location:

The TTN gateway console shows the traffic that the node sends and receives it correctly:

The TTN application console shows the last status change 3 hours ago whereas the last message was transmitted only minutes ago.

I’ve checked the TTN status page but there doesn’t seem to be an issue regarding this at the moment.

Anyone able to point me in the direction to troubleshoot this issue?

[arjanvanb (Arjan)]

@emacee

This issue seems similar to earlier topics but in those topics no solution seems to be given.

I think it does:

@kersing

Check the keys are in the right byte order. If data goes missing between gateway (console view) and application that is 90% of the time the issue.
Counters not matching is the remainder

As things worked earlier, your keys should be okay. So you’ll have to look at the frame counter security.

(And for your first test you could temporarily disable that security.)

[emacee]

Hi Arjan,

Thanks for your swift reply, turns out I didn’t read the part about the counters before.
That solved my issue!

To make sure it doesn’t happen again I decided to recode my sketch to OTAA and now that seems to work! Thanks a lot, this topic can be closed.

[cslorabox]

@emacee

To make sure it doesn’t happen again I decided to recode my sketch to OTAA and now that seems to work!

Beware. OTAA doesn’t so much solve the problem as move or defer it.

In OTAA, the node has to use a unique “nonce” for each join, and a join which re-uses a previously used nonce will silently fail.

So actually, a compliant OTAA node has to keep track of which join nonces it has previously used.

Many implementations don’t do that and cheat, for example by taking a random number.

If their random number generator isn’t any good, they may take the same number they used the previous time. Worse, many only take a random number for the first attempt after booting, then then count forward from there. When that method is used, the node without random starting numbers will take longer and longer to register each time it is cold booted, as it has to count past all the previously used join nonces…

OTAA nodes are only supposed to register a few times in their entire service life (ideally just once).

But if your firmware doesn’t save session details in storage that persists across re-flashing, then if you are doing development work you’ll likely end up re-registering each time you re-flash even if you’ve only made the slightest firmware change.