When traveling, I have experienced multiple times I am unable to connect to Hotel WiFi using repeater mode of my GL.iNet router. I often stay in hotels for only one night but it is important to me to have secure Internet access and thus I have a Beryl AX (GL-MT3000) travel router. I configure it with a VPN. I use Windows 11 Pro.
I recently was at a hotel and had successfully connected to the WiFi in repeater mode using version 4.6.9. I then installed 4.7.0 (2024-10-18) beta and the same connection failed. So the new firmware version introduced a conenction bug.
But each hotel has its own WiFi setups, some primitive and some sophisticated, some with passwords and some not. It would be hard for GL.iNet to test across all the variations and combinations of Access Points and WiFi hardware, versions and configurations. GL.iNet will not have all the hardware and configurations for all combinations as there are just too many.
In order to solve (long-term) where I cannot establish a WiFi repeater connection, I suggest:
GL.iNet add to their routers a configurable feature to automatically record, store, and forward the technical details and logs they would use to diagnose the connection issue.
Store and forward is required to store as I cannot make a Internet connection - possibly until I reach the next hotel the next night.
Forward/upload the technical details and logs automatically when an Internet connection is finally established and provide an upload history with receipt identifiers.
Users can use the upload receipt identifier if they need specific technical support from GL.iNet.
Be configurable so users can choose to opt in/out. If a user has not opted in, they could be prompted on the next router login that a connection problem was identified and would they like to opt in or approve this one upload.
Uploads be automatically processed. Machine learning can scan across the uploads to find patterns for where GL.iNet developers should focus.
New firmware versions can enrich the details and logs where issues have been found to continuously improve future investigations.
I would see this as participating in a continuous improvement program and I would not be expecting automatic individual responses. Obviously, this works with other router connection modes (eg: via ethernet)
For alot i agree, but i stopped with machine learning
the issue where it can conflict is some people still use advanced setups, therefor what will machine learning pick and what would the desired reaction to a dev be?
I don't see how that works, i have seen it with Windows, and it gave me so many negative reactions from installing drivers automatically, to not getting the old consent dialogue boxes, just because they depend on AI, doesn't mean their actions help quality.
Went from normal sata port in where windows saw it into a swappable usb drive, on very old mobos.
^ just as example of demostration.
That is one which need to be carefully evaluated, other than that having a record of what devs want seem very good idea
I agree that there are many, many possible hardware/software combinations, configurations, and setups. Some advice from GL.iNet Support is to provide a network diagram with the details the user knows to help them understand.
But this is the point of using machine learning to here look across large number of uploaded logs etc and identify patterns of failures. I am not thinking of generative AI to suggest or provide coding solutions but to quickly highlight the scenarios of failure and where they fail. Help the developers quickly find the root cause.
There is a correlation with the more information into the input for the model, the more precise will be its output. So uploading the user's configuration (minus sensitive data like identifiers/passwords etc) could be an optional upload along with the logs.
As for training the model, a successful connection is easy to test for. Where they are failing, is it at a common place in the code? Or a particular setup?
I am no means an expert to machine learning but I have read of different organizations across different IT news sites of using machine learning models this way.
I would also say there is a lot of IT to be built for this solution and potentially new skills needed (for machine learning). So thus a sizable commitment would be needed to implement. So agreed, it is best to review and assess with eyes wide open.
I see, well im not a openwrt dev , but i think one can write such code detecting certain wifi log messages, or making the network config readable or wireless, and detect known corner cases which might point to a misconfiguration, a simple one i might can think of is a simple dhcp conflict where peoples upsteam router use same dhcp.
However it becomes hard to figure out the other side i.e what the hotel is doing here are some examples which are hard to track and are only findable by trying interraction, however if your attempt fails a hotel could also block you.
they look into your mac vendor id, that are the first 3,4 octals of a mac address and block you upon that, they likely have lists which vendors are considered routers, so mac cloning is required.
they do hop detection, for them it is a easy detection because they measure the ttl outcome, your ttl will likely be higher than expected thus meaning they block you, the trick is to check what ttl is counted for one hop what a direct connection looks like.
maybe they did something in the captive portal where it can detect a other routers page, it won't be cookies since if you click or login it would work again, but that does not prevent them to hide a image or javascript element trying to resolve to a gateway ip (i.e your routers page), also some use google captchas which are not always instantly making its appearance.
^ i mean if i was one of them i think it is actually a smart move i could theoretically for loop through rfc1918 and bruteforce gateway ips until my javascript detects either a refused state, or 200 OK state, as far as i know in firewalls defaults it is easily detected because if i type 192.168.8.2 (must be a non connected device), i see refused message rather than dropped, assuming they drop everything.
now the gl captive portal detection works only for clicking this won't work if it is not aware of cookies or even certain popping up captchas, if it doesn't accept them they can be aware.
You make good points.
Maybe just getting router logs and configuration is not enough as you pointed out the way a hotel implements their network is unknown and varied. Attempts by the router to try different connection methods might trigger blocking.
My thinking is you need data (logs/configuration for connections) for failures, and successes, to make decisions to how to code the connection software needed for the WiFi repeater. Getting real-world data is important otherwise the router is coded and tested to a limited number conditions.
I am interested to hear what the GL.iNet response will be.
I am traveling a lot. Sometimes 7 hotels a week, airports, buses, and trains... I am really happy with the OP24 version. I have not seen a single Wi-Fi problem since.
, but i think one can write such code detecting certain wifi log messages, or making the network config readable or wireless, and detect known corner cases which might point to a misconfiguration, a simple one i might can think of is a simple dhcp conflict where peoples upsteam router use same dhcp.