# \[BUG\] GL-E5800 Mudi 7 — LAN DHCP DNS setting is lost after reboot **URL:** \ **Category:** VPN, DNS, Leaks\ **Created:** [August 19, 2026, 1:55pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682 "2026-08-19T13:55:10Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Motobyte](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/7bcc69/32.png) [@Motobyte](https://forum.gl-inet.com/u/Motobyte)\ **Post date:** [August 19, 2026, 1:55pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/1 "2026-08-19T13:55:10Z")
# [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: ```plaintext 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: ```plaintext dhcp.lan.dhcp_option='3,10.100.1.1' '6,10.10.70.100' ``` GL.iNet LAN RPC: ```json {"interface":"lan","dns":["10.10.70.100"]} ``` Generated dnsmasq configuration: ```plaintext dhcp-option=lan,6,10.10.70.100 ``` After reboot: ```plaintext dhcp.lan.dhcp_option='3,10.100.1.1' dhcp.lan.dhcp_option_force='26,1472' ``` GL.iNet LAN RPC: ```json {"interface":"lan","dns":[]} ``` Generated dnsmasq configurations no longer contain option 6. Relevant configuration diff: ```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. ---
**Author:** ![charles2](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/c/9dc877/32.png) [@charles2](https://forum.gl-inet.com/u/charles2)\ **Post date:** [August 20, 2026, 10:49am UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/3 "2026-08-20T10:49:52Z")
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. ---
**Author:** ![mike-more-mike](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/m/c4cdca/32.png) [@mike-more-mike](https://forum.gl-inet.com/u/mike-more-mike)\ **Post date:** [September 13, 2026, 12:03pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/4 "2026-09-13T12:03:25Z")
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. ---
**Author:** ![will.qiu](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/w/b38774/32.png) [@will.qiu](https://forum.gl-inet.com/u/will.qiu)\ **Post date:** [September 16, 2026, 4:09am UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/5 "2026-09-16T04:09:53Z")
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](https://docs.gl-inet.com/router/en/4/tutorials/ssh_log_in_to_the_router/) and run: ```sh 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: ```sh uci set qcmap_lan.@profile[0].ippt_bridge_context='0' uci commit qcmap_lan ``` ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [October 3, 2026, 6:54pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/7 "2026-10-03T18:54:16Z")
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,'`, and dnsmasq had `dhcp-option=lan,6,`. 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? ---
**Author:** ![AI\_bot](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/a/ecccb3/32.png) [@AI\_bot](https://forum.gl-inet.com/u/AI_bot)\ **Post date:** [October 3, 2026, 6:54pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/8 "2026-10-03T18:54:56Z")
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. ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [October 3, 2026, 7:03pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/10 "2026-10-03T19:03:31Z")
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,'` 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. ---
**Author:** ![charles2](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/c/9dc877/32.png) [@charles2](https://forum.gl-inet.com/u/charles2)\ **Post date:** [October 8, 2026, 8:28am UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/11 "2026-10-08T08:28:40Z")
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. ```auto 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. ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [October 16, 2026, 3:04pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/12 "2026-10-16T15:04:23Z")
@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,'` 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. ---
**Author:** ![Dustin282](https://forum-assets.gl-inet.com/letter_avatar_proxy/v4/letter/d/d78d45/32.png) [@Dustin282](https://forum.gl-inet.com/u/Dustin282)\ **Post date:** [October 18, 2026, 2:38pm UTC](https://forum.gl-inet.com/t/bug-gl-e5800-mudi-7-lan-dhcp-dns-setting-is-lost-after-reboot/70682/13 "2026-10-18T14:38:50Z")
One more issue on the same GL-E5800 (firmware 4.10.0), probably related, because it is again triggered when QCMAP re-applies its configuration: **The router itself becomes unreachable through the WireGuard tunnel after the WAN connection changes** Setup: two WireGuard clients with policy routing (include lists). `wgclient1` goes to our home network, `wgclient2` to the office. Internet access is via cellular or repeater, which changes while travelling. What happened: - The router switched to a new repeater Wi-Fi. At that moment the log shows `QCMAP ... backhaulCommonConfig.sh` rebuilding the firewall. - After that, the router’s LAN IP was **not reachable from the home network** any more (ping, SSH, web UI, SNMP). The tunnel itself was up: the tunnel IP of `wgclient1` still answered, and clients behind the router could still reach the home network. - Cause: in `inet vpn_table`, the rule `wgclient1_in_new_connmark` was **missing** after the rebuild, while `wgclient2_in_new_connmark` was still present. Without it, the router’s own replies to connections that came in through `wgclient1` are not marked. They are routed via the main table (default route over the repeater) instead of back through the tunnel, and get lost: - A side effect of the same routing design: the router’s own traffic never uses the tunnel, so the router itself cannot reach a DNS server that is only reachable through WireGuard. This is also why “force DNS” breaks internal name resolution (see my previous post).