GL-XE3000 dropping connections constantly

mike503 · October 25, 2025, 9:42am

I finally think I’ve narrowed down what is interrupting my connections.

I have a GL-XE3000 setup as a repeater. I don’t see any issues with the upstream.

I have a laptop, wired to the LAN port (192.168.5.138)

I have another laptop, wifi connected on 2.4ghz, right next to the router (192.168.5.202)

My connections (RDP most noticably) drops out often. It comes back within a few seconds.

I setup a ping every second to the other machine, the router and google public DNS - and I am seeing pings fail around the same time as the RDPs fail if I am actively on the system.

It seems to happen around the time the firewall reload happens. It doesn’t happen every time, but every time it happens I’m able to see that it just happened to reload the firewall.

Each one of these was when a hiccup occured. Common theme is the firewall reload. There’s even more examples of this, there’s not actually a lot of log output that shows up around this time.

example 1:

Fri Oct 24 18:35:24 2025 daemon.info glc: (common.c:1741) Parse +COPS response success
Fri Oct 24 18:35:50 2025 kern.err kernel: [965815.860925] 7981@C13L1,tx_free_v3_notify_handler() 3530: ContTxFailCntTotal = 1, ContTxFailCnt300ms = 1
Fri Oct 24 18:35:50 2025 kern.err kernel: [965815.870408] 7981@C13L1,tx_free_v3_notify_handler() 3533: token used by current wcid = 59, free_token_cnt = 2303
Fri Oct 24 18:35:55 2025 daemon.info glc: (common.c:1741) Parse +COPS response success
Fri Oct 24 18:36:00 2025 kern.err kernel: [965826.151157] 7981@C13L1,tx_free_v3_notify_handler() 3530: ContTxFailCntTotal = 2, ContTxFailCnt300ms = 1
Fri Oct 24 18:36:00 2025 kern.err kernel: [965826.160671] 7981@C13L1,tx_free_v3_notify_handler() 3533: token used by current wcid = 59, free_token_cnt = 2303
Fri Oct 24 18:36:11 2025 kern.err kernel: [965836.352965] 7981@C13L1,tx_free_v3_notify_handler() 3530: ContTxFailCntTotal = 3, ContTxFailCnt300ms = 1
Fri Oct 24 18:36:11 2025 kern.err kernel: [965836.362453] 7981@C13L1,tx_free_v3_notify_handler() 3533: token used by current wcid = 59, free_token_cnt = 2303
Fri Oct 24 18:36:26 2025 daemon.info glc: (common.c:1741) Parse +COPS response success
Fri Oct 24 18:36:57 2025 daemon.info glc: (common.c:1741) Parse +COPS response success
Fri Oct 24 18:37:12 2025 user.notice kmwan: config json str={ "op": 6, "data": { } }
Fri Oct 24 18:37:13 2025 user.notice firewall: Reloading firewall due to ifupdate of wwan (apclix0)

example 2:

Sat Oct 25 02:01:13 2025 user.notice firewall: Reloading firewall due to ifupdate of wwan (apclix0)
Sat Oct 25 02:16:51 2025 kern.err kernel: [993470.202935] 7981@C13L1,tx_free_v3_notify_handler() 3530: ContTxFailCntTotal = 1, ContTxFailCnt300ms = 1
Sat Oct 25 02:16:51 2025 kern.err kernel: [993470.212429] 7981@C13L1,tx_free_v3_notify_handler() 3533: token used by current wcid = 62, free_token_cnt = 2302

example 3:

Fri Oct 24 18:53:09 2025 user.notice kmwan: config json str={ "op": 6, "data": { } }
Fri Oct 24 18:53:09 2025 user.notice firewall: Reloading firewall due to ifupdate of wwan (apclix0)

example 4:

Fri Oct 24 23:18:41 2025 user.notice kmwan: config json str={ "op": 6, "data": { } }
Fri Oct 24 23:18:41 2025 user.notice firewall: Reloading firewall due to ifupdate of wwan (apclix0)

I’m on latest stable firmware (4.0 0802release5)

Note - those ContTxFailCntTotal messages don’t seem to be related - when a hiccup happens, those are not always there. The reloading firewall though is. Also… I don’t know why ifupdate of wwan keeps happening. The cellular connection is disabled, it should not be trying to connect to anything. The repeater is the only thing setup.

will.qiu · October 27, 2025, 4:07am

Hi

Based on the current logs, it appears to be caused by the interface status update of the Wi-Fi repeater.

Could you PM us the full logs for further investigation?

Additionally, you can first:

Check the DHCP lease time on the main router and try adjusting it to a larger value to see if it helps.
Since you're using the 2.4GHz band, also check if any USB 3.0 devices are connected to the XE3000 or if there are other sources of interference present.
If possible, please try using the 5Ghz to see if any improve.

mike503 · October 27, 2025, 6:39am

sending logs to you now in PM - it’s a decent long snippet and just happened to “blip” again on me

no USB devices

i don’t control DHCP upstream it’s a hotel’s wifi i am repeating

i’ll see what i can do (if anything) about forcing 2.4 vs 5ghz from the upstream

mike503 · October 27, 2025, 6:49am

11:44 PM 10/26/2025
changed settings:
Allow Switching to Other Networks Mode: No Switching
Band Selection: 5ghz

will.qiu · October 27, 2025, 8:57am

After checking the logs, it appears that your upstream Wi-Fi assigns a very short DHCP lease—around 30 minutes.

This causes the router to renew its IP frequently (roughly every 15 minutes), which can result in intermittent interruptions during that period.

If possible, please try to configure a static IP address on your device to bypass these frequent DHCP renewals.
Repeater - GL.iNet Router Docs 4

If that cannot work on your hotel’s Wi-Fi, there may be no other solution, as we cannot access the it.

mike503 · October 30, 2025, 11:46pm

thanks for that. i’ve switched over to cellular and it does seem more reliable for sure (i do see a few lost pings sometimes but nothing regular/predictable)

i do question about this firewall reloading. i thought my other hotel was more stable but it apparently is doing the same thing i think, where DHCP leases are shorter. i tried to force a manual static on it, but it didn’t like that.

there’s gotta be a way to not reload the firewall unless it truly needs it, it seems that the reloading firewall task flushes all connections and resets them. other devices (phone, laptop, etc) connected to the same wifi may have these same short DHCP leases, i mean, all it should do is renew the lease transparently… no?

will.qiu · October 31, 2025, 6:53am

Thank you for updating the logs. As you mentioned, this situation does appear to be a repeater disconnection.
However, it seems somewhat different from the earlier incidents, since previous logs did not include any repeater disconnection related entries — only DHCP lease renewals were recorded.

Regarding this repeater disconnection, did you retain the complete logs?
The logs you’ve shared so far begin exactly at the disconnection message, so we’re unable to review what happened beforehand to determine the root cause.

Unlike endpoint devices (phones, laptops, etc.), routers need to perform additional operations during an upstream DHCP lease renewal.
These include resetting existing connections, updating firewall rules, and reconfiguring default routes to properly handle NAT and routing.
As a result, compared with endpoint devices, users may notice more obvious network interruptions during this process.

mike503 · October 31, 2025, 9:10am

I can send more logs than what I did, although I’m worried it winds up being too noisy, and it may get confusing when I am switching networks on purpose, for example. this is just the output from logread -f… there’s no way to tell the router to be “dumber” and not do all kinds of extra stuff? in my mind, if doing NAT, it’s all inside of the router to manage, shouldn’t matter what the upstream is. it feels like I’ve had other devices over the years with internet WAN or other upstreams that didn’t reset all connections even to itself when the upstream changes.

the last log I sent with the disconnection really did have nothing (at least, nothing in logread -f) before that disconnection. I sent the couple preceeding lines which were a long time before the disconnect happened, there simply was nothing.

posting it publicly for others’ benefit (changed name and MAC of the hotel wifi)

Thu Oct 30 18:09:31 2025 kern.err kernel: [1482509.240627] 7981@C13L1,tx_free_v3_notify_handler() 3530: ContTxFailCntTotal = 1, ContTxFailCnt300ms = 1
Thu Oct 30 18:09:31 2025 kern.err kernel: [1482509.250198] 7981@C13L1,tx_free_v3_notify_handler() 3533: token used by current wcid = 1, free_token_cnt = 2303
Thu Oct 30 18:12:17 2025 daemon.notice netifd: wwan (27236): udhcpc: sending renew to 10.0.1.133
Thu Oct 30 18:12:18 2025 daemon.err gl-repeater[3366]: (repeater.lua:524) disconnected from Hotel-WiFi 34:a7:dc:12:c8:a5
Thu Oct 30 18:12:18 2025 daemon.notice netifd: Network device 'apcli0' link is down
Thu Oct 30 18:12:18 2025 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Thu Oct 30 18:12:18 2025 kern.notice kernel: [1482675.355048] 7981@C09L3,sta_cntl_disassoc_conf() 1850: CNTL - Dis-associate successful
Thu Oct 30 18:12:18 2025 daemon.notice netifd: wwan (27236): udhcpc: received SIGTERM
Thu Oct 30 18:12:18 2025 daemon.notice netifd: wwan (27236): udhcpc: unicasting a release of 10.15.34.108 to 10.0.1.133
Thu Oct 30 18:12:18 2025 daemon.notice netifd: wwan (27236): udhcpc: sending release
Thu Oct 30 18:12:18 2025 daemon.notice netifd: wwan (27236): udhcpc: entering released state
Thu Oct 30 18:12:18 2025 daemon.notice netifd: wwan (27236): Command failed: Permission denied
Thu Oct 30 18:12:18 2025 kern.debug kernel: [1482675.424272] del link apcli0
Thu Oct 30 18:12:18 2025 kern.debug kernel: [1482675.427302] nf_unregister_hooks()
Thu Oct 30 18:12:18 2025 kern.debug kernel: [1482675.431027] del path: ra0(UP)->apcli0(DN), active path:1

also this is when the DHCP renewal seems to force a disconnection, there wasn’t anything before it. seems like the router decided it was time to renew. even though the lease time is 3600 seconds it seems like it’s doing it every 30 minutes (1800)

Thu Oct 30 18:42:19 2025 daemon.notice netifd: wwan (2815): udhcpc: sending renew to 10.0.1.133
Thu Oct 30 18:42:20 2025 daemon.notice netifd: Network device 'apcli0' link is down
Thu Oct 30 18:42:20 2025 daemon.notice netifd: Interface 'wwan' has link connectivity loss
Thu Oct 30 18:42:20 2025 daemon.err gl-repeater[3366]: (repeater.lua:524) disconnected from Hotel-WiFi 34:a7:dc:12:c8:a5

sends DHCP renew every 30 minutes and gets disconnected quick.
then comes back, same information every time.

Thu Oct 30 18:42:21 2025 daemon.notice netifd: wwan (10712): udhcpc: lease of 10.15.34.108 obtained, lease time 3600

lease time is an hour though

seems like it’s consistently happening when the router decides to send a renewal to the DHCP server it starts the whole disconnect process.

will.qiu · October 31, 2025, 9:24am

Please let us know the firmware version of your XE3000.
We will test here to see if DHCP renew causes the wireless connection to disconnect.

mike503:

also this is when the DHCP renewal seems to force a disconnection, there wasn’t anything before it. seems like the router decided it was time to renew. even though the lease time is 3600 seconds it seems like it’s doing it every 30 minutes (1800)

A DHCP client (router) sends a lease renewal request when 50% of the lease time has passed.
This is specified by the RFC standard, so it is normal.

Refer: How a DHCP Client Renews Its IP Address Lease
or RFC 2131 - Dynamic Host Configuration Protocol

mike503 · October 31, 2025, 10:04am

Cool to know about RFC I’ve never had to dive this deep into things to care

I’m on latest stable firmware (4.0 0802release5)

will.qiu · October 31, 2025, 10:28am

After a quick test, DHCP renewals did not cause the interface to disconnect, and we could not reproduce the issue.

Given that DHCP renewals did not trigger disconnections in your previous logs as well, it is likely that this issue is specific to this hotel's Wi-Fi network.

Is there an opportunity to test whether the wired connection has the same issue?