TTIG disconnects after a few days

Hi,
I read a lot of posts regarding TTIG not connecting to TTN v3 but open a new one as I encounter some slightly different issue.
I use a lot of TTIG at different places and they work fine but I have a problem on 1 single site.
I first plugged TTIG EUI 58A0CBFFFE8019CF. It worked for a couple of weeks on TTN V3. 10 days ago, it appeared as “disconnected” and stopped relaying messages from my sensors. I checked the LED : it blinked green rapidly (every 1/4s). Once, I also saw it blinking alternatively green and red. If I unplug and replug it, after a reboot, the led blinks green rapidly (every 1/4s).
So, I plugged another TTIG in the same room (EUI 58A0CBFFFE8021F1). This one worked correctly for 7 days (while the first one still doesn’t connect) and then disconnected, just as the first one. It is connected to WiFi but doest not connect to the server.
Once disconnected, they never reconnect, whatever I do.
Any idea where this could come from?
Thanks,
Claire

Paging @KrishnaIyerEaswaran2 anything in the back end on these two EUI’s?

Both gateways are configured properly on the server side.

It is connected to WiFi but doest not connect to the server.

How did you ascertain this? Most connectivity issues wrt TTIGs are due to spotty WiFi.

Have you changed anything on your gateway wrt the API Keys or Rights on The Things Stack?

Hi, first all of, thank you both for your time.

Both TTIG are connected to the same WIFI, in the same room.

Last week, the first one, which had been connected to the TTN V3 server for 15 days appeared as “disconnected” (and the led blinked green rapidly). I tried to reboot the internet box and the TTIG without success (green led is still blinking rapidly). Thinking the problem could come from the TTIG, I decided to plug a second one (that I had been using for a long time without any issue). It connected immediatly. So I concluded that the WIFI was working well and that the problem probably came from the first TTIG. However, I let both TTIG plugged, just to see what would happen in the following days.
Well the second one disconnected from the server 7 days later… And as the first one, it would never reconnect. So my conclusion is that it neither comes from the TTIG itself, nor from the WIFI connection.

Don’t get me wrong, I don’t say the problem comes from the server (I imagine it could come from the internet box as it is very specific to this site) but what can I do to diagnose the origin of it and find a turnaround?

Try to tether to a mobile phone connection or a 3G/4G Dongle/MiFi type device to see if it connects then if possible leave running for several days to see if issue rearises… I have several sites running with such arrangements for >12_18 months without issue

If stable you know it is local WiFi or backhaul problem…

Thanks Jeff I’ll try this, although this site is located in a rural area, with very very bad GSM coverage (yes, it still exists… :wink:

Hi @KrishnaIyerEaswaran2 , @Jeff-UK,

As suspected, the GSM coverage is too poor to use a 2G/4G router.

However, I might have some explanations regarding the fact that the TTIGs work properly for a couple of weeks and then disconnect from the server, without any chance to reconnect after that.

I noted that if I take the TTIGs, connect them on another internet box (on a different site), they immediately reconnect to the server. If I bring them back to the problematic site, they work again, but only for a couple of weeks. I suspect that the TTIGs are working fine only for a limited time period, until the next CUPS query is performed and blocked by the internet box.

To confirm this hypothesis, can you tell me on which frequency the CUPS query occurs?

I was told that the CUPS protocole is https and uses port 443. Is that correct? Could the Orange Livebox block these exchanges but not the LNS protocol (WSS)?

I specify that there is no Proxy nor Firewall on the WIFI connection (although there are ones on the LAN connection).

TTIGs contact the CUPS server every 24 hours (or when restarted).

CUPS uses 443 while LNS uses 8887.

Thanks @KrishnaIyerEaswaran2
Can you see in the backend if these 2 gateways contact the CUPS server on a daily basis?
Could the problem come from a failing authentification procedure with the CUPS server ? What is the expiration delay of related credentials ?

Hi,

I’ve investigated further. I’m more and more convinced that the problem comes from the connection to the CUPS server. According to the console, one of the gateway has the “cups - last - seen” date set to 2021-09-30 when all my other ttigs have the current date displayed here. However, this gateway IS currenlty connected to the LNS server and correctly relays messages.

So I really think the problem comes from the expiration of the CUPS credentials that cannot be renewed for some reason.

Does somebody know the delay before authentication credential expiration? Wouldn’t it be around 15 days?

Furthermore, what could prevent my ttig to connect to the CUPS server when it connects correctly to the LNS server?

Has someone ever experienced an orange livebox blocking the 443 port for in or out communication?

Please help :wink:

image