Hello,
I am having an issue with my GL-MT3000 / Beryl AX in repeater mode on a hotel Wi-Fi network. I normally use this router in hotels without problems, but at this specific hotel the router can associate to the Wi-Fi network, but it never receives an IPv4 address via DHCP. Because of that, the captive portal never opens.
The strange part is that manual/static IP configuration works, so the Wi-Fi association itself is not the problem.
Environment
Router:
Model: GL-MT3000 / Beryl AX
Firmware/log bundle: mt3000_4.8.1_log
Firmware version: 4.8.1
OpenWrt base shown in logs: v21.02.3 / mt7981 packages
Hotel Wi-Fi:
SSID: InterContinental
Security: open / none
Captive portal: yes, hotel public Wi-Fi
Router mode/config:
Mode: Repeater
Upstream interface when using 5 GHz: apclix0
LAN interface: br-lan
LAN IP: 192.168.8.1/24
My goal is simply to use the GL-MT3000 as a travel router/repeater and share the hotel Wi-Fi with my devices.
Main problem
When I configure the repeater normally with DHCP/automatic IP, the GL-MT3000 connects to the hotel SSID, but wwan never receives an IPv4 lease.
The logs show that the router associates successfully:
connected to InterContinental
Network device 'apclix0' link is up
Interface 'wwan' has link connectivity
Interface 'wwan' is setting up now
Then DHCP starts:
udhcpc: started, v1.33.2
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending discover
But there is never any:
DHCPOFFER
DHCPACK
lease obtained
bound
So the router never gets an IPv4 address from the hotel network. Since there is no IP address, gateway, DNS, or default route, the captive portal cannot be reached.
Manual/static configuration that works
I was able to make internet work by manually configuring the repeater interface with the IP settings copied from a working client.
This is the working manual configuration:
IP Address: 192.168.146.114
Netmask: 255.255.224.0
Gateway: 192.168.128.1
DNS Server 1: 192.168.128.1
DNS Server 2: empty
MAC cloned from PC (already autenticatedbefore from captive portal in hotel)
With this manual configuration, the GL-MT3000 has internet access and shares it correctly to LAN/Wi-Fi clients.
Important detail: I first tried the same IP with this netmask:
255.255.255.0
That did not work, because the router had:
IP: 192.168.146.114
Gateway: 192.168.128.1
Mask: 255.255.255.0
With /24, the gateway is outside the local subnet, so the router did not create a proper default route. After changing the netmask to:
255.255.224.0
the gateway became reachable and internet started working.
So the static/manual configuration works, but automatic DHCP does not.
DHCP mode configuration shown in debug logs
When using automatic mode, the debug log shows this for wwan:
config interface 'wwan'
option proto 'dhcp'
option classlessroute '0'
option metric '20'
option hostname '*'
option mtu '1500'
When DHCP fails, ifconfig shows apclix0 has only IPv6 link-local, no IPv4 address:
apclix0 Link encap:Ethernet HWaddr A2:D3:**:**:**:24
inet6 addr: fe80::a0d3:17ff:fe89:af24/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500
The route table also confirms there is no upstream route, only the internal LAN route:
========table main :==========
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
There is no hotel subnet route and no default route when DHCP mode is used.
Example log from DHCP failure
One test used random MAC:
A2:D3:17:89:AF:24
The relevant log:
Wed May 27 21:40:12 daemon.info gl-repeater[2609]: using random macaddr: A2:D3:17:89:AF:24
Wed May 27 21:40:13 daemon.info gl-repeater[2609]: connecting to bss: InterContinental 02:ec:da:f5:73:55 36 none
Wed May 27 21:40:22 kern.warn kernel: LINK UP !!! wdev(name=apclix0,type=2,func_idx=1,PortSecured=22)
Wed May 27 21:40:22 kern.warn kernel: BssType=1, AID=2, ssid=InterContinental, Channel=36, CentralChannel = 38
Wed May 27 21:40:23 daemon.info gl-repeater[2609]: connected to InterContinental 02:ec:da:f5:73:55
Wed May 27 21:40:23 daemon.notice netifd: Network device 'apclix0' link is up
Wed May 27 21:40:23 daemon.notice netifd: Interface 'wwan' is setting up now
Wed May 27 21:40:23 daemon.notice netifd: wwan (20072): udhcpc: started, v1.33.2
Wed May 27 21:40:23 daemon.notice netifd: wwan (20072): udhcpc: sending discover
Wed May 27 21:40:26 daemon.notice netifd: wwan (20072): udhcpc: sending discover
Wed May 27 21:40:29 daemon.notice netifd: wwan (20072): udhcpc: sending discover
No lease is ever obtained.
Another later test used another random MAC:
F6:65:B6:88:C8:CA
The result was the same:
Wed May 27 21:58:48 daemon.info gl-repeater[2609]: using random macaddr: F6:65:B6:88:C8:CA
Wed May 27 21:58:49 daemon.info gl-repeater[2609]: connecting to bss: InterContinental 02:ec:da:f5:73:55 36 none
Wed May 27 21:58:59 daemon.info gl-repeater[2609]: connected to InterContinental 02:ec:da:f5:73:55
Wed May 27 21:58:59 daemon.notice netifd: Interface 'wwan' is setting up now
Wed May 27 21:58:59 daemon.notice netifd: wwan (4187): udhcpc: started, v1.33.2
Wed May 27 21:58:59 daemon.notice netifd: wwan (4187): udhcpc: sending discover
Wed May 27 21:59:02 daemon.notice netifd: wwan (4187): udhcpc: sending discover
Wed May 27 21:59:05 daemon.notice netifd: wwan (4187): udhcpc: sending discover
Again, no DHCP lease.
Things I already tried
I tried different MAC modes:
Random MAC
Cloned laptop MAC
Different random MACs
The result is the same: the router connects to the SSID but does not receive DHCP.
This is especially confusing because my Android phone uses a randomized MAC on the same hotel SSID and works correctly. So I do not think the hotel is simply blocking randomized MAC addresses. It may be related to DHCP client behavior/fingerprint, DHCP options, or the GL.iNet repeater implementation.
I also tried this through SSH:
uci set network.wwan.proto='dhcp'
uci set network.wwan.broadcast='1'
uci set network.wwan.hostname='android'
uci -q delete network.wwan.vendorid
uci -q delete network.wwan.clientid
uci commit network
ifdown wwan
sleep 2
ifup wwan
But it did not solve the problem. After reconnecting, the debug logs still showed:
option hostname '*'
and I did not see option broadcast '1' in the final wwan config. It looks like the GL.iNet repeater service may be overwriting or regenerating the wwan configuration.
BSSID/AP observations
The router connected to different BSSIDs on the same SSID, for example:
InterContinental 02:ec:da:f5:73:55 channel 36
InterContinental 02:ec:da:f5:78:48 channel 36
I also saw this kernel message before some successful associations:
ERROR: AP BSSID not equal
But after that, the router still reports LINK UP and connected to InterContinental.
I have not confirmed whether this is related to the DHCP failure. It may be normal in an environment with many hotel APs using the same SSID, but I wanted to mention it.
Why I think this is not a captive portal issue
The captive portal cannot be reached because DHCP never completes.
The order should be:
1. Wi-Fi association
2. DHCP lease: IP, netmask, gateway, DNS
3. HTTP redirect / captive portal
4. Internet access
In my case, step 1 works, but step 2 fails. The router never receives an IPv4 address in automatic mode.
With manual static IP, the router reaches the network and internet works.
What I would like help with
Can someone from GL.iNet or the community help confirm whether this is a known issue with the GL-MT3000 / firmware 4.8.1 in repeater mode on open hotel/captive-portal networks?
