When Ubuntu clients connected to a GL.iNet mobile router fail to resolve the captive portal hostname with a "No address associated with hostname" error, the issue typically stems from DNS configuration conflicts or cached stale records rather than a complete network outage. Resolving this requires verifying the local DNS resolver settings, flushing the system cache, and ensuring that the client is correctly receiving DHCP options for name resolution from the router.
Understanding the Network Context
Mobile routers like those produced by GL.iNet often operate as standalone access points or bridge devices. When an Ubuntu machine connects via Wi-Fi or USB tethering, it expects to receive IP configuration and DNS server addresses through Dynamic Host Configuration Protocol (DHCP). The error message indicates that the operating system cannot translate the domain name of the login page into an IP address. This is distinct from a connection timeout; the link layer and network layer are likely functional, but the name resolution service is failing. This scenario differs significantly from backend web server errors. For context on general connectivity troubleshooting in similar Linux environments, you might find relevant insights in Troubleshooting React/Express on Nginx/Ubuntu, which discusses network stack integrity, though the focus here remains strictly on client-side DNS resolution.Verifying DHCP and DNS Settings
The first step is to confirm that your Ubuntu interface is actually receiving DNS information from the router. Open a terminal and identify your active network interface using the commandip a. Look for the interface connected to the mobile router, such as wlan0 or enp0s20f0u1.
Next, inspect the current network configuration. If you are using NetworkManager, which is standard on most Ubuntu desktops, run:
nmcli dev show | grep IP4.DNSnmcli con show, then update it:
nmcli con mod <UUID> ipv4.dns "<router_ip>"
nmcli con up <UUID><router_ip> with the actual gateway address of your GL.iNet device, which is commonly found in the router’s admin panel or printed on the device label. Note that specific default IPs vary by model, so relying on the output of ip route to find the gateway is safer than assuming a static value.
Flushing Local DNS Caches
Ubuntu systems usesystemd-resolved as the default stub resolver. This service caches DNS responses to improve performance, but it can also hold onto stale or incorrect records indefinitely. If you previously attempted to connect to the hotspot and received a partial response, or if the router changed its firmware settings, the local cache may be blocking new resolutions.
To clear these entries, execute the following command in your terminal:
sudo resolvectl flush-cachesresolvectl query google.comsudo systemctl status systemd-resolvedChecking /etc/resolv.conf and Symlinks
Historically,/etc/resolv.conf was a static file edited by users. In modern Ubuntu versions, it is a symbolic link pointing to the stub resolver. Misconfigurations here can cause persistent failures. Verify the symlink target:
ls -l /etc/resolv.conf/run/systemd/resolve/stub-resolv.conf. If it points elsewhere, or if it is a regular file owned by root with restrictive permissions, NetworkManager may not be able to update it dynamically. Restoring the symlink usually involves removing the old file and recreating the link, but this is rarely necessary unless manual edits were performed previously.
For users experiencing broader DNS issues related to privilege escalation commands, understanding how sudo interacts with network resolution can be helpful. See Sudo Complain: DNS Name Resolution in Ubuntu 22.04 for details on how environment variables affect resolution during privileged operations.
Router-Specific Captive Portal Behavior
GL.iNet routers often use a specific domain name for their captive portal, such asglinet.net or mywifi.gl-i.net. Some browsers or OS-level firewall rules may block UDP port 53 queries for these specific domains if they are flagged as suspicious or if strict DNS-over-HTTPS (DoH) is enabled in Firefox or Chrome.
Disable DoH in your browser settings temporarily. In Firefox, go to Settings > Privacy & Security > DNS over HTTPS, and select "Off". In Chrome, navigate to chrome://settings/security and disable Secure DNS. This forces the browser to use the standard DNS protocol provided by your system resolver, which is more likely to interact correctly with the router's local interception logic.
Additionally, ensure that your Ubuntu machine is not using IPv6-only resolution if the router does not support IPv6 for the captive portal. You can force IPv4-only resolution for testing purposes by adding ipv4.only=true to your NetworkManager connection profile, though this is generally a last resort.
Resetting Network Manager Connections
If the above steps fail, the connection profile itself may be corrupted. Instead of deleting connections arbitrarily, which can lead to loss of other network configurations, export your current profiles first. Usenmcli con show to list all connections. To reset the specific problematic connection, you can delete it and re-add it, but always ensure you have the SSID and password handy.
nmcli con del <connection_name>nmcli dev wifi connect <SSID> password <password>rm on network configuration files directly, as this can break the entire networking stack if not handled with extreme caution and proper backups.
Frequently Asked Questions
Why does the error happen only on some devices?
The issue often depends on how each operating system handles DHCP DNS options. Windows and macOS may accept fallback DNS servers differently than Ubuntu's strict systemd-resolved configuration. Devices that successfully connect likely received the correct DNS IP via DHCP, while the Ubuntu machine did not.
Can I use a public DNS like 8.8.8.8 to bypass the login page?
No, doing so will prevent you from reaching the captive portal entirely. The router relies on intercepting DNS queries for the login domain to redirect them to the authentication page. Using external DNS servers bypasses this interception, leaving you unable to log in even though you have internet access once authenticated.
What if my GL.iNet router doesn't provide a DNS IP via DHCP?
If the router fails to push DNS options, you must manually configure the static DNS settings on your Ubuntu machine to point to the router's gateway IP. This ensures that all DNS queries are sent to the router, allowing it to perform the necessary redirection for the captive portal.
Does disabling IPv6 help with this specific error?
Yes, if your mobile router does not support IPv6 or if the captive portal is IPv4-only, forcing IPv6 resolution can cause timeouts or failures. Setting the connection profile to prefer or require IPv4 can eliminate these conflicts and improve reliability on older hardware.
How do I check if systemd-resolved is blocking the query?
You can use the resolvectl query command followed by the hotspot domain name. If it returns "server returned error NXDOMAIN" or hangs, the resolver is actively failing to find the record. Check the logs with journalctl -u systemd-resolved for any denied queries or permission errors.