Repeater gets disabled

I'm facing an issue with a GL-SFT1200 (Opal) used as a repeater for a Wi-Fi Network at a campsite, where the repeater function stops working after a while without a clear pattern or trigger.

I'm new in this forum but I've seen already a few posts reporting this exact same problem, although I couldn't find any viable solutions yet.
I post this here to add details about my own setup, hoping this could help to identify possible triggers, solutions or.. workarounds.

The Opal I'm using is currently running version v4.3.18, although I've seen this same issue with previous 4.x versions too (I don't have the exact list, but I have no "working" version to report either):

  • everything has been configured exclusively using the GL-iNet UI (I use LuCi only for monitoring)
  • The repeater is the only available upstream connection and it uses a WPA2-PSK SSID from the campsite: there are multiple APs deployed at the campsite; roaming seems to happen quite often, as in LuCi I can see that the best RSSI I'm getting in 2.4 is around -73 and the BSSID changes quite often; I'm not sure if the frequent roaming could be related to the issue I'm facing.. I haven't selected the BSSID lock as I noticed that the BSSID with the best signal is not always the same
  • I forced the band to be 2.4 GHz on 20 MHz using the GL-iNet UI:
    image
  • I have a private SSID, also WPA2-PSK on both 2.4 and 5 GHz, as well as a guest SSID, also active on both bands
  • I have configured a Wireguard VPN to my home router, only accessible from the private SSID (I mention Wireguard here as I read another post here where Wireguard was used, although it was configured via LuCI; in my case, the Wireguard VPN was also configured via the GL-iNet UI)
  • I have no other plug-ins/packages installed, this is just the basic firmware + the config described above

Based on what I read on other posts, and in order to try to mitigate the issue, I did the following:

  • disabled the interface status tracking for the repeater; this seems to have mitigated the problem (it still happens, but it seems like since I disabled this check, it hangs once or twice a day, instead of every other hour..):

  • I configured a scheduled reboot every morning at 5 AM ... but this seems to have no effect, so I'll probably disable this:

So far, I suspect that the upstream network instability may trigger the repeater function to stop working at some point, but I wonder if there could be any solution (e.g., a config to force it to retry connecting irrespective of failures), or workarounds (any script detecting the repeater being disabled and restarting it?!..).

Thanks in advance for any suggestions!

When it has disconnection (disabled) can you export and send the system log?

I could collect the system and kernel logs today after I realized the problem reoccurred, but I can't see myself anything "interesting"... perhaps the problem started before the time frame covered in the logs.

I'm attaching the logs I could collect today here anyway... the only change I applied was to redact the Wireguard VPN server hostname, the rest is the exported log from the GL-iNet UI.

20240816_opal_logs_01.zip (8.6 KB)

What would be the best way to persist logs for a long time?
Any ways to periodically export them to an external storage, for instance an USB stick?

Thanks for your help!

Could it be that the campsite has a low DHCP lease time and you are not active on your router at certain times so you get disconnected? Im just wondering if it's a setting on the campsite that treats idle clients as expired so they have enough leases.

If my thought process has any substance then maybe you could run a script to constantly ping a domain to keep your connection live and then see If you get disconnected. Again, it's just a thought and I'm not even sure if my logic is plausible.

I managed to trigger this issue last night in router mode, SFT1200 on latest firmware, PPPoE FTTP connection, SFT1200 went to blinking white light after streaming video over 5ghz AC WiFi.

The log only contains wireguard disconnect. So hard to tell what happend.

I am not sure if it is the same issue. But can you send log when this happends?