GL.iNet GL-MT6000 (OpenWrt 21.02 snapshot / v4.9) — LAN DNS Issues + SQM Behavior in Dual WAN Setup

Router
1

Hello everyone,

I’m trying to understand some stability and behavior issues I’m observing on the GL.iNet GL-MT6000 running OpenWrt 21.02 snapshot (v4.9), especially related to LAN DNS behavior and SQM in a dual-WAN environment.

I would like to know if others have experienced similar behavior or if this is expected design limitation.

:magnifying_glass_tilted_left: 1. LAN DNS Stability Issue

Problem observed:

Devices connected to LAN (especially iPhones) occasionally show:

  • Connected to WiFi but “No Internet”

  • DNS resolution failures or inconsistent responses

  • Browsing works intermittently even when ping to public IPs is fine

My setup:

  • Router: GL.iNet GL-MT6000 (OpenWrt 21.02 snapshot)

  • LAN: 10.1.1.0/24 (br-lan)

  • DHCP handled by dnsmasq

  • AdGuard Home installed (used for DNS filtering on port 3053, sometimes disabled for testing)

  • Dual WAN:

    • WAN (eth1 → ISP router)

    • WWAN (WiFi repeater / apclix0)

What I noticed:

The issue seems related to DNS routing inside LAN, such as:

  • dnsmasq sometimes forwarding DNS to:

    • AdGuard (127.0.0.1#3053)

    • ISP DNS servers

    • or fallback resolvers

  • DHCP DNS options changing behavior depending on configuration state

  • Missing or inconsistent /tmp/resolv.conf.auto

  • Clients receiving different DNS behavior depending on routing state

Question (LAN DNS):

Has anyone experienced:

  • LAN devices connected but showing “No Internet”?

  • DNS instability when using AdGuard with dnsmasq?

  • Problems after changing DHCP DNS settings?

  • Recommended stable LAN DNS architecture for MT6000?

:high_voltage: 2. SQM / QoS Behavior in Dual WAN Setup

Observation:

When using SQM (cake/fq_codel):

  • It seems to mainly control WAN interface traffic only

  • LAN-originated traffic or secondary interface flows may not always be shaped consistently

  • In dual-WAN setup, behavior becomes less predictable

  • Some traffic appears to bypass expected queue discipline depending on routing path

My setup:

  • Dual WAN:

    • WAN (eth1)

    • WWAN (apclix0 WiFi repeater)

  • LAN bridge: br-lan (10.1.1.1)

  • Policy routing not heavily customized

Question (SQM):

Is this expected behavior in OpenWrt SQM?

Specifically:

  • Does SQM only shape egress WAN traffic by design?

  • Can SQM be applied effectively to LAN-side flows or bridge interfaces?

  • Any recommended configuration for dual-WAN + SQM stability?

  • Any known limitations on MT7986 / GL-MT6000 platform?

:brain: Summary

It looks like I may be dealing with two related areas:

  • LAN DNS inconsistency (likely dnsmasq / AdGuard interaction)

  • SQM behavior being WAN-centric by design

I would appreciate any clarification or best practice recommendations.

Thanks in advance :+1:

1 Like
3

Hi

Sorry for the delayed reply.

Regarding the LAN DNS issue

  1. Modern operating systems typically determine Internet connectivity by checking both DNS resolution and the ability to reach certain public services. If either of these checks fails, the device may conclude that there is no Internet connection and display a "No Internet" status.

    The next time the issue occurs, we recommend running the following commands on one of the affected LAN devices to help determine whether the problem is related to DNS or general network connectivity:

    # Windows (Command Prompt)
nslookup google.com
tracert 8.8.8.8

# macOS / Linux
nslookup google.com
traceroute 8.8.8.8

  2. It is normal for the dnsmasq configuration to change based on your Admin Panel → Network → DNS settings and your AdGuard Home configuration.

  3. By default, the router advertises only its LAN IP address as the DNS server via DHCP. This does not change based on your DNS or AdGuard Home settings.

Regarding the SQM issue

  1. In the current firmware (v4.9.0), SQM is designed to run on the br-lan interface, and both inbound and outbound traffic are shaped.

  2. As mentioned above, SQM is currently applied to br-lan, not the WAN interface. If you previously installed luci-app-sqm yourself and configured it to run on WAN, that configuration may have been preserved.

  3. At the moment, the GL.iNet SQM implementation does not support multi-WAN. If you need SQM in a multi-WAN setup, you may need to use luci-app-sqm instead.