So my issue is similar to this one, but probably not the exact same.
Also it might be either related to the KDE mechanism for finding a registration/landing page (usually where it says “agree to terms to use our Wlan”), or the Firefox one (which, I don’t understand why both always involve themselves, it feels like either one should do the trick on its own), but I decided to post in the KDE section.
If I connect to a free Wifi with a registration page, first Plasma’s registration prompt pops up:
Pressing “register”, a Firefox tab opens up (or Firefox is launched, if not running yet, it’s my default browser), displaying https://networkcheck.kde.org/
which is just a page saying “OK” and it has a button to open the registration page to this network:
pressing that button opens a second tab that loads detectportal.firefox.com/canonical.html
which says you have to register to this network to access the internet (otherwise the page is empty)
and loads forever, no portal
… in some places, not in others! e.g. It often works at Mcdonalds, but not always.
It always works on my Android phone in all the places, I’m directly taken to the landing page.
A) How to fix it?
B) Why is it so many steps? It should really be from the Plasma prompt directly to the landing page - there’s no good reason for two separate (empty) tabs with more buttons being shown inbetween.
I cannot test right now, and it is not a solution but a workaround:
I think i managed to once force Chrome(ium based) browser to display the captive portal by manually loading https://www.gstatic.com/generate_204
You can test next time and tell us. If it works - you can make a bookmark and hit it manually when the popup comes up. Not ideal, but better than no internet at all.
It is the same as hitting detectportal in firefox, but there might be differences in the implementation of this DNS forwarding.
Generally, if you try to load any non-https page it should load automatically, but sometimes it is stuck.
One can also try to load the portal directly - sometimes it is on the gateway, sometimes, esp. on larger networks, the DNS is somewhere else. dig somesite will show the current dns resolver at the bottom under “server”. Then try to load it in the browser. I have not tried it though.
I only understood maybe half of that.
I just wanted to test your suggestion of https://www.gstatic.com/generate_204, but for some reason, the Cafe’s own landing page came up just now, without the workaround (I still used Firefox, not using Chromium-based).
However, since the same thing works fine on an Android phone, IMO, the problem is on an OS level, the browser shouldn’t matter, and no manual entering of URLs should be required. I’d really like to see it addressed by Manjaro (it’s also not the same behavior in other distros).
I just threw a couple of ideas to test as workarounds.
I have no idea why it does not work in some cases. It has happened to me in CromeOS too, but very rarely. I will come back to report here next time i am on a public spot, but i do not remember that it happened on my current laptop (i use XFCE and Chromium).
Android is relatively reliable in that aspect…although in one case it was misconfiguration of the portal itself.
The addresses you mentioned are part of the internet detection mechanisms, they are not the actual login pages of the wifi connection in question.
It’s too long and detailed to go into details to explain you how this mechanism works exactly.
But for you to be able to login, a simple step is to open your browser and navigate to http://www.google.com/, which will make the WiFi profider that you are trying to connect to redirect you to their LOCAL-IP registration page…
That actually IS the LOCAL-IP page i mentioned above, plus it IS an URL
The whole “Captive portal” feature works by redirecting DNS requests, thats why the login pages in portals ALWAYS have IP’s instead of domain names…
Thanks for the infos, correcting wrong terminology
Actually, trying to load any web page to trigger a redirect to the captive portal is not workin here, it can sometimes work, but, again, is not a reliable workaround.
Just pointing out for the record: problem isn’t solved.
Well then either you didn’t explain your problem well enough, or i don’t understand the problem…
Captive Portal in a nutshell: # SPDX-License-Identifier: CC-BY-NC-SA-4.0
User tries to connect to any domain. (Using domain names)
The captive portal’s network stack intercepts all such requests and answers with a HTTP Redirect code to the LOCAL-IP based login page.
Your OS, no matter which one, detects this redirect code when checking the captive portal URL they use.
If it gets a redirect code it shows the message to the user that it needs to login.
If it gets a normal response, with or without a special content that is dependend on the URL, it rcognizes that there is no captive portal involved.
If the Captive portal gets a submission on it’s login page, it alters it’s filtering / firewall rules to let the trafic flow as usual for that user’s-IP ONLY.
On a phone, the captive portal is loaded without the need to open any browser, i.e. just by pressing the “register to this network” button (which is imo how it should work in any OS). Either that, or Android/other OSs do send a request to Google.com or sth. just by pressing that button.
But whatever the standard procedure may be, it frequently fails on my Manjaro in places where Android has no problem. I tried to describe it in detail in the first post, I have no idea how else to do it better.
