Avatar for Username

חיפוש בתמיכה

יש להימנע מהונאות תמיכה. לעולם לא נבקש ממך להתקשר או לשלוח הודעת טקסט למספר טלפון או לשתף מידע אישי. נא לדווח על כל פעילות חשודה באמצעות באפשרות ״דיווח על שימוש לרעה״.

מידע נוסף

אשכול זה הועבר לארכיון. נא לשאול שאלה חדשה אם יש לך צורך בעזרה.

Captive portal detection for public Wi-Fi login fails

  • 2 תגובות
  • 1 has this problem
  • 5 views
  • תגובה אחרונה מאת nanomir

nanomir
nanomir
more options

I'm using Firefox 102 on Ubuntu Mate 20.04 (the vanilla one from apt), but I think I've experienced the same with a couple of previous versions too ...

So, I've sat in one Espresso House in Denmark; tried to connect to their public Wi-Fi with Firefox in private mode, captive portal went fine, and I was on the Internet. Apparently I had gotten a danish IP address there, since google.com thereafter was in danish.

Now, I sit in a different Espresso House, also in Denmark; however, here, captive portal does not work; in the sense that:

As shown on first screenshot, first I get "You must log in to this network before you can access the Internet.", and I get a "Open network login page" button.

I click on the "Open network login page" button, I can see browser wants to load http://detectportal.firefox.com/canonical.html - but in the end, I do not get the Espresso House login page, but instead I get a redirect to https://support.mozilla.org/en-US/kb/captive-portal , where the "You must log in to this network before you can access the Internet." still stands, but there is no more "Open network login page" button (as shown on the second screenshot)

If I restart the browser in this shop, I think I get the exactly same process - Espresso House wi-fi login page never gets shown, only the https://support.mozilla.org/en-US/kb/captive-portal ...

Strangely, at this point, I do get access to the internet through a browser - but google.com is then in swedish, which I guess means, that there is some sort of a VPN of that shop's wi-fi to Sweden. On the other hand, I don't get internet elsewhere on my computer - for instance, if I want to do `sudo apt update` from the command line, I get errors like "Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)" - which is what I otherwise get in (the first mentioned) Espresso House, before I've connected to wi-fi via captive portal (once I connect to wi-fi via captive portal there, `sudo apt update` or any other network access from command line is fine).

(Note: my android phone in the same shop, does indeed show Espresso House Wi-Fi login prompt upon Wi-Fi connection, and I can login there fine).

Why does this happen, and how can I force Firefox to show me the actual captive portal so I can login to Wi-Fi - instead of redirecting me to https://support.mozilla.org/en-US/kb/captive-portal ?

I'm using Firefox 102 on Ubuntu Mate 20.04 (the vanilla one from apt), but I think I've experienced the same with a couple of previous versions too ... So, I've sat in one Espresso House in Denmark; tried to connect to their public Wi-Fi with Firefox in private mode, captive portal went fine, and I was on the Internet. Apparently I had gotten a danish IP address there, since google.com thereafter was in danish. Now, I sit in a different Espresso House, also in Denmark; however, here, captive portal does not work; in the sense that: As shown on first screenshot, first I get "You must log in to this network before you can access the Internet.", and I get a "Open network login page" button. I click on the "Open network login page" button, I can see browser wants to load http://detectportal.firefox.com/canonical.html - but in the end, I do not get the Espresso House login page, but instead I get a redirect to https://support.mozilla.org/en-US/kb/captive-portal , where the "You must log in to this network before you can access the Internet." still stands, but there is no more "Open network login page" button (as shown on the second screenshot) If I restart the browser in this shop, I think I get the exactly same process - Espresso House wi-fi login page never gets shown, only the https://support.mozilla.org/en-US/kb/captive-portal ... Strangely, at this point, I do get access to the internet through a browser - but google.com is then in swedish, which I guess means, that there is some sort of a VPN of that shop's wi-fi to Sweden. On the other hand, I don't get internet elsewhere on my computer - for instance, if I want to do `sudo apt update` from the command line, I get errors like "Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)" - which is what I otherwise get in (the first mentioned) Espresso House, before I've connected to wi-fi via captive portal (once I connect to wi-fi via captive portal there, `sudo apt update` or any other network access from command line is fine). (Note: my android phone in the same shop, does indeed show Espresso House Wi-Fi login prompt upon Wi-Fi connection, and I can login there fine). Why does this happen, and how can I force Firefox to show me the actual captive portal so I can login to Wi-Fi - instead of redirecting me to https://support.mozilla.org/en-US/kb/captive-portal ?
צילומי מסך מצורפים

כל התגובות (2)

cor-el
cor-el
  • Moderator
  • Top 10 Contributor
more options

You can try Firefox from the official Mozilla server if you currently use a version from the repositories of your Linux distribution to see if it behaves differently.

nanomir
nanomir Question owner
more options

Thanks for the replies, all:

> What I can see is your not given login access as the top line us saying until your granted this wifi access this becomes a laptop connectivity issue.

I don't think it's a laptop connectivity issue: both the hardware (i.e. WiFi card) and the operating system have demonstrated ability to establish a WiFi network connection in other contexts; to summarize my experience:

  • In OK shop: captive portal detection works (that is, I'm redirected to the Wi-Fi login webpage of the shop), thereafter both Firefox and the rest of the OS have network connectivity; Google is shown in local language
  • In bad shop: captive portal detection does not work (that is, I'm not shown the shop's login webpage, but instead I'm shown a Firefox help page); Firefox thereafter insists in the top bar message that "you must log in to this network before you can access the Internet" - but even the screenshot above shows that while the page https://support.mozilla.org/en-US/kb/captive-portal has been loaded from the Internet; Firefox then has Internet connection (in spite of the top bar message), but the rest of the OS does not; Google is shown in language from a foreign country (implying VPN or something similar).

> You can try Firefox from the official Mozilla server if you currently use a version from the repositories of your Linux distribution to see if it behaves differently.

Thanks, that helped.

  • First I tried with my usual Firefox, but I tried it with an "empty" profile (without any addons), this did not work (i.e. same behavior as before)
  • Then I downloaded official Mozilla Firefox for Linux, upon starting it I created a brand new empty profile for it - and this finally worked:

So with the Mozilla version of Firefox, when being asked to login to the network in the "bad" shop, I was not redirected to https://support.mozilla.org/en-US/kb/captive-portal - I was instead redirected to the actual shop login page, which in this case turned out to be this (slightly censored) URL:

https://n236.network-auth.com/splash/?mac=68%FFFF%3AFF%3AFF%3AFF%3AFF&real_ip=10.ZZZ.XXX.YY&client_ip=10.ZZZ.XXX.YY&client_mac=FF:FF:FF:8D:FF:FF&vap=1&a=0ade7c2cf97f75d009975f4d720d1fa6c19fffff&b=14381910&auth_version=5&key=a843f8f842707b56f878843ec9ae0672a0f3ffff&acl_ver=P1301069V2&continue_url=http%3A%2F%2Fdetectportal.firefox.com%2Fcanonical.html

The good thing is, after I logged in using this link, the top bar message disappeared - also after I closed this Firefox down, and opened my usual Firefox, with addons and all; and also, the rest of the OS can now use the Internet too (so I can now run `sudo apt update` also in the "bad" shop).

Thanks for the assistance - good to know there is a workaround, at least.