Solved the issue
**
Issue:**
After updating/running GL-MT6000 on firmware 4.9.1, devices were failing to connect properly to Wi-Fi. The SSID was visible, but clients were not getting a valid DHCP lease.
Relevant log errors:
dnsmasq: failed to bind DHCP server socket: Address in use
dnsmasq: FAILED to start up
I also saw repeated Wi-Fi interface/path messages like:
del path: ra0(DN)->apcli0(UP), active path:0
add new: ra0(UP)->apcli0(UP), active path:1
Root cause found:
The router had multiple dnsmasq instances running for WireGuard client interfaces:
ps w | grep '[d]nsmasq'
Output showed wgclient1 and wgclient2 dnsmasq instances. Checking DHCP port usage confirmed that the WireGuard client dnsmasq processes were binding to UDP port 67 globally:
netstat -lunp | grep ':67'
Problem output looked like:
udp 0 0 0.0.0.0:67 0.0.0.0:* 28443/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:* 28442/dnsmasq
Because those VPN-related dnsmasq instances were already holding DHCP port 67, the normal LAN DHCP server could not start. That caused clients to fail when connecting because they could not receive DHCP leases.
Fix:
I set the WireGuard client dnsmasq instances to use nonwildcard=1, then restarted dnsmasq cleanly:
uci set dhcp.wgclient1.nonwildcard='1'
uci set dhcp.wgclient2.nonwildcard='1'
uci commit dhcp
/etc/init.d/dnsmasq stop
killall dnsmasq
rm -f /var/run/dnsmasq/*.pid
sleep 2
/etc/init.d/dnsmasq start
Then I verified DHCP port 67:
netstat -lunp | grep ':67'
After the fix, only one normal dnsmasq process was listening on DHCP:
udp 0 0 0.0.0.0:67 0.0.0.0:* 9701/dnsmasq
Devices immediately started connecting again and receiving DHCP leases.
Summary:
The issue was not the client devices. On GL-MT6000 firmware 4.9.1, the WireGuard client dnsmasq instances were binding to DHCP port 67 on 0.0.0.0, preventing the main LAN DHCP server from starting. Setting nonwildcard='1' on the wgclient1 and wgclient2 dnsmasq sections fixed the conflict.
