☰

Ubuntu 17.10 上无法连接到谷歌星巴克 wifi

tag-icon • tag-icon networking wireless 17.10
Ubuntu 17.10 上无法连接到谷歌星巴克 wifi

错误报告

概括

由于某种原因，Ubuntu 会丢失与处理路由器登录的路由器 URL 关联的 IP 地址的跟踪。我发布了一个解决此问题的答案。在手机上查找路由器的 IP 地址，并将其输入/etc/hosts尝试处理路由器登录的名称下。这为我解决了问题。如果您所在位置的 SB 设置不同，还有其他答案。

细节

我在手机上看到一个帖子说要把连接服务的主机IP添加到/etc/hosts。浏览器地址栏显示的url是：

https://sbux-portal.globalreachtech.com/check?cmd=login&mac=a0:88:39:65:f0:cc&essid=Google%20Starbucks&ip=172.31.98.108&apname=24%3Ade%3Ac6%3Ace%3A49%3Af6&apmac=24%3Ade%3Ac6%3Ace%3A49%3Af6&vcname=S17730-VC&switchip=aruba.odyssys.net&url=http%3A%2F%2Fdetectportal.firefox.com%2Fsuccess.txt

所以我照做了，但结果是一样的。有什么想法吗？星巴克是唯一无法连接的 WIFI。

如果您知道 Google WIFI/星巴克何时修复了此问题，请告知我们。

我尝试使用 macchanger 来更改 mac 地址：

Permanent MAC: a0:88:69:15:f0:cc (Intel Corporate)
New MAC:       00:11:22:33:44:55 (CIMSYS Inc)

但那并没有起作用。

今天 4 月 18 日，我尝试使用一台完全不同的笔记本电脑，但仍然遇到同样的问题。消息显示：

 Error resolving "aruba.odyssys.net": Name or service not known.

到目前为止，我什么都没用。我联系了星巴克的 WIFI 支持部门和他们的一般客户支持部门，但到目前为止，没有人能估计这个问题何时或是否会被修复。星巴克支持部门给了我这个参考号码：

 180413-010073

他们说打电话给 Wifi 支持部门并给出电话号码，他们会解决这个问题。当我打电话给 Wifi 支持部门时，他们说他们不需要电话号码，而且他们无能为力。对于一家竭尽全力提供优质客户体验的公司来说，这真是太可悲了。他们推出这个解决方案已经一个多月了，但仍然没有得到解决。

错误解决消息

当尝试在浏览器中连接时，它会重定向到此 URL 并挂起https://aruba.odyssys.net/cgi-bin/login。

更新

今天还尝试使用我的手机 MAC 地址。没有用。星巴克 Wifi 认为我是一台新笔记本电脑，所以它再次打开了初始启动页面注册，但完成输入后它仍然挂起https://aruba.odyssys.net/cgi-bin/login。

答案1

我遇到的问题是 Ubuntu 不知道如何访问https://aruba.odyssys.net/cgi-bin/login。主机aruba.odyssys.net 是WIFI路由器。

解决方法

  • 找到该路由器的 IP 地址并将其添加到/etc/hosts。
  • 在某些情况下您可能还需要添加一行/etc/resolv.conf。

详细步骤

  1. 查找路由器 IP-在终端运行：

    ip route

    （示例输出default via 172.31.98.1：）

  2. 通过运行来编辑文件sudo nano /etc/hosts以添加以下行：

    172.31.98.1 aruba.odyssys.net

  3. 可选？sudo nano /etc/resolv.conf在任何其他名称服务器条目之前添加该行：

    nameserver 172.31.98.1

此后，连接便顺利进行。

错误报告

问题似乎是错误报告：1766969。

答案2

就此事与谷歌 Wifi 支持人员进行了沟通。如果您使用同一个电子邮件地址注册多个设备，星巴克闪屏页面就会出现一个已知问题。您注册的第一个设备可以正常工作，但第二个设备则不行。如果您可以在无线网卡上使用克隆的 MAC 地址，则可以再次进入注册页面并使用不同的电子邮件地址。

答案3

whois不是查找地址的正确工具，而且它主要处理域名。要查找 IP，请使用nslookup或dig甚至ping：

>dig sbux-portal.globalreachtech.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> sbux-portal.globalreachtech.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36541
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sbux-portal.globalreachtech.com. IN    A

;; ANSWER SECTION:
sbux-portal.globalreachtech.com. 14121 IN CNAME sbux-portal.odyssys.net.
sbux-portal.odyssys.net. 1521   IN      CNAME   wlb1.us-east-1.sbux-portal.globalreachtech.com.
wlb1.us-east-1.sbux-portal.globalreachtech.com. 14121 IN CNAME wlb1-1579773356.us-east-1.elb.amazonaws.com.
wlb1-1579773356.us-east-1.elb.amazonaws.com. 1521 IN A 52.55.178.64
wlb1-1579773356.us-east-1.elb.amazonaws.com. 1521 IN A 34.233.215.66

;; AUTHORITY SECTION:
us-east-1.elb.amazonaws.com. 1214 IN    NS      ns-1119.awsdns-11.org.
us-east-1.elb.amazonaws.com. 1214 IN    NS      ns-1793.awsdns-32.co.uk.
us-east-1.elb.amazonaws.com. 1214 IN    NS      ns-235.awsdns-29.com.
us-east-1.elb.amazonaws.com. 1214 IN    NS      ns-934.awsdns-52.net.

;; Query time: 59 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Apr 09 21:50:10 CEST 2018
;; MSG SIZE  rcvd: 346

>nslookup sbux-portal.globalreachtech.com
Server:         127.0.1.1
Address:        127.0.1.1#53

Non-authoritative answer:
sbux-portal.globalreachtech.com canonical name = sbux-portal.odyssys.net.
sbux-portal.odyssys.net canonical name = wlb1.us-east-1.sbux-portal.globalreachtech.com.
wlb1.us-east-1.sbux-portal.globalreachtech.com  canonical name = wlb1-1579773356.us-east-1.elb.amazonaws.com.
Name:   wlb1-1579773356.us-east-1.elb.amazonaws.com
Address: 52.55.178.64
Name:   wlb1-1579773356.us-east-1.elb.amazonaws.com
Address: 34.233.215.66

>ping -c 1 sbux-portal.globalreachtech.com
PING wlb1-1579773356.us-east-1.elb.amazonaws.com (34.233.215.66) 56(84) bytes of data.
^C
--- wlb1-1579773356.us-east-1.elb.amazonaws.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

（ping将另外确认该端是否可以访问，但没有得到答复也可能意味着该站点不响应ping请求）。

答案4

由于这是一个 DNS 解析问题。我决定看看 Ubuntu 是如何解析该名称的：

dig aruba.odyssys.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> aruba.odyssys.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1821
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;aruba.odyssys.net.     IN  A

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Apr 27 15:50:04 PDT 2018
;; MSG SIZE  rcvd: 46

因此失败了，它正在使用127.0.0.53作为名称服务器。我检查了我的手机，它能够连接，它正在使用的 DNS 服务器。结果发现后面跟着8.8.8.8，8.8.4.4这对于 Google 网络来说是有意义的。果然：

dig @8.8.8.8 aruba.odyssys.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @8.8.8.8 aruba.odyssys.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52482
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;aruba.odyssys.net.     IN  A

;; AUTHORITY SECTION:
odyssys.net.        899 IN  SOA ns-543.awsdns-03.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 46 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Apr 27 15:49:23 PDT 2018
;; MSG SIZE  rcvd: 127

这显然有效！所以我修改了我的/etc/resolv.conf添加

# nameserver 127.0.0.53 # comment out the local cache.
nameserver 8.8.8.8
nameserver 8.8.4.4

瞧，我可以通过打开 Firefox 并再次触发登录页面来进行连接。

明确告知您不要/etc/resolv.conf通过进行编辑systemd-resolved。但无论如何，我认为这是它的错。

相关内容