ummm... I don't think the link points anywhere valid: http://the solution
Second, the issue is unpredictable behavior that gives undesired results (no connection) . As an example, it would be infuriating if /bin/ls did not give a listing, but occasionally acted like /bin/cd... In case anyone forgot, one of the basic tenets of UNIX is keeping things simple. And right now, connecting to wi-fi is anything but simple, there's lots of details that need to be correct. Should be still available to play with, but for the public, it needs to be as simple and reliable as /bin/ls, without extra options to complicate things.
Okay, there are problems. Even with a config that i
think is someway corrent, the connection does not build up reliably.
But then, how could one do it correctly? Lets look into the challenges:
- the wifi chip is started as an iface, it gets some configuration and scans for networks.
- in coordination with wpa_supplicant it decides for a network.
- dhcp takes over and tries to obtain, well, whatever ip, routing, resolver.
- now a graphic display must be started
- and a browser is required, but not any browser, only the absolute newest with the most elaborate ES6 support, otherwise it will not work
- in the browser the user needs to open a specific url (as reported from dhcp), and this is on an entirely different network - which then presents a webpage bloated with javascript which will not work with anything but the newest chrome browser.
- on that page the user has to click "yes" at "Access free wifi" (afterwards the browser is not needed anymore).
- Now the wifi should become functional, and we can connect to our VPN server at home.
- we have to change the routing, and the resolver accordingly, to some static and reliable configuration..
The fun here is, wifi is instable by nature (for instance train goes into a tunnel), and any of these steps can fail at any time, so for every step we must be able to correctly recover and retry.
For example, when VPN starts, the original default route from dhcp becomes a hostroute to the VPN server only, while a new default route is provided from VPN. Now whenever dhcp does refetch whatever that lease (and it does so frequently), the routes are usually gone, and consequentially the resolver also.
Now if you have any idea how to put all that into a neat application, preferraby commandline (but including the ES6), then please feel free to do so.
Bottomline: the whole matter is so horribly botched, it just cannot integrate into a properly structured networking implementation. In fact, we should never have allowed the Internet to get outside of the scientific community.
(the little I messed with this would just have wifi ignore the specified passworded AP and connect to a random open one)
