Không thể kết nối với wifi Google Starbucks trên Ubuntu 17.10

Báo cáo lỗi

Tóm lược

Vì một số lý do, Ubuntu mất dấu địa chỉ IP được liên kết với URL bộ định tuyến xử lý đăng nhập vào bộ định tuyến. Tôi đã đăng một câu trả lời giải quyết điều này. Tìm địa chỉ IP của bộ định tuyến trên điện thoại của bạn và đặt nó /etc/hostsdưới tên đang cố xử lý đăng nhập bộ định tuyến của bạn. Điều đó đã giải quyết nó cho tôi. Cũng có những câu trả lời khác trong trường hợp thiết lập SB khác với nơi bạn đang ở.

Chi tiết

Một bài đăng tôi tìm thấy trên điện thoại của mình nói sẽ thêm IP máy chủ của dịch vụ kết nối vào /etc/hosts. Các url được hiển thị trong thanh địa chỉ trình duyệt là:

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

Vì vậy, tôi đã làm điều đó, nhưng kết quả là như nhau. Có ý kiến ​​gì không? Starbucks là WIFI duy nhất tôi không thể kết nối.

Vui lòng cập nhật cho chúng tôi nếu bạn biết khi Google WIFI / Starbucks đã khắc phục sự cố này.

Tôi đã thử sử dụng một địa chỉ mac khác bằng macchanger:

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

Tuy nhiên điều đó đã không làm việc.

Hôm nay 18 tháng 4, tôi đã thử một chiếc máy tính xách tay hoàn toàn khác và tôi vẫn bị treo máy. Tin nhắn nói:

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

Cho đến nay không có gì là làm việc cho tôi. Đã tiếp xúc với cả bộ phận hỗ trợ WIFI của Starbucks và bộ phận hỗ trợ khách hàng chung của họ và cho đến nay không ai có thể đưa ra ước tính về thời điểm hoặc nếu điều này sẽ được khắc phục. Bộ phận hỗ trợ của Starbucks đã cho tôi số tham chiếu này:

 180413-010073 

Họ nói sẽ gọi hỗ trợ Wifi và đưa ra số điện thoại và họ sẽ khắc phục điều này. Khi tôi thực hiện Hỗ trợ Wifi, họ nói họ không cần số và họ không thể làm gì. Đối với một công ty vượt ra ngoài cách cung cấp trải nghiệm khách hàng tuyệt vời thì điều này thật đáng buồn. Đã hơn một tháng kể từ khi họ tung ra điều này và vẫn không có cách khắc phục.

Khi cố gắng kết nối trong trình duyệt, đây là url nó chuyển hướng và treo https://aruba.odyssys.net/cgi-bin/login.

Cập nhật

Cũng đã thử sử dụng địa chỉ MAC điện thoại của tôi ngày hôm nay. Nó không hoạt động. Starbucks Wifi nghĩ rằng tôi là một máy tính xách tay mới, và vì vậy nó đã mở đăng ký trang giật gân ban đầu một lần nữa, nhưng sau khi hoàn thành các mục, nó vẫn bị treo https://aruba.odyssys.net/cgi-bin/login.

Vấn đề trong trường hợp của tôi là Ubuntu không biết cách truy cập https://aruba.odyssys.net/cgi-bin/login. Máy chủ aruba.odyssys.net là bộ định tuyến WIFI.

Công việc xung quanh

• Tìm địa chỉ IP của bộ định tuyến đó và thêm nó vào /etc/hosts.
• Trong một số tình huống, bạn có thể cần phải thêm một dòng vào /etc/resolv.conf.

Các bước chi tiết

1. Tìm ip bộ định tuyến - trong một thiết bị đầu cuối chạy:

   ip route
   

   (Ví dụ đầu ra default via 172.31.98.1:)

2. Chỉnh sửa tệp bằng cách chạy sudo nano /etc/hostsđể thêm dòng:

   172.31.98.1 aruba.odyssys.net
   

3. Không bắt buộc? sudo nano /etc/resolv.confđể thêm dòng trước bất kỳ mục nhập máy chủ tên nào khác:

   nameserver 172.31.98.1
   

Sau đó, kết nối đi qua mà không gặp trở ngại.

Báo cáo lỗi

