1043097 - Unable to connect to "Stanford Visitor" wireless network's captive portal

Status: RESOLVED DUPLICATE of bug 1041511

(Core :: Networking, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: screencast

STR:
 1. Visit Stanford.
 2. Connect to "Stanford Visitor" wireless network.
 3. Open a web browser, and try to visit any non-https site (e.g. http://www.blizzard.com), which bounces you to their captive portal URL. Or alternately, just visit the captive portal URL directly:
  https://ctw-webauth.sunet.stanford.edu/fs/customwebauth/login.html

ACTUAL RESULTS:
 Firefox's "Server Not Found" error page

EXPECTED RESULTS: Correctly load the captive portal.

After I waited a few minutes (continuously reloading & failing to load the page), it finally started succeeding -- not sure why.

I tried this several times with fresh profiles in Firefox Nightly, and each time I got ACTUAL RESULTS.

Firefox release version (31), Chrome (version 36), and Opera (version 12.16) all gave EXPECTED RESULTS.


I suspect this bug depends on you being physically at Stanford to reproduce. Sorry :-/ That may make it harder to diagnose. (I'm just visiting at the moment; don't know when I'll be here next.)


Attaching a screencast of Firefox 31 side-by-side w/ current Nightly, each using a fresh profile.  As shown in the screencast, Firefox loads the captive portal page immediately, whereas Nightly has an error page, even after a few reloads, and then eventually succeeds. (This screencast was taken after Nightly had been running for a few minutes, too, which I think made it get to "working" quicker during the screencast.)

Comment 1

[Daniel Holbert [:dholbert]]

I wonder if this might be due to cert revocation checking?  I recall that being turned on recently.

keeler, do you know when that happened? (and was it more recently than when Firefox 31 split off of trunk?)  If so, that seems like a likely candidate for causing network issues when trying to load a HTTPS captive-portal page. (somewhat intentionally, I guess, though it makes for an unfortunate user experience :-/ )

Comment 2

[Daniel Holbert [:dholbert]]

(It looks like the OCSP prefs have the same default values between my Nightly & Firefox 31, so maybe that's not the explanation after all.)

Comment 3

[Daniel Holbert [:dholbert]]

(Never mind -- I don't think this is OCSP/cert-related after all, because I'm hitting what appears to be the same issue on the "Stanford" wireless network, which has an initial HTTP splash page (which works) with a button that links to http://snsr.sunet.stanford.edu/snsr/index.jsp (which does not work), and there's no HTTPS involved.)

Comment 4

[Daniel Holbert [:dholbert]]

I tested up-to-date Aurora & Beta, too -- couldn't reproduce there. Can only repro in Nightly. (Re-tested Nightly after the others, to be sure.)  Using brand-new fresh profile every time.

Aurora: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
 (datestamp from help|about: 32.0a2 (2014-07-21))

Beta:  Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0

Comment 5

[Patrick McManus [:mcmanus]]

daniel, I can't resolve off the stanford net - so I'm going to assume that's a 1918 address and probably a dup of 1041511.. if you can retest with network.zonepolicy.enabled set to false we can confirm. if you can't retest because you aren't there anymore I guess we should assume that's the issue because its a private name and the timing matches.

Comment 6

[Daniel Holbert [:dholbert]]

(Sadly, I'm not there anymore, so I can't re-test.)