Hotel Wireless Internet Access

[ArchAngel777]

Accidently hit enter before I had anything typed in... Found a bug with the forum software as a result. It let me post, even though it shows a star that "Message Text" is required before posting. Well, it allowed me to post a completely blank message...

Ok, on to the issue/question...

Ok, my knowledge of this particular questions is lacking. What do hotels use to setup a portal/proxy page to allow access to their internet? If anyone travels here, you will know that when you connect to their wireless network, 99% of the time you will be brought to a webpage which you basically agree to the terms of service and then the router unblocks your access to internet IPs.

The question is this... How is this done? Is it a software that is install with the router (comercial grade, perhaps?) or is this a server computer running a proxy software package?

Second question is... How are they are to bring that URL into your browser. The browsers page that should load is the default browser that you have in your IE configuration settings (if using IE, I suppose). So, how do the hotels insert the URL to their portal page when opening up your browser?

This pretty much stems from a client not getting that portal page... He can connect to the network, is served his IP address, gateway IP and the DNS servers. Can ping everything on the internal network, unable to access the internet IP's due to the router blocking him. The portal is not coming up for him and I am not sure of the portals URL to have him manually type that in.

 

[ktwebb]

Captive Portal

Have him call the front desk. They won't know diddly squat of course but can point you to a 1-800 number, where you'll sit on hold for x minutes/hours but eventually someone should be able to help. That or have the front desk try to find someone else using the hotel internet connection and ask them what the re-direct URL is.

 

[Bluestealth]

Yes call them up and they can bypass the server by letting the guest's MAC address through.... not hard, usually caused by firewall/proxy on client's computers.
The front desk will try to help for about 30 seconds... but they are useless.

 

[ArchAngel777]

Originally posted by: ktwebb
Captive Portal

Have him call the front desk. They won't know diddly squat of course but can point you to a 1-800 number, where you'll sit on hold for x minutes/hours but eventually someone should be able to help. That or have the front desk try to find someone else using the hotel internet connection and ask them what the re-direct URL is.

Thanks for the suggestion. I had actually already contact the tech and asked him what the redirect URL was, but he had no idea. He said he was not at his computer (ok, where are you then?) and could not check the browser history. Nice enough guy, but I could tell his knowledge of TCP/IP was lacking. Especially since he gave me the same old BS is DNS issue... I am begining to hate that statement. DNS issues are so overstated and abused.

 

[ArchAngel777]

Originally posted by: Bluestealth
Yes call them up and they can bypass the server by letting the guest's MAC address through.... not hard, usually caused by firewall/proxy on client's computers.
The front desk will try to help for about 30 seconds... but they are useless.

Although I thought the same, this was not the case. There is no firewall or internet security programs loaded on my clients laptop. He is/was working fine on many other wireless networks. This was sort of the bump in the road for him. Strange issue, because the hotel has many others working fine. So, from what I can tell from all my troubleshooting is that the problem has to do with the laptop and the wireless router. They both are the problem as, each on their own, function perfectly proper.

 

[spidey07]

Yeah, captive portal. Pretty standard practice.

Doubtful it has anything to do with the client and the router - you have already said he can ping on the internal network (which is rare, I would not allow him to talk to anything but the captive portal)

Check and make sure he doesn't have any proxy settings on IE. I believe this will cause a captive portal to not work depending on how they set it up.

 

[ArchAngel777]

Originally posted by: spidey07
Yeah, captive portal. Pretty standard practice.

Doubtful it has anything to do with the client and the router - you have already said he can ping on the internal network (which is rare, I would not allow him to talk to anything but the captive portal)

Check and make sure he doesn't have any proxy settings on IE. I believe this will cause a captive portal to not work depending on how they set it up.

Already checked the proxy settings, also used FF and EI. But, the reason It has sometihng to do with the router and client is simple math.

A. Laptop connects to other wireless hotels and works fine. It loads the portal in the browser and loads.
B. Other customers at this specific hotel can connect and the portal comes up and they can surf fine.
C. Since both A and B can function on their own, without each other, then clearly, both A and B contribute to the problem.

 

[Bluestealth]

It could be a gateway made by Ip3 Networks .... wonder if anyone else has delt with those.

 

[spidey07]

Originally posted by: ArchAngel777

Originally posted by: spidey07
Yeah, captive portal. Pretty standard practice.

Doubtful it has anything to do with the client and the router - you have already said he can ping on the internal network (which is rare, I would not allow him to talk to anything but the captive portal)

Check and make sure he doesn't have any proxy settings on IE. I believe this will cause a captive portal to not work depending on how they set it up.

Already checked the proxy settings, also used FF and EI. But, the reason It has sometihng to do with the router and client is simple math.

A. Laptop connects to other wireless hotels and works fine. It loads the portal in the browser and loads.
B. Other customers at this specific hotel can connect and the portal comes up and they can surf fine.
C. Since both A and B can function on their own, without each other, then clearly, both A and B contribute to the problem.

Here's a litte advice for you.

You can't troubleshoot networking that way. The "well it works over here" doesn't apply.

Move through the OSI model and check each function. You can ping which means layer 3 works (and subsequently, layer2 which is where the AP and client operate)

so, move on up the stack...layer4. Telnet to a known good website on port 80 and see if you can connect, look at what is returned to you - connection refused or connection timed out. They mean very different things.

Can you ping your gateway? What about a traceroute? If it is a captive portal then you probably won't, but at least you're following good troubleshooting.

how about name resolution? Is that working and verified with NSlookup? Most times stuff like this is a DNS problem.

 

[ArchAngel777]

Originally posted by: spidey07

Originally posted by: ArchAngel777

Originally posted by: spidey07
Yeah, captive portal. Pretty standard practice.

Doubtful it has anything to do with the client and the router - you have already said he can ping on the internal network (which is rare, I would not allow him to talk to anything but the captive portal)

Check and make sure he doesn't have any proxy settings on IE. I believe this will cause a captive portal to not work depending on how they set it up.

Already checked the proxy settings, also used FF and EI. But, the reason It has sometihng to do with the router and client is simple math.

A. Laptop connects to other wireless hotels and works fine. It loads the portal in the browser and loads.
B. Other customers at this specific hotel can connect and the portal comes up and they can surf fine.
C. Since both A and B can function on their own, without each other, then clearly, both A and B contribute to the problem.

Here's a litte advice for you.

You can't troubleshoot networking that way. The "well it works over here" doesn't apply.

Move through the OSI model and check each function. You can ping which means layer 3 works (and subsequently, layer2 which is where the AP and client operate)

so, move on up the stack...layer4. Telnet to a known good website on port 80 and see if you can connect, look at what is returned to you - connection refused or connection timed out. They mean very different things.

Can you ping your gateway? What about a traceroute? If it is a captive portal then you probably won't, but at least you're following good troubleshooting.

how about name resolution? Is that working and verified with NSlookup? Most times stuff like this is a DNS problem.

Moving through the OSI model is "basic" networking and shouldn't even be explained here. This is something that is a given, something any network tech should be checking. As for my simplified explanation, in terms of basic mathematics, it can't be wrong. The problem lies between these two items specifically "Router & Client". There is no getting around this. That, however, does not change that fact that you do need to go through the OSI model to verify where the problem lies, but I already determined what the problem was (the portal) I just didn't know how to fix it due to their tech support not knowing the URL to the portal or why the router was not intercepting the http traffic and bringing this particular client to the portal.

Let me put it this way and I will try and be friendly about it... Uhm, the only person who informed me of anything I didn't know is the first reply to my message. Everything else that was suggested was tried previous to this. I am truly not trying to be a dink about it either as I am truly grateful for the help and ideas that this forum offers... However, it does unsettle me a bit when someone says "Here is a bit of advice" and then the advice is actually basic OSI Model that pretty much anyone learns is a basic networking class. That isn't to say that advice is wrong, it is just sort of... Well, that is a "given" something that need not be said.

But anyway, I truly appreciate the comments and #2 has the answer in this situation which linked to the captive portals and now I understand how it works (intercepts the HTTP data to redirects to the portal URL) and this is what is not happening for the client. The client can and does connect to portals all across the world, but this one was not redirecting him, though it did give him all the correct TCP information, down to DNS, Gateway and the IP is designated himself. Internal traffic worked fine, external was failing. No portal was opened -- Bummer -- Stumped. Moves to another hotel by the *SAME* tech firm, loads up and is brought to the redirect page, logs in, working fine... Ok, so the client works fine, right? Yes, it does. We test another different laptop on the problem network and it is given all the correct TCP information from the router (just like the problem client) and bring up a webpage and bing, redirect pops up. Strange, very the same tech company! See, this is why the basic example I gave above is correct, because it was applied with the OSI model already tested. No Proxy selected in either FF or IE and even if there was one setup, it would have never worked on the other hotel network that he tried I am sure I left out something, but anyway, that is it in a nutshell.

Thanks again guys, BTW, last night the problem was solved by finding the URL to the portal (It was 1.1.1.1) and now everything is working fine. If anyone knows why it wasn't doing this automatically, you get a cookie