Vấn đề dường như là báo cáo lỗi: 1766969 .

Đã nói với google Wifi hỗ trợ về việc này. Có một vấn đề được biết đến với trang giật gân Starbucks nếu bạn đăng ký nhiều thiết bị có cùng địa chỉ email. Thiết bị đầu tiên bạn đăng ký sẽ hoạt động nhưng không phải thiết bị thứ hai. Nếu bạn có thể sử dụng địa chỉ MAC được nhân bản trên thẻ không dây, bạn có thể truy cập lại trang đăng ký và sử dụng địa chỉ email khác.

whoiskhông phải là công cụ phù hợp để tra cứu địa chỉ và dù sao nó cũng chủ yếu liên quan đến tên miền. Để tìm IP, sử dụng nslookuphoặc dighoặc thậm chí 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

( pingcũng sẽ xác nhận nếu bên đó có thể truy cập được, nhưng không nhận được câu trả lời cũng có thể có nghĩa là trang web không phản hồi pingyêu cầu).

thành công: 1. giúp điện thoại của tôi (android) hoạt động tại Starbucks bằng cách điền vào trang đăng nhập.

2. tìm thấy mac điện thoại bằng cách sử dụng ứng dụng android Network Info II .

3. tắt wifi điện thoại và wifi máy tính xách tay (ví dụ: ifconfig wlan0 xuống dưới dạng root hoặc qua sudo)

4. đã sử dụng macchanger -m ##: ## ... wlan0 (dưới dạng root hoặc qua sudo) để đặt mac android trên máy tính xách tay linux.

5. kết nối lại máy tính xách tay với Starbucks SSID để kết nối máy tính xách tay trực tiếp mà không cần trang đăng nhập

Vì đây là vấn đề giải quyết DNS. Tôi quyết định xem Ubuntu đang làm gì để giải quyết cái tên đó:

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

Vì vậy, thất bại và nó đang sử dụng 127.0.0.53như máy chủ tên. Tôi đã kiểm tra điện thoại của mình, có thể kết nối, cho máy chủ DNS mà nó đang sử dụng. Hóa ra được 8.8.8.8theo sau 8.8.4.4, điều này có ý nghĩa đối với một mạng Google. Đảm bảo đủ:

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

Điều đó rõ ràng đã làm việc! Vì vậy, tôi đã chỉnh sửa /etc/resolv.confthêm

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

Và kìa, tôi đã có thể kết nối bằng cách mở firefox và kích hoạt lại trang đăng nhập.

Bạn được đặc biệt nói không chỉnh sửa /etc/resolv.confbởi systemd-resolved. Nhưng tôi nghĩ đây là lỗi của nó.

Tôi đã thử lời khuyên được liệt kê trong tất cả các câu trả lời khác mà không thành công. Đây là cách cuối cùng tôi đã làm cho nó hoạt động:

1. Vô hiệu hóa thẻ không dây của máy tính xách tay của bạn.
2. Kết nối với mạng WiFi qua điện thoại của bạn và đăng nhập.
3. Sử dụng macchanger để đặt địa chỉ MAC giao diện không dây của máy tính xách tay của bạn thành địa chỉ MAC của bạn:

sudo macchanger -m [your phone's MAC] [your wireless interface]

4. Kích hoạt thẻ không dây của máy tính xách tay của bạn.
5. Kết nối với mạng WiFi thông qua máy tính xách tay của bạn. Nó sẽ kết nối mà không cần đăng nhập, nhưng kết nối internet sẽ bị trục trặc, cho đến khi bạn Học
6. Ngắt kết nối mạng WiFi trên điện thoại của bạn.

Bây giờ bạn sẽ có một kết nối WiFi và internet ổn định trên máy tính xách tay của bạn.

Nếu bạn bỏ qua bước 2, hệ thống mạng sẽ phát hiện địa chỉ MAC giả mạo của bạn, nhưng vì bạn chưa kết nối, nó sẽ đưa bạn đến đăng nhập lại trang thay vì đăng nhập trang-cả hai đều không tải đúng cách. Vì vậy, mẹo đầu tiên là kết nối bằng điện thoại của bạn.

Điều này đã làm việc cho tôi nhiều lần tại một số địa điểm khác nhau. Tôi hy vọng nó sẽ giúp!