You are not logged in.

#1 2018-11-24 20:30:57

kjs3
Member
Registered: 2018-04-02
Posts: 6

[unSOLVED] Hotel WiFi issues (DNS?)

I’m at a Courtyard Marriott and completely lost trying to get my Thinkpad x1 carbon on their WiFi. It’s a typical hotel setup with open WiFi and a portal to log on.

My iPhone got on fine, opened the portal, and everything is working. Family member’s phones, laptops, and other devices seem to have joined without issue either.

I’m on Gnome using NetworkManager. I’m able to connect to the WiFi network fine but am left with the little ? icon and it seems like DNS resolution is failing. I don’t have custom DNS settings though. I’m trying to get sent to the login portal and here’s what I’ve tried.

* going to http://neverssl.com in a private Firefox window. No response at all.
* going to http://neverssl.com in a private Chromium window. No response at all.
* curl http://neverssl.com. Same. No response.
* visiting the router IP. I get redirected to a marriott.hotspotportal.com or something like that (I’m out atm). This seems like what I want but the redirect fails. Seems like DNS can’t resolve the domain.

So that’s where I’m at. Making my phone a hotspot and connecting to that works fine so it seems like WiFi in general is ok. Just not this particular hotel network. But it’s hard to blame that either since all the other devices are fine.

Any ideas on how to debug this?

Last edited by kjs3 (2018-12-03 23:20:06)

Offline

#2 2018-11-24 21:19:10

bugsmanagement
Member
Registered: 2017-04-21
Posts: 201

Re: [unSOLVED] Hotel WiFi issues (DNS?)

What would be particularity useful here, preferably Firefox, opening up Web Developer -> Console and moving between Console and Network to see what the browser is doing in the background while attempting to reach the Captive portal.

Offline

#3 2018-11-24 22:34:46

twelveeighty
Member
From: Alberta, Canada
Registered: 2011-09-04
Posts: 1,096

Re: [unSOLVED] Hotel WiFi issues (DNS?)

I stay at Marriott's a lot, their Wifi is never really a problem in terms of connecting (speed is a different matter) with NetworkManager.

Check the usual: NetworkManager service / system log (journalctl -b), dhcp client log. What is in /etc/resolv.conf? I've been in hotels where I had to hack the generated resolv.conf to bypass their shitty DNS server.

If your phone is connected, pull the connection details from your phone (easy on an Android, no idea where to look on an iPhone) and update /etc/resolv.conf and/or hack /etc/hosts to get that captive portal resolving. Once you're registered with the captive portal, you should be good.

Offline

#4 2018-11-25 00:33:11

kjs3
Member
Registered: 2018-04-02
Posts: 6

Re: [unSOLVED] Hotel WiFi issues (DNS?)

Whew, coming to you from a thinkpad!

Turned off automatic DNS and set it to 1.1.1.1, applied settings, but it still didn't work. Then I noticed that DNS still showed 172.20.0.1 on the connection details.
Turned wifi off and back on and DNS correctly showed as cloudflare's 1.1.1.1. Then neverssl.com just worked without logging in but https sites still failed.
I'm trying to remember how I got the portal to finally show up. Hitting the router at 172.20.0.1 actually didn't redirect me. I think just randomly trying 172.20.1.1 might have been when I got redirected to the portal.

Anyway, it works now. Thanks!

Offline

#5 2018-11-25 15:10:34

twelveeighty
Member
From: Alberta, Canada
Registered: 2011-09-04
Posts: 1,096

Re: [unSOLVED] Hotel WiFi issues (DNS?)

Glad you got it working! Please remember to mark your thread as [SOLVED].

Offline

#6 2018-12-03 23:19:54

kjs3
Member
Registered: 2018-04-02
Posts: 6

Re: [unSOLVED] Hotel WiFi issues (DNS?)

Changing this to [unSOLVED].

I had a flight last night with gogo and the same thing happened. Connecting to the wifi technically worked but I couldn't get the portal for the life of me. Tried manual DNS, hitting IPs directly, nothing worked.

When connected to wifi any request to a non-loopback IP returns an HTTP 302 with a Location header and a body containing a URL to the portal but I'm not able to resolve that URL in any way I've tried (browser, curl, postman).

Here's some terminal output from curl during the flight:

$ curl -v 1.1.1.1
*   Trying 1.1.1.1...
* TCP_NODELAY set
* Connected to 1.1.1.1 (1.1.1.1) port 80 (#0)
> GET / HTTP/1.1
> Host: 1.1.1.1
> User-Agent: curl/7.62.0
> Accept: */*
> 
< HTTP/1.1 302 Temporarily Moved
< Location: http://captive.gogoinflight.com/abp/checkDevice.do?CLI=172.19.131.48&acpu_redirect=true&airline_code=DAL&TAIL=N710TW
* no chunk, no close, no size. Assume close to signal end
< 
<html>
<body>
Questa pagina dovrebbe rinviarvi subito verso il sito di autenticazione.<p>
Se la ridirezione non avviene, <a href="http://captive.gogoinflight.com/abp/checkDevice.do?CLI=172.19.131.48&airline_code=DAL&TAIL=N710TW">fate clic qui</a>.
</body>
</html>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Then I try to GET that URL but it fails:

$ curl -v 'http://captive.gogoinflight.com/abp/checkDevice.do?CLI=172.19.131.48&airline_code=DAL&TAIL=N710TW'
* Could not resolve host: captive.gogoinflight.com
* Closing connection 0
curl: (6) Could not resolve host: captive.gogoinflight.com

Any other ideas on why DNS might be failing? Maybe I'm running something locally that's interfering? I turned off all the networked daemons I typically have running even though I'm pretty sure they couldn't effect DNS (postgres, redis, nginx, docker). I don't run dnsmasq. I'll have another flight on Friday to try this again but I'm back to being pretty lost.

Offline

#7 2018-12-04 01:39:47

r0b0t
Member
From: /tmp
Registered: 2009-05-24
Posts: 505

Re: [unSOLVED] Hotel WiFi issues (DNS?)

That's most probabl a DNS issue, the actual http redirect from the captive portal is working as shown in the logs but the DNS isn't.
Check the DNS server on the "working" devices and set it to your arch via network manager.
Try resolving the captive.portal domain and see if that works.
If that still doesn't work resolve it manually.

A pcap of the traffic with wireshark would help as well, if you don't see the traffic getting back from the physical interface then that's the captive portal's problem.
Maybe it creates some conflict with arch's connectivity check request, but that's another story.

Offline

Board footer

Powered by FluxBB