I’m here in the hotel in Barcelona and Beryl AX can’t get a DHCP lease to the hotel wifi. Wifi will connect, DHCP never happens. Every single device I have from phones, laptops and even gl-inet own mango can connect to this wifi without problem. No captive portal or anything, straight out SSID+pass. Tried all things for 30 mins before giving up.
I could start wasting my time to debug this but I find it disheartening such basic functionality won’t work out of the box. Seems gl-inet is becoming a shop to pump out as many devices as possible yearly without any care to not breaking anything important. A ponzi scheme of sorts. Which makes you wonder the viability of them long term…
I’d pump the breaks there with the accusations. I’ve used many of their devices on various wifi networks globally and have not experienced the same issues you have. Each new device is better than the last by a long shot (except maybe for size). Try reinstalling the latest stable firmware on it without retaining settings and then let us know if you have problems. I’m guessing it’s user error.
Device just wont get DCHP lease on this particular wifi for whatever reason. Wifi connects and on the DHCP page info it just shows “getting…”. I’m on the latest stable release for Beryl AX 4.1.3. Beryl AX connects to my phone hotspot fine so there’s something specific about this one it doesn’t like. Then my mac, iOS devices and android phones all can connect to this Wifi without a hitch, so it’s easy to assign blame.
Then I’ve bought 6 gl-inet routers, I’m an active member in these forums, and use them extensively everywhere. They are useful, but, other than Mango, that works as expected all the time, all the other ones have always had quirks like this one. It’s fairly obvious gl-inet releases are too fast and there’s not enough QA. As a general rule for these devices, if you have a device+FW release that works for your use case, never update it.
I totally get what you are suggesting but why is it that whenever I struggle to connect to a hotel WiFi using GL.iNet, pulling my TP-Link or Huawei routers from the bag and turning them on and hey presto connection achieved with no fuss whatsoever? Are you suggesting that these establishments are targeting GL.iNet but not other travel routers? I mean just look at the countless posts complaining about getting wireless repeater mode to work with hotel or WiFi. I think that @glinetvr has a very valid point there.
There’s very limited ways in which an access point can recognize the device connecting. One I can think of is by having a lookup of the MAC address for the manufacturer then ban certain devices. Gl-inet is registered in the 94:83:C4:XX:XX:XX range. This sounds super unlikely though, as there’s not a fundamental motive behind this.
And in this particular hostal, which is a very low key cheap one with 6 rooms, the wifi is just your typical ISP provided fiber router/IP. I think I saw the box. Doubt gl-inet was being banned… very likely something else.
Do you have Adguard enabled? I sometimes have to turn Adguard off to register with the hotel wi-fi and get passed the captive portal. Then turn Adguard on once I’m online.
I’m gonna mark this as a solution (which is totally not, it’s just a hack) but if anyone finds themselves needing to guarantee no issues with hotel connectivity I suggest carrying a USB data cable for your phone, then use USB tethering.
On Android, the phone will tether you to whatever connection you have, so if phone is connected ot wifi you can use it as a Wifi client of sorts. Then
a) Connect phone to hotel Wifi
b) connect phone to gl-inet router with data cable
c) enable usb tethering on phone
d) enable tethering in gl-inet as your WAN option on gl-inet router.
This is very likely to work and has little overhead as Wifi packets flow through the kernel of the phone into USB and the router.
Is your time zone correct for your current location?
Do you know if the subnet of the hotel wifi happens to be the same as the Gl.iNet router?
Have you tried connecting to wifi with your phone first and cloning your phone MAC on the router?
Can you try toggling the hardware acceleration setting?
Have you tried fiddling with the repeater settings (cog top right):
I’ve seen some hotels block devices based on MAC OUI lookups… my solution has been to randomize, or spoof the MAC address of the router to that of my iPhone or laptop… 9/10 times the randomized MAC does the trick, since most iOS devices do that now by default on new networks anyway. Organizations aren’t able to accurately block the randomized MAC devices due to unknown vendor… Cisco and Aruba are working on technologies that will inspect traffic, and try to determine device manufacturer based on traffic patterns (e.g. Wi-Fi calling connections, iCloud connections could mean iPhone… Microsoft.com windows update, is likely a windows device) and based on those patterns will treat devices different with QoS and security policies.
The only other issues I’ve seen that took a long time to figure out was at a client of mine. Their Meraki wireless was configured to detect rogue access points and isolate them with AirMarshal… basically flooded my devices with deauth, so Wi-Fi was unstable. Had to get an exception made. The router would connect perfectly, but the rebroadcast SSID didn’t work. Connecting via Ethernet to the router worked for that one until I found the issue and added an exception on the Meraki side (very frustrating).
This is all fine and makes sense but still doesn’t answer the fundamental question of why this is the case with GL.iNet but not with other arguably more prevalent travel routers like TP-Link or Netgear!
I did try all the repeater settings. Locking to 2.4ghz, 5ghz, only 20Mhz, no DFS… nothing helped. Issue was definitely past the Wifi layer, as the wifi connection seemed established.
Time zone was not set for current location
Unsure of hotel subnet. good suggestion
Did not try to clone MAC.
Nothing in the logs seemed a red flag, other than the DHCP request was not being finished, which we already knew from the status screen.
Like I said in the OP I had a short stay for vacation time in beautiful Barcelona and I just did not have the time to debug this. This is the second time Beryl has failed for me in a hotel (previous was in Amsterdam Hotel) and it’s starting to be a major letdown.
i have the same problem at home
I have some UniFi-APs at home with 4 wifi-networks. The internal wifis goes to a window dhpc-Server and are fine. The guest-wifi’s dhcp is served by the FW, an opnsense. The opnsense ist offering, but the Beryl-ax ist not working. > Any hint what to look for in the logfiles of Beryl?
Same setup with Creta or Slate in stock-FW works fine. Also a Creta with OpenWrt 22.03.5 works in this setup.
Regards.
Michael
the log of the DHCP-Server in OPNsense say’s:
DHCPDISCOVER from 92:83:c4:2c:c1:a6 (GL-MT3000) via em3
DHCPOFFER on 10.25.1.250 to 92:83:c4:2c:c1:a6 (GL-MT3000) via em3
So the req. from Beryl is coming to the DHCP-Server an the DHCP is offering.
But in the systemlog of berly there is no select for an IP, only udhcpc: started, v1.33.2 and sending discover. Next entry is already the connect to the wifi.
Anywhere else to look for more details?
Regards.
Michael
Any other thoughts on this? My GL-MT3000 on v4.2.2 is also not getting an IP address. I tried a random MAC address and also cloned my Android device’s MAC address with no luck. The Android device is able to connect to the wifi without a problem.
The logs show a periodic “udhcpc: sending discover”.
