Не может соединиться с Wi-Fi 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 является единственный WI-FI, с которым я не могу соединиться.
Обновите нас, если Вы знаете, когда 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.
Так себе далеко ничто не работает на меня. На контакте и с поддержкой WI-FI 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.
6 ответов
Проблема в моем случае состоит в том, что Ubuntu не знает, как получить доступ https://aruba.odyssys.net/cgi-bin/login. Хост aruba.odyssys.net маршрутизатор WI-FI.
Работа вокруг
- Найдите IP-адрес того маршрутизатора и добавьте его к
/etc/hosts. - В некоторых ситуациях Вы, возможно, должны были бы также добавить строку к
/etc/resolv.conf.
Подробные шаги
Найдите IP маршрутизатора - в терминале выполненным:
ip route(Пример произвел:
default via 172.31.98.1)Отредактируйте файл путем выполнения
sudo nano /etc/hostsдобавить строку:172.31.98.1 aruba.odyssys.netДополнительный?
sudo nano /etc/resolv.confдобавить строку перед любыми другими записями сервера имен:nameserver 172.31.98.1
После этого соединение проходит без помехи.
Отчет об ошибках
Проблема, кажется, отчет об ошибках: 1766969.
Говорил с поддержкой google Wifi об этом. Существует известная проблема со страницей-заставкой Starbucks при регистрации больше чем одного устройства в том же адресе электронной почты. Первое устройство, которое Вы регистрируете, будет работать, но не второе. Если можно использовать клонированный MAC-адрес на беспроводной карте, можно добраться до регистрационной страницы снова и использовать другой адрес электронной почты.
whois не правильный инструмент к адресам поиска, и он главным образом имеет дело с доменными именами так или иначе. Для нахождения дюйм/с использовать 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 путем заполнения страницы входа в систему.
найденный телефонным Mac при помощи Информации о сети II приложений для Android.
выключенный телефонный Wi-Fi и Wi-Fi ноутбука (например, ifconfig wlan0 вниз как корень или через sudo)
используемый macchanger-m ##:##... wlan0 (как корень или через sudo) для установки андроида Mac на ноутбуке Linux.
повторно подключенный ноутбук в 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. Но я думаю, что это - его отказ так или иначе.
Я попробовал совет, перечисленный во всех других ответах без успеха. Вот то, как я наконец получил его работа:
- Отключите беспроводную карту своего ноутбука.
- Соединитесь с сетью WiFi по своему телефону и регистрируйтесь.
- Используйте macchanger для установки MAC-адреса беспроводного интерфейса ноутбука на MAC-адрес телефона:
sudo macchanger -m [your phone's MAC] [your wireless interface]
- Включите беспроводную карту своего ноутбука.
- Соединитесь с сетью WiFi через свой ноутбук. Это соединится, не запрашивая вход в систему, но интернет-соединение будет glitchy до Вас …
- Отключитесь от сети WiFi по своему телефону.
У Вас должны теперь быть стабильный WiFi и интернет-соединение на Вашем ноутбуке.
При пропуске Шага 2 сеть обнаружит имитировавший MAC-адрес, но, потому что Вы еще не соединены, это возьмет Вас к странице перевхода в систему вместо страницы входа в систему — обоим из которых не удается загрузиться правильно. Так, прием должен сначала соединить использование Вашего телефона.
Это работало на меня несколько раз теперь в нескольких различных местоположениях. Я надеюсь, что это помогает!