Closed Bug 583228 Opened 14 years ago Closed 8 years ago

Firefox not playing nice with internet access hotspots (attwifi, Starbucks, airport and hotel wifi, etc.)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 562917

People

(Reporter: mitsu, Unassigned)

Details

Attachments

(1 file)

NSPR log
1.11 MB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

Since I updated to 3.6.8 I have noticed Firefox is no longer playing nice with Internet access hotspots such as the AT&T Wifi hotspots at Starbucks locations (i.e., attwifi), airport and hotel wifi, etc. Typical behavior with these hotspots is they override DNS requests and redirect traffic to their signup or login page, from which you enter in login info or agree to their terms and conditions, after which normal internet access is granted. The 3.6.8 build of Firefox seems to instead insist on "detecting" the broken DNS and showing a cached version of the page, even when hitting refresh over and over again, or switching to "Offline Mode" which is extremely irritating. I am on Mac OS X so I have had to resort to running Safari in order to log in.

Reproducible: Sometimes

Steps to Reproduce:
1. I believe it is important to make sure the page you're trying to use (say, the Google homepage) to initially load is in the cache. So, connect to a normal network connection and load your homepage.
2. Go to an internet hotspot such as Starbucks, airport, hotel, Boingo, etc.
3. Attempt to load your homepage.

Actual Results:  
Firefox shows the cached page rather than the redirected page, and sometimes goes to Offline Mode. Switching off Offline Mode does not help. Must resort to using a different browser to log in to the hotspot.

Note that this does not occur every time, but in my recent experience is happening more than half the time. It seems to occur only when I have a recent cached copy of the page I am initially attempting to load.

Expected Results:  
It should redirect the request and show the signup, terms acceptance, or login page for the hotspot in question.

My suspicion is that some new code in Firefox intended to detect broken DNS or perhaps even hijacked DNS is being "too smart" and, rather than allowing the DNS to correctly redirect the user to an alternate page, it insists on displaying the cached page instead. However nice this might be to prevent computers from being hijacked, it is causing Firefox to be unusable as a way of logging into most wifi hotspots at least half or more of the time.
Will check this out over the weekend when I can access a Starbucks. I think I recall another report of this with 3.6.8 - so this may be a dupe.
Mitsu: Did this work using Firefox 3.6.7 and now you noticed it does not work using 3.6.8?
Well keep in mind that it does not always fail. It just sometimes fails ---- and I haven't yet pinned down exactly how to reproduce reliably. However yes, I do not recall ever seeing this problem in earlier versions, though I'm not sure if the last time I was traveling was when I had 3.6.7 or an earlier version.
Just a bit of further information: I've noticed this multiple times with different hotspots: so far, a Starbucks in NYC (the one near Astor Place), the JetBlue wifi hotspot at JFK airport, the hotel wifi hotspot at the Shattuck Plaza Hotel in Berkeley, CA, and the Boingo hotspot at London Heathrow airport (I've been traveling a lot recently). In most of the cases it both worked and didn't work in the way documented above, and in every case Safari worked fine.

I did try to search for a dupe of this but didn't find one, but maybe someone described the bug differently.
Version: unspecified → 3.6 Branch
You can't use Firefox at Starbucks or for any Wifi connections that have sign on pages, period. It's been that way for years. You have to go to IE, sign in, then go back to Firefox. I guess none of the Firefox devs ever used a public wifi service.
I can confirm that this still happens. I use Chrome to authenticate with these types of networks.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 3.6 Branch → Trunk
I never had issues connecting using Firefox. I may have used shirt+reload though, don't remember.
*shift+reload ... :)
Hm. I have tried shift+reload without success, unfortunately. I should note that I do not see old cached content when this happens, as the reporter did, but instead see a generic "can't connect to server" message.
Could it be a DNS resolver issue? I don't know if Firefox and Safari uses the system's resolver.
Firefox uses the system's DNS resolver.

Could you try a few things?

1) close and restart the browser.

if that doesn't fix things,

2) Empty your HTTP cache (Preferences | Advanced | Network | "Clear now" in "Cached Web Content" section).

Also try 

3) try to connect to an http:// destination and not an https:// one.

If any of these work it may help to narrow down the bug here.
Amazing. It's been four years and this still doesn't work?

My guess is that this is due to DNS caching, or DNS server caching. Firefox is not correctly detecting that the user has logged into the network and DNS is working again. I suspect the code only checks when the user joins a new Wifi or wired network, but not when they log into an existing Wifi connection.
The work on bug 939318 should if not fix this, be an excellent foundation for getting this fixed properly. The problem being two parted:

A) noticing the situation

B) acting on it

The B) part is at least done in that bug and I plan to work on the A) part going further.
Component: General → Networking
Product: Firefox → Core
(In reply to John Karahalis [:openjck] from comment #9)
> Hm. I have tried shift+reload without success, unfortunately. I should note
> that I do not see old cached content when this happens, as the reporter did,
> but instead see a generic "can't connect to server" message.

if shift-reload is not doing the trick then nothing daniel talks about in comment 13 is going to help. That work is more or less about noticing automatically there have been topology changes and flushing all connections and caches that might be relevant. shift-reload does that same thing in an awkward manual manner.

so :openjck if you can reproduce with shift-reload it would be really interesting to see an NSPR log along with a narrative of what you do see (e.g. a spinner, or a blank page, or the login page again, or whatever..) vs what you expect to see.

The NSPR logging information for networking can be found here: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Yes, it would be great to have an NSPR log here.  None of us on the networking team actually run into this issue (I log into wifi at cafes all the time) so there may be something special that's going on in the cases here.  A log would be really helpful.
(In reply to Patrick McManus [:mcmanus] from comment #14)

> if shift-reload is not doing the trick then nothing daniel talks about in
> comment 13 is going to help.

Really? Is the DNS cache re-init and the socket service restart done on a shift-reload? We've seen exactly those things fix similar problems before (they can be triggered by manually setting "offline mode" on and then off again)
(In reply to Daniel Stenberg [:bagder] from comment #16)
> (In reply to Patrick McManus [:mcmanus] from comment #14)
> 
> > if shift-reload is not doing the trick then nothing daniel talks about in
> > comment 13 is going to help.
> 
> Really? Is the DNS cache re-init and the socket service restart done on a
> shift-reload? We've seen exactly those things fix similar problems before
> (they can be triggered by manually setting "offline mode" on and then off
> again)

you could be right :)

I said that basically because shift-reload
 1] bypasses the dns cache
 2] and always uses a new socket

but wrt #2 we've certainly seen wedge cases where that isn't enough
Interestingly, I cannot seem to reproduce this in a new Firefox profile. It only happens with my existing Firefox profile. (That said, I do remember this happening on completely different computers, so I don't think it's just this one profile that has issues.)

I get the message "The connection was interrupted". I will try the other steps at another time.
(In reply to Jason Duell (:jduell) from comment #11)
> Firefox uses the system's DNS resolver.
> 
> Could you try a few things?
> 
> 1) close and restart the browser.
> 
> if that doesn't fix things,
> 
> 2) Empty your HTTP cache (Preferences | Advanced | Network | "Clear now" in
> "Cached Web Content" section).
> 
> Also try 
> 
> 3) try to connect to an http:// destination and not an https:// one.
> 
> If any of these work it may help to narrow down the bug here.

No luck with these steps.

(In reply to Daniel Stenberg [:bagder] from comment #16)
> Really? Is the DNS cache re-init and the socket service restart done on a
> shift-reload? We've seen exactly those things fix similar problems before
> (they can be triggered by manually setting "offline mode" on and then off
> again)

Setting offline mode off and on again also has no effect.
Attached file NSPR log — 

    
    

    
  
(In reply to Jason Duell (:jduell) from comment #11)
> Firefox uses the system's DNS resolver.

And I'm quite sure Chrome uses its own resolver, for once (but I don't know for Safari).

> 
> Could you try a few things?
> 
> 1) close and restart the browser.
> 
> if that doesn't fix things,
> 
> 2) Empty your HTTP cache (Preferences | Advanced | Network | "Clear now" in
> "Cached Web Content" section).
> 
> Also try 
> 
> 3) try to connect to an http:// destination and not an https:// one.

Very good point: when I know I am in such captive portals, I always start a connection to a http:// server that gets redirected to the captive portal, while using a https:// server always times out. A "normal" user wouldn't know the difference obviously.

    
    

    
  
(In reply to John Karahalis [:openjck] from comment #20)
> Created attachment 8443273 [details]
> NSPR log

I appreciate the log John. Here's what I see

1] there is no http port 80 requests in it; only 443 https. Captive portals are basically hijacking you - so they play poorly with our https code which authenticates.

2] dns seems fine.. for instance www.yammer.com resolves to 204.152.18.206 which looks right

3] tcp seems fine - we log a successful, albeit slow, handshake

4] we don't complete a TLS handshake .. after a couple attempts we get reset by the server - that fails the transaction. I could see a firewall doing this for an anauthenticated client on port 443.

I wonder if people are seeing the safe-browsing bug we've had reports of with the great firewall of china. Monica is working on that.. but basically the firewall there swallows TCP syn (it doesn't reply or reset) for some https.. and the safe browsing code gets caught up in that and times out - and other (regular http://) requests are blocked on the safe browsing code.

That's just an idea - but its not what this log shows.. this log looks like you should try http://www.cnn.com to at least see what happens there. I guess it could be the same thing (a reset but this time in http space instead of tls handshake) - I'm not sure what the next step would be in that case.

    
    

    
  
I'm not near one of these networks at the moment, but IIRC manually visiting "http://google.com" had the same effect.

    
    

    
  
A non-technical friend of mine caught this happening in the wild. He met someone in the airport who complained that Firefox was recommended by their IT department, but that they didn't like to use it because they "could never connect to the internet in airports."
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE

    
    

    
  
I think also add to the mix that recently google is requiring https - i used to edit my home page taking out the 's' (plus the tls stuff at the end) I found very helpful, once i get the redirect to work (e.g. in I.E.), (always wanted to say that) i cut the URL to that FIRST page & paste to a bookmark in firefox, then just use the bookmark. sometimes doesn't work  (maybe the "portal" is already being used by another user.)
here's what worked at Fred Meyer:
https://loginportal5.wanderingwifi.com/Portals/(S(25ox5cdfd1h5xilpeecwu0uc))/Login/FreeUserAgreement.aspx

Safeway's done that to me for years.

    
    

    
  
Possible additional authentication error source. My recent install of Fedora 25 OS w/Firefox, at a Texas Health Resources facility, using free Cisco wifi hotspots, resulted in a web page pop up detailing a web authentication error caused by a time difference between internet time and the default time of the Fedora Live-CD install media. I find that using Live-CD install media, on free wifi websites, requires web authentication prior to attempting a hard disk install with downloads of updates as part of the OS install process.

After many OS Live-CD install attempts via free wifi hotspots, I would actually pay for a web browser configured to SUCCESFULLY INTERFACE AND AUTHENTICATE with free wifi routers and access points. The suggested browser should be neutered ( compared to a main line browser ) to optimize TCP technologies and embedded web pages. Browser add-ons and associated menus with default logon/login for all manufacturers.  The manufacturer's default data is available at many web sites. Additional capabilities of neutered nmap
( and associated but neutered internet applications ).  Neutered in these instances because full blown capabilities are not needed. Just the select capabilities needed to successfully complete/authenticate the edge connected wifi access points. Addition browser only capabilities to accurately report access failures and possible corrective actions would be appreciated.

P.S.  a bootable portable app Browser that would facilitate WIFI ACCESS AND WEB AUTHENTICATION ( usually good for two hours at my usual att.com free wifi hotspot).  Then a Live-CD installation w/updates would be possible without the use of the normally out of date browser or very minimal capability browser on the associated Live-CD installation media.

Thank you for your consideration of these recommendations.
 

James M. McDonald   j834_4562@yahoo.com

    
    

    
  
(In reply to rickycornell from comment #5)
> You can't use Firefox at Starbucks or for any Wifi connections that have
> sign on pages, period. It's been that way for years. You have to go to IE,
> sign in, then go back to Firefox. I guess none of the Firefox devs ever used
> a public wifi service.

It's frustrating as can be. See it in some android browsers too. Doesn't even give you the option to add an exception.

    
    

    
  
and to add...I work in many hospitals and a majority have a sign in, so it's annoying to have to deal with another browser on a daily basis just for this issue.

    
    

    
  
It's been worked on. See the network.captive-portal-service.enabled pref. It's now enabled by default at least in Aurora.

Looking at bug 1313706, looks like it will ship in v52. But you can enable the pref right now on other channels, with possible bugs.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: