Router drops clients every 30 minutes like clockwork

I’m still having the same issue, I think at the same hotel chain (I forget) and was hoping by now with different hardware and more software updates, things would be different.

I had this post last year sometime: GL-XE3000 dropping connections constantly - #11 by mike503

It looks like every 30 minutes like clockwork I get disconnected on all my downstream devices (one of which is a GL-RM10 KVM!) for 5-10 seconds before things recover. I am sure it’s a DHCP renew situation. I do not know though why other devices don’t have issues, I believe it’s because “routers are supposed to behave differently” but in this case I am repeating the hotel wifi so I can use my Mudi 7 (GL-E5800) as the central connection point. It’s set as a wifi repeater only (cellular is disabled) so there’s nothing it should be doing trying different WAN options.

this is driving me crazy as i’ll be in the middle of a call and get kicked off. it doesn’t seem like the whole connection table needs to be reset, or whatever the device seems to be doing.

actually it looks like this person back in 2021 had the same issue reported (maybe more, it just came up on the forum search box) - Router Drops All 2.4GHZ Connections At 28 Minutes Past Every Hour - #8 by alzhao and alzhao i think is who replied to mine last time with the same thing - DHCP renew causing wifi restart. there’s got to be something that can be done to be graceful about this. like DHCP renew (or issue a conditional "i want to maintain my existing lease”) or some sort of “has my IP or anything changed? if not, don’t restart everything” kind of thing…

i’m happy to send logs via private message. i got a big log dump from the last cycle!

I threw this into claude for inspection since it was a lot and it does sound like the same kind of thing as last time. is there no way to make it handle things more gracefully rather than tearing everything down?

Now let me parse the log carefully. I can see the issue pretty clearly:

What's happening (in timeline order):

  1. 20:20:01 — Device disconnects from MGMResorts-WiFi AP 24:d7:9c:82:d5:c5 with reason code 252 ("Unknown vendor")

  2. 20:20:06–20:20:07 — GL.iNet stops wpa_supplicant on wlan3, clears config, and tears down the interface completely

  3. 20:20:07–20:20:14 — GL.iNet rescans, finds the same AP at 70:bd:96:9c:57:e5 (different MAC—likely the same physical AP, different radio/band), and reconnects successfully

  4. 20:20:14+ — Interface stays up, backhaul is restored, life is good

The core issue:

You're right about DHCP, but it's subtler. The log shows:

  • wwan interface (your WiFi backhaul) gets an IP: 10.15.36.242

  • The disconnect reason is code 252, which in Qualcomm drivers means a vendor-specific deauth/disassoc—often a regulatory/channel conflict or the AP forcibly booting the client

The GL.iNet router's response is aggressive: instead of just letting the WiFi interface recover (which most consumer routers do), it tears down the entire interface stack:

wpa_supplicant_teardown_vif(wlan3)
wpa-supplicant-qcacld: stop wlan3
wpa-supplicant-qcacld: delete wpa_supplicant.wlan3
vdev 2 destroyed successfully

Then it rebuilds from scratch. This causes a ~6–13 second blip (visible in the timestamps: 20:20:01 to 20:20:13).

Key observations from the log:

  1. Regulatory/channel safety events (20:20:07 area):
   extract_reg_ch_avoid_event_tlv: range 0 tlv id 4718600, start freq 5560, end freq 5745
   extract_reg_ch_avoid_event_tlv: range 1 tlv id 4718600, start freq 5945, end freq 6005

The router detected unsafe channels (possibly due to radar interference or regulatory changes). This might trigger the AP to move bands, and the client loses sync.

  1. MLO (Multi-Link Operation) errors everywhere:
   mlo_mgr_link_switch_defer_disconnect_req: Link switch not in progress
   mlo_sta_get_vdev_list: Invalid input
   mlo_dev_ctx object is NULL for vdev 2

The router's WiFi stack is in a confused state about multi-link connections (this is a 6GHz/WiFi 6E thing). It's not fatal, but it suggests the driver isn't fully handling the backhaul correctly.

  1. IPA (Internet Packet Accelerator) errors:
   __wlan_ipa_w2i_cb: Invalid iface_id 6,session_id 2 0 0 0
   wlan_ipa_setup_iface: net:... MAC:70:bd:96:**:**:e5 id:2

The router is mishandling offload config during reconnection.

Hi,

Thank you for providing the detailed information and the analysis you provided.

Based on the timeline you shared, the upstream Wi-Fi connection appears to disconnect first, after which the Mudi 7 rebuilds the repeater connection and reconnects.
Since this reportedly happens approximately every 30 minutes, could you please help us check the following?

  1. Could you please provide the current firmware version of your Mudi 7.
  2. If possible, please connect the Mudi 7 to another Wi-Fi network, such as a mobile hotspot, and check whether the same disconnection occurs.
  3. Please try enabling Lock BSSID for the current repeater connection and check whether the issue still occurs.
  4. When the issue occurs again, could you please export the system log and send it to us via private message.

Thank you for your cooperation.

thanks for the reply. here’s some more details:

  • router broadcasts DFS
  • should i try changing the different bands? right now it's "allow switching to other saved networks" and band selection is "auto"
  • i tried to lock BSSID but it kept failing, and i have to work and can’t be offline for long periods of time :slight_smile:
  • OpenWrt 23.05.4 r24012-d8dd03c46f, GL.iNet GL-E5800, i was on 4.0 0804release, i’m upgrading now to 4.0 0805release.

Hi,

Thank you for the update.

When the Mudi 7 connects to an upstream 5 GHz Wi-Fi network through Repeater, its 5 GHz Wi-Fi may follow the upstream network and use the same DFS channel.

After upgrading to the 0805release firmware, does the periodic disconnection still occur?

If the issue persists, please change the Wi-Fi Band setting for the 5 GHz/6 GHz network from Auto to a single band, such as 5 GHz or 6GHz only, and check whether the disconnection still occurs.

If the issue persists, could you please export the latest system log and send it to us via private message?


Thank you for your understanding and cooperation.

i sent you a message with a zipfile since the logfile was so big. thanks. i thought it was stable but it’s doing the same thing still. :stuck_out_tongue:

1 Like

I have the same issue with a GL-MT6000 latest firmware. I thought it was the ISP so I changed ISP’s/ Still the same issue.

Found in my case, even though the GUI said the MAC was going to be randomized every 7 days. In Lucie, the cron job was set to 30 minutes:
”*/30 * * * * /usr/sbin/gl-update-cable-mac.sh time”
I changed it to seven days.

Hi,

This is a known issue related to periodic MAC randomization, and we have reported it to the relevant team for further analysis.
At present, we recommend changing the WAN MAC mode to Factory or disabling Auto Update MAC to avoid scheduled MAC changes causing repeated WAN reconnections.

We apologize for the inconvenience and appreciate your understanding and support.