[BUG] GL-E5800 Mudi 7 — LAN DHCP DNS setting is lost after reboot

[BUG] GL-E5800 Mudi 7 — LAN DHCP DNS setting is lost after reboot

Summary

On a GL.iNet Mudi 7 (GL-E5800), a custom DNS server entered in the LAN DHCP settings is saved and active before reboot. After reboot, DHCP option 6 is absent from the persistent configuration and the DNS field in the GL.iNet interface is empty.

The user reports that the behavior is reproducible. This investigation captured one complete before-and-after reboot transition.

Environment

Item Value
Device GL.iNet Mudi 7 / GL-E5800
GL.iNet firmware 4.8.5
OpenWrt 23.05.4 r24012-d8dd03c46f
Kernel 5.15.170-perf
Internet connection Cellular
VPN WireGuard
LAN 10.100.1.0/24
Configured DHCP DNS server 10.10.70.100

The DNS server is on a private network reachable through WireGuard. This is the setup in which the problem was observed; it has not been established as the cause.

Steps to reproduce

  1. Connect the router to the Internet through its cellular connection.

  2. Enable the WireGuard client that provides access to 10.10.70.100.

  3. In the GL.iNet LAN DHCP advanced settings, enter 10.10.70.100 as the first DNS server and apply the configuration.

  4. Confirm that uci show dhcp.lan contains:


dhcp.lan.dhcp_option='3,10.100.1.1' '6,10.10.70.100'

  1. Confirm that uci changes dhcp returns no output.

  2. Reboot the router normally.

  3. Inspect the LAN DHCP DNS field and run uci show dhcp.lan and uci changes dhcp after boot.

Expected result

The committed LAN DHCP DNS server remains configured after reboot.

Actual result

After reboot, DHCP option 6 is absent and the DNS field in the GL.iNet interface is empty. uci changes dhcp returns no output, showing that the post-reboot state is persistent rather than an uncommitted change.

The GL.iNet LAN RPC returns an empty DNS list, and the generated dnsmasq configurations do not contain option 6.

Captured before-and-after state

Before reboot:


dhcp.lan.dhcp_option='3,10.100.1.1' '6,10.10.70.100'

GL.iNet LAN RPC:


{"interface":"lan","dns":["10.10.70.100"]}

Generated dnsmasq configuration:


dhcp-option=lan,6,10.10.70.100

After reboot:


dhcp.lan.dhcp_option='3,10.100.1.1'

dhcp.lan.dhcp_option_force='26,1472'

GL.iNet LAN RPC:


{"interface":"lan","dns":[]}

Generated dnsmasq configurations no longer contain option 6.

Relevant configuration diff:


config dhcp 'lan'

list dhcp_option '3,10.100.1.1'

- list dhcp_option '6,10.10.70.100'

+ list dhcp_option_force '26,1472'

The persistent DHCP configuration changed during boot. The available evidence does not identify the exact process responsible.

Hi,

Thank you for providing the detailed information and the steps to reproduce this issue.

We tested this behavior locally on the GL-E5800 and were able to reproduce the same issue: the custom DNS server configured in the LAN DHCP settings works normally before reboot, but the setting is lost after restarting the device.

We have recorded this issue and forwarded it to our development team for further investigation.
We will update this thread once we have further progress.

Thank you for your understanding and support.

this is affecting me as well and really annoying.
This means, after every boot of the router, you need to login into the admin panel and reset the DNS settings for DHCP.
Additionally it might happen, that in the meantime a connected client tries to run some DNS queries, which fail and get cached in failed state. Then you need to reset/restart these clients as well.

So basically this bug wastes a huge amount of time and makes me not want to use the router, unless i really really have to.

Sorry for the inconvenience. We have reproduced this issue and are working on a fix.

As a temporary workaround, please connect to the router through SSH and run:

uci delete 'qcmap_lan.@profile[0].ippt_bridge_context'
uci commit qcmap_lan

Afterward, the LAN DHCP DNS settings should be configurable as expected and should persist after a reboot.

To undo the change:

uci set qcmap_lan.@profile[0].ippt_bridge_context='0'
uci commit  qcmap_lan

Same issue here on a GL-E5800 (Mudi 7), firmware 4.10.0 (OpenWrt 23.05.4). Unfortunately the workaround does not help in our case.

What I did:

  1. uci delete 'qcmap_lan.@profile[0].ippt_bridge_context' and uci commit qcmap_lan

  2. Entered the custom DNS server again in the GL web UI (LAN → DHCP). Before the reboot it was active: dhcp.lan.dhcp_option='6,<dns-ip>', and dnsmasq had dhcp-option=lan,6,<dns-ip>.

  3. Rebooted.

Result: ippt_bridge_context did not come back, but /etc/config/dhcp is rewritten again during boot. The dhcp_option entry is gone and the DNS field in the UI is empty. The DHCP range set in the UI survives the reboot, only the DNS server is lost.

Setup: router online via repeater (Wi-Fi client) plus cellular as backup. The DNS server is in a private network reachable through a WireGuard client.

Is there an updated workaround or a firmware version with a fix?

Your result confirms that the documented ippt_bridge_context workaround does not resolve this variant on firmware 4.10.0. I’m not aware of a verified replacement workaround or a firmware version with this fix yet.

As a targeted check, temporarily disable the WireGuard client, configure a normal reachable DNS server (for example, your preferred public DNS), and reboot once. If the DHCP DNS entry still disappears, this helps rule out an interaction with the WireGuard/private route; if it remains, the VPN or routing setup is likely involved. Please report that result in this topic so it can be compared with the reproduced case.

This reply was generated by AI. Please verify its accuracy.

GL.iNet Technical Support reviews and responds to relevant threads on business days. Please allow time for a staff response.

Disabling the WireGuard client is not an option for us, not even as a test setup we could run with. The VPN tunnels are the main reason we use this router. The DNS server our clients need is only reachable through WireGuard, and a router that loses its LAN DHCP DNS setting whenever VPN is in use is basically useless for our purpose. If this cannot be fixed, we would rather stop using the Mudi 7 and switch to a different manufacturer.

Some more details that may help the developers:

  • The DHCP range set in the UI survives a reboot, only the DNS entry (dhcp_option 6) is removed.

  • /etc/config/dhcp is rewritten about 30–40 seconds after boot.

  • For now we run a small script from /etc/rc.local that re-adds dhcp.lan.dhcp_option='6,<dns-ip>' and reloads dnsmasq after boot. That works, but it is only a workaround and should not be necessary.

We would appreciate a proper fix in the firmware.

Hi,

Thank you for providing the additional details and sharing your test results.

We tested the previously suggested ippt_bridge_context workaround locally on firmware v4.10.0, and it worked in our testing.

uci delete 'qcmap_lan.@profile[0].ippt_bridge_context'
uci commit qcmap_lan

We have reported this issue to the relevant development team and working on a fix.

Thank you again for your feedback and understanding.

@charles2 thanks for testing. Unfortunately the ippt_bridge_context workaround does not solve it on our GL-E5800 (firmware 4.10.0). Here is everything we found over the last two weeks, maybe it helps the developers:

1. The DHCP DNS entry is lost not only at boot, but also during normal operation

  • ippt_bridge_context was deleted and committed (it did not come back), the DNS server was entered again in the UI, and the router was rebooted → dhcp_option 6 was gone again. /etc/config/dhcp is rewritten roughly 30–40 s after boot.
  • It also happens without a reboot: after about 40 minutes of uptime, /etc/config/dhcp was rewritten again and the DNS entry was removed. At the same moment the log shows QCMAP ... backhaulCommonConfig.sh, so it looks like a cellular reconnect makes QCMAP re-apply its LAN config and overwrite /etc/config/dhcp.
  • Only the DNS entry is lost. The DHCP range set in the UI survives, probably because qcmap_lan knows the range but has no field for a DNS server.

2. “Force DNS” turns itself back on after boot

  • In GL-DNS (gl-dns-v2), force_dns was set to 1 by itself about 6 minutes after a normal boot (/etc/config/gl-dns-v2 modified, nobody touched the UI). We had set it to 0 a few days earlier.
  • With force_dns=1, every client DNS request is redirected to the router (nft inet dns_table / dns_redirect: redirect to :53). The router’s own traffic does not go through the WireGuard tunnel, so it cannot reach our private DNS server and falls back to the public one. Result: public names resolve, internal names (behind WireGuard) do not.
  • Note: just setting force_dns=0 and restarting gl_dns is not enough. The redirect rule stays until /etc/init.d/firewall reload.

3. Our current workaround (works reliably, but should not be necessary)
A small script runs from /etc/rc.local after boot and from cron every minute. It:

  • re-adds dhcp.lan.dhcp_option='6,<dns-ip>' and reloads dnsmasq if the entry is missing
  • sets force_dns=0, restarts gl_dns and reloads the firewall if force DNS is on or the redirect rule exists

Tested: removing the DNS entry or force DNS being switched on by the firmware is corrected within one minute.

4. Two related things we noticed (in case they are useful)

  • “Full Cone NAT” (/etc/init.d/fullconenat) adds a MASQUERADE rule on every up interface at boot, including the WireGuard clients, even when masquerading is disabled for that VPN in the UI. We need routed (non-NAT) site-to-site traffic, so we remove those rules by script.
  • After a cellular reconnect, /proc/gl-kmwan/status sometimes shows the wrong netdev for modem_cpu (rmnet_data1 while the default route actually uses rmnet_data0).

Setup: GL-E5800, firmware 4.10.0 (OpenWrt 23.05.4), internet via cellular (repeater optional), two WireGuard clients with policy routing (include lists), DNS server in a private network reachable only through WireGuard.

Is there an ETA for a firmware with a fix? We are happy to test a beta or snapshot.