Open Bug 1583164 Opened 2 years ago Updated 2 months ago

False positives for detectportal and persistent "Open Network Login Page" prompts

Categories

(Core :: Networking, defect, P3)

69 Branch
defect

Tracking

()

People

(Reporter: benjaoming, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Using Airtel in Malawi via an Android Hotspot, it seems that detectportal.firefox.com is pointing to http://10.150.35.18:6510/detectportal.firefox.com/success.txt - I see this page when clicking "Open Network Login Page".

However, this page contains nothing and no login, but it's actually a proxy for detectportal.firefox.com (or so I would assume)

Using wget, I can see that subsequent requests to detectportal.firefox.com are not redirected.

Actual results:

I assume it's because the very first request is redirecting to this page, however it's impossible to reproduce in subsequent requests. However, periodically, the "Open Network Login Page" is displayed in ALL tabs and does not go away when clicking "X". Instead it shows up again.

Expected results:

  1. The "Open Login Page" should stop displaying after dismissing the prompt the first time.
  2. Since there is no login, the portal detection should be able to detect that there is this odd proxy that just echoes back the intended success message.

Hi @Benjamin Bach, for now I just could set a component; fell free to change it is isn't the proper one. Also, this issue could be related or duplicate of: 1559753, 1558023. We wait some support from dev's team.
Regards,
Liviu

Component: Untriaged → Networking
Product: Firefox → Core

Valentin, there seem to be two issues:

  • the hotspot redirect traffic which we, probably mistakenly, detect as a portal (not sure why, logs are probably needed)
  • the "must login" ui persists, this doesn't seem like a necko issue, unless they are somehow dependent on us to remove it
Flags: needinfo?(valentin.gosu)

Seems likely that the UI issue is a duplicate of #1559753 and #1558023 - thanks Liviu

The "false positive" mis-detection of the portal remains the issue. Perhaps someone could have a look at cases where responses include 301 and 302 but the content is still the expected "success". I won't be able to post logs, as I'm no longer on Airtel Malawi. I could try to setup a portal that mocks the behavior.

(In reply to Benjamin Bach from comment #3)

Seems likely that the UI issue is a duplicate of #1559753 and #1558023 - thanks Liviu

The "false positive" mis-detection of the portal remains the issue. Perhaps someone could have a look at cases where responses include 301 and 302 but the content is still the expected "success". I won't be able to post logs, as I'm no longer on Airtel Malawi. I could try to setup a portal that mocks the behavior.

We started treating any redirects as a captive portal in bug 1556259.
Since hotspot is actually intercepting your traffic and causing you to redirect, I would argue that this is actually captive portal behaviour, even though there is no actual login page.
We'll see if we can improve this in the future.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(valentin.gosu)
Priority: -- → P3
Whiteboard: [necko-triaged]
You need to log in before you can comment on or make changes to this bug.