Неможливо підключитися до wifi Google Starbucks на Ubuntu 17.10

Повідомлення про помилку

Підсумок

Чомусь Ubuntu втрачає трек IP-адреси, пов'язаної з URL-адресою маршрутизатора, який обробляє вхід до маршрутизатора. Я розмістив відповідь, яка вирішує це. Знайдіть 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

Так я і зробив, але результат той самий. Якісь ідеї? Starbucks - єдиний WIFI, до якого я не можу підключитися.

Будь ласка, оновіть нас, якщо ви знаєте, коли Google WIFI / Starbucks вирішив цю проблему.

Я спробував використовувати інший mac-адресу за допомогою macchanger:

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

Однак це не вийшло.

Сьогодні, 18 квітня, я спробував зовсім інший ноутбук, і я все одно отримую ту саму повіску. У повідомленні сказано:

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

Тому поки що для мене нічого не працює. Був у контакті як із підтримкою WIFI Starbucks, так і з їх загальною підтримкою клієнтів, і поки що ніхто не може дати оцінку, коли або якщо колись це буде виправлено. Підтримка Starbucks дала мені цей довідковий номер:

 180413-010073 

Вони сказали зателефонувати в службу підтримки Wi-Fi і дати номер, і вони це виправлять. Коли я зробив підтримку Wi-Fi, вони сказали, що їм номер не потрібний, і вони нічого не можуть зробити. Для компанії, яка виходить із шляху, це забезпечити чудовий досвід клієнтів, це дуже сумно. Минуло більше місяця з тих пір, як вони це розгорнули, і все ще немає виправлень.

При спробі підключення у веб-переглядачі це URL-адреса, на яку переадресовується та зависає https://aruba.odyssys.net/cgi-bin/login.

Оновлення

Також спробував сьогодні використовувати мій MAC-адресу телефону. Це не спрацювало. Wi-Fi Starbucks подумав, що я новий ноутбук, і тому він знову відкрив початкову реєстрацію на сторінці всплеску, але після завершення записів він все ще завис https://aruba.odyssys.net/cgi-bin/login.

Проблема в моєму випадку полягає в тому, що 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 .

Про це говорила служба підтримки Wi-Fi в Google. Відома проблема зі сторінкою сплеску Starbucks, якщо ви зареєстрували більше одного пристрою з однаковою електронною адресою. Перший пристрій, який ви зареєструєте, буде працювати, але не другий. Якщо ви можете використовувати клоновану MAC-адресу на своїй бездротовій карті, ви можете знову потрапити на сторінку реєстрації та скористатися іншою електронною адресою.

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запити).

успіх: 1. змусив мій телефон (андроїд) працювати в Starbucks, заповнивши сторінку входу.

2. знайшла телефонний ПК за допомогою програми Network Info II для Android.

3. вимкнено Wi-Fi у телефоні та на ноутбуці (наприклад, якщо ifconfig wlan0 вниз як root або через sudo)

4. використовується macchanger -m ##: ## ... wlan0 (як root або через sudo) для встановлення андроїд-мак на ноутбуці Linux.

5. підключений ноутбук до Starbucks SSID для підключення ноутбука безпосередньо без сторінки входу

Оскільки це проблема вирішення 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. Але я думаю, що це все-таки є виною.

Я безперешкодно випробував поради, перелічені у всіх інших відповідях. Ось, як я нарешті змусив це працювати:

1. Вимкніть бездротову карту вашого ноутбука.
2. Підключіться до мережі WiFi за допомогою телефону та увійдіть.
3. Використовуйте macchanger, щоб встановити MAC-адресу бездротового інтерфейсу вашого ноутбука на MAC-адресу вашого телефону:

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

4. Увімкніть бездротову карту вашого ноутбука.
5. Підключіться до мережі WiFi через ноутбук. Він підключиться без запиту на вхід, але підключення до Інтернету буде блискучим, поки ви…
6. Відключіться від мережі WiFi на телефоні.

Тепер у вас на комп’ютері повинен бути стабільний Wi-Fi та Інтернет.

Якщо ви пропустите крок 2, мережа виявить підроблено MAC - адреса, але, оскільки ви ще не підключені, він буде вважати вас на повторному вході сторінку замість входу сторінку-обидва з яких не в змозі завантажити правильно. Отже, фокус - спочатку підключитися за допомогою телефону.

Це працювало для мене кілька разів у кількох різних місцях. Я сподіваюся, що це допомагає!