Console Fatal error after some minutes of inactivity

Hi guys
I´m getting this error message in the console after some minutes of inactivity


This happens in this links (for example)

Pressing F5 (refresh) in the browser recover the connection.

What can be wrong?

Thanks in advance.

Two and a half years later and the problem still appears to exist. Anyone have info?

1 Like

It’s part of the joy of websites - cookies, links to backend authorisation mechanisms, XHR, JSON, CSRF and so on.

TTI are working on v3, so this is deeply unlikely to be fixed in v2.

I have had this happen three days in a row now and am rapidly losing faith in the reliability of the TTN system. Yesterday it occurred again after two hours of connection.

When this occurs I am unable to reconnect my end device and have developed these steps to restore my working connection.

Firstly I set up a console browser looking at my gateway traffic. This confirms that end node is alive and transmitting a packet with a single byte payload ever few minutes.

Then I set up another console browser looking at the device data. And I see no traffic.

I then confirm this using my MQTT.fx client that is logged onto my TTN Application and is subscribing to the MQTT Topic.

So I have confirmed that the end node is transmitting valid packets and that those packets are arriving at my gateway but are not being passed on to the TTN Device and TTN Application, so never get to my MQTT.fx client either.

The only way I have found to restore the system is to change the device completely. To do this I delete the existing device and create a new one. Then I copy the new Device Address, Network Session Key and Application Session Key to my Arduino sketch. After recompiling, the device connects and the data flows again.

Till the next time.

Please note that there is no HTTP involved in this other than in the console browsers which are in fact only monitoring proceedings and not participating in them. The connection between the TTN Application and my MQTT.fx client is via TCP but is not using HTTP at all. Even if this connection failed it would not crash the link between my gateway and my TTN Application.

It is all working right now and time will tel how long it continues.

Whilst I sympathise with the frustration, most of what you do has nothing at all to the console fatal error which is entirely about the information the browser has about its login expiring and both ends not quite managing to sync up.

If I’ve got anywhere between one or 10+ TTN console windows open doing tests and monitoring, over the space of the day, at least one of the windows will end up with a fatal error, sometimes more. My main development platform is macOS on which I run Safari & Chrome but I also have a Windows 7 PC to hand on which I run Chrome. Any or all of them can end up with the fatal error.

The vast majority of the time I simply refresh the browser page. If that hiccups, I close the tab and reopen a new tab.

At no point have I seen this issue affect the TTN back end that results in the network server having incorrect data which is what would be needed to prevent it being accepted in to the TTN system from your gateway and then on to your application.

I’ve no doubt something is going on, but given the chain of code that would have to go horribly wrong between a browser console session and the authentication & decryption on the network server to stop packets uploading from your gateway, I suspect you are the victim of a set of co-incidental circumstances.

Can you start a new thread and we can pick from there.

1 Like

Sounds like an ABP frame counter issue. Next time this happens could you go to the device overview and hit the reset frame counters link next to to Frames up?

1 Like

Same issue recurred today after about an hour and 20 odd messages. As suggested I hit the ‘reset frame counter’ link and also refreshed my failed console pages and voilla! the messages flow again.

Can you please enlighten me as to what this means or what I should do in order to counter it happening in the future.

Next time it happens, after reset of the browser session and when new data arrives please look at the counter value listed in the device page and tell us the value(s) listed there.

1 Like

A simple problem then. Please learn about Frame Counters, they are important when testing devices: