We're calling on all EU-based Mozillians with iOS or iPadOS devices to help us monitor Apple’s new browser choice screens. Join the effort to hold Big Tech to account!

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Need help troubleshooting a hotel LAN (captive portal)

  • 2 replies
  • 5 have this problem
  • 1 view
  • Last reply by wkrp

more options

This problem isn't specific to Firefox but I'm trying to see how I can use Firefox's debugging capabilities to troubleshoot a network problem. I'm staying in a hotel in China that uses a so-called "captive portal" to authenticate people before using the network. (That means one's first browsing action is redirected to the hotel's web page for entering login info -- as is also commonly done in coffee shops, etc.) Using my own notebook PC, the redirection works if I use wifi, and fails if I use the network cable (Firefox and IE both give the same results). I want my PC to work in both cases (and, in fact, it worked the previous day using a network cable at another location of the same hotel chain, that also uses what appears to be the same redirection scheme). The hotel staff demonstrated to me that a hotel-supplied PC will work with the cable. So from their point of view, something is wrong with my PC, and from my point of view, something is wrong with their network. I need to find out which it is.

I enabled HTTP logging in Firefox on my PC. I noticed a cycle of GET requests where a URL was repeatedly URL-encoded (so ':' becomes '%3A', which becomes '%253A', then '%25253A', etc.). So the GET requests keep getting longer until they reach a limit, I guess... the final result being a '400' error ('bad request'). Since their servers are causing the redirections, I can only assume that they have a bug causing this repetitive URL encoding. But, mysteriously, the hotel-supplied PC does not exhibit the problem (and neither does my PC when using wifi). As far as I can tell, Firefox and IE both fail in the failure case, and both succeed in the success case, so I don't suspect the browser.

My objective is to either fix my system (if that's where the fault lies) or show the hotel staff that the fault is in their network (by demonstrating that the fault can occur even without my PC being involved). Troubleshooting effort on the hotel-supplied PC is limited by the fact that, once the authentication succeeds, I can't induce it to expire, so I can't experiment much with the redirection mechanism using that PC. Any ideas?

This problem isn't specific to Firefox but I'm trying to see how I can use Firefox's debugging capabilities to troubleshoot a network problem. I'm staying in a hotel in China that uses a so-called "captive portal" to authenticate people before using the network. (That means one's first browsing action is redirected to the hotel's web page for entering login info -- as is also commonly done in coffee shops, etc.) Using my own notebook PC, the redirection works if I use wifi, and fails if I use the network cable (Firefox and IE both give the same results). I want my PC to work in both cases (and, in fact, it worked the previous day using a network cable at another location of the same hotel chain, that also uses what appears to be the same redirection scheme). The hotel staff demonstrated to me that a hotel-supplied PC will work with the cable. So from their point of view, something is wrong with my PC, and from my point of view, something is wrong with their network. I need to find out which it is. I enabled HTTP logging in Firefox on my PC. I noticed a cycle of GET requests where a URL was repeatedly URL-encoded (so ':' becomes '%3A', which becomes '%253A', then '%25253A', etc.). So the GET requests keep getting longer until they reach a limit, I guess... the final result being a '400' error ('bad request'). Since their servers are causing the redirections, I can only assume that they have a bug causing this repetitive URL encoding. But, mysteriously, the hotel-supplied PC does not exhibit the problem (and neither does my PC when using wifi). As far as I can tell, Firefox and IE both fail in the failure case, and both succeed in the success case, so I don't suspect the browser. My objective is to either fix my system (if that's where the fault lies) or show the hotel staff that the fault is in their network (by demonstrating that the fault can occur even without my PC being involved). Troubleshooting effort on the hotel-supplied PC is limited by the fact that, once the authentication succeeds, I can't induce it to expire, so I can't experiment much with the redirection mechanism using that PC. Any ideas?

Chosen solution

Try this: go to your Control Panel then Network and Sharing Center then click on change adapter settings on the left side. Right click on your Ethernet -> properties then select internet protocol version 4 -> properties and click on obtain ip address automatically and obtain dns server automatically.

Read this answer in context 👍 1

All Replies (2)

more options

Chosen Solution

Try this: go to your Control Panel then Network and Sharing Center then click on change adapter settings on the left side. Right click on your Ethernet -> properties then select internet protocol version 4 -> properties and click on obtain ip address automatically and obtain dns server automatically.

more options

To Dziple308: OK, it worked (the terminology on Windows XP is a little different, but basically the same). I should have thought of this myself. What happened was that the hotel staff in the previous hotel set a fixed IP on my PC, and that caused the problem in the current hotel (whose "captive portal" system bizarrely enters an infinite redirection loop in that case). I'm not a big fan of captive portals (as I think DNS hijacking and/or HTTP masquerading probably violates some RFC somewhere), but what can I do, I'm just a lowly user. Thanks and best wishes!