HomeAssistant destroys Internet connection of LTE router?

Hey guys,
I have a strange situation here (at least for me).
I have a HomeAssistant connected via Ethernet to a switch which is connected (with other devices (several Shellys)) to a 4G/LTE router (simple TP-Link). Everything works fine uuuuntil: I try to install an update (no matter remote (Nabucasa) or local). Process starts as expected and at some point the router loses Internet connection (local Wifi and local network still works). I tried this a couple of times and already spent a couple of GB of Mobile data because it seems the download takes place (each time). However, the update is finally not installed. Same for Operating system and Core update.

Logging onto the router it shows “searching for internet” for 5-10mins. But again - this ONLY happens when running an update.

Just now I tried to install RClone Add on (from remote) and it seems the same thing happened (still hoping HA is back online in 5-10 mins).

Any ideas? As long as I do not run any update (or install something?) everything works just fine.

Hello schwan88,

Are you using PiHole or AdGuard or another DNS redirector software?

1 Like

no, until now very basic installation.
Using a HA “green” by the way.

HA is online again after ~10 or 15 mins.
I tried to reinstall RClone and now I´m getting this message:

" Add-on konnte nicht installiert werden

Can’t install ghcr. io / jcwillox/hassio-rclone-backup/aarch64:3.3.4: 500 Server Error for http+docker://localhost/v1.51/images/create?tag=3.3.4&from Image =ghcr. io%2Fjcwillox%2Fhassio-rclone-backup%2Faarch64&platform=linux%2Farm64: Internal Server Error (“Get “https:// ghcr. io/v2/”: net/http: request canceled (Client.Timeout exceeded while awaiting headers)”)"

But I´m not sure if it is 1 or 2 different issues (update and add on installation)

Any further ideas?

Ask your ISP why your router is losing connection. That’s your problem. It’s disrupting your download. And the add-on is similarly failing to download. It’s interesting it failed at the HTTP layer and not TCP but it could just be a misleading error message. Maybe there’s some kind of HTTP proxy that’s blackholing the traffic like @Sir_Goodenough implied.