Não é possível conectar ao wifi do Google Starbucks no Ubuntu 17.10

Relatório de erro

Sumário

Por alguma razão, o Ubuntu perde o controle do endereço IP associado ao URL do roteador que processa o login no roteador. Eu postei uma resposta que aborda isso. Procure o endereço IP do roteador no telefone e coloque-o /etc/hostssob o nome que está tentando processar o login do roteador. Isso resolveu para mim. Também há outras respostas, caso a configuração do SB seja diferente de onde você está.

Detalhes

Uma postagem que encontrei no meu telefone disse para adicionar o IP do host do serviço de conexão /etc/hosts. O URL exibido na barra de endereço do navegador é:

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

Então eu fiz isso, mas o resultado é o mesmo. Alguma ideia? Starbucks é o único WIFI ao qual não consigo me conectar.

Atualize-nos se você souber quando o Google WIFI / Starbucks resolveu esse problema.

Eu tentei usar um endereço mac diferente usando o macchanger:

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

No entanto, isso não funcionou.

Hoje, 18 de abril, tentei um laptop completamente diferente e continuo tendo o mesmo problema. A mensagem diz:

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

Até agora, nada está funcionando para mim. Estive em contato com o suporte WIFI da Starbucks e com o suporte geral ao cliente e até agora ninguém pode fornecer uma estimativa de quando ou se isso será corrigido. O suporte da Starbucks me deu este número de referência:

 180413-010073 

Eles disseram para ligar para o suporte Wifi e fornecer o número e eles resolverão isso. Quando fiz o Wifi Support, eles disseram que não precisam do número e não há nada que possam fazer. Para uma empresa que se esforça para oferecer ótimas experiências aos clientes, isso é bastante triste. Já faz mais de um mês que eles lançaram isso e ainda não têm solução.

Ao tentar conectar-se a um navegador, esse é o URL para o qual ele redireciona e trava https://aruba.odyssys.net/cgi-bin/login.

Atualizar

Também tentei usar o endereço MAC do meu telefone hoje. Não funcionou. O Starbucks Wifi achou que eu era um laptop novo e, portanto, abriu novamente a inscrição inicial da página inicial, mas depois de concluir as entradas, ele ainda permanece https://aruba.odyssys.net/cgi-bin/login.

O problema no meu caso é que o Ubuntu não sabe como acessar https://aruba.odyssys.net/cgi-bin/login. O host aruba.odyssys.net é o roteador WIFI.

O trabalho ao redor

• Encontre o endereço IP desse roteador e adicione-o /etc/hosts.
• Em algumas situações, talvez você precise adicionar uma linha também /etc/resolv.conf.

Etapas detalhadas

1. Encontre o ip do roteador - em um terminal:

   ip route
   

   (Exemplo de produção: default via 172.31.98.1)

2. Edite o arquivo executando sudo nano /etc/hostspara adicionar a linha:

   172.31.98.1 aruba.odyssys.net
   

3. Opcional? sudo nano /etc/resolv.confpara adicionar a linha antes de outras entradas do servidor de nomes:

   nameserver 172.31.98.1
   

Depois disso, a conexão passa sem problemas.

Relatório de erro

O problema parece ser um relatório de erro: 1766969 .

Falei com o Google Wifi support sobre isso. Há um problema conhecido com a página inicial da Starbucks se você registrar mais de um dispositivo com o mesmo endereço de e-mail. O primeiro dispositivo que você registra funcionará, mas não o segundo. Se você puder usar um endereço MAC clonado na sua placa sem fio, poderá acessar a página de registro novamente e usar um endereço de e-mail diferente.

whoisnão é a ferramenta certa para procurar endereços e, principalmente, lida com nomes de domínio. Para encontrar IPs, use nslookupou digou até 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

( pingconfirmará adicionalmente se o lado está acessível, mas não obter uma resposta também pode significar que o site não responde a pingsolicitações).

sucesso: 1. fiz meu telefone (android) funcionar na Starbucks preenchendo a página de login.

2. encontrou o telefone mac usando o aplicativo Android do Network Info II .

3. desligou o wifi do telefone e do laptop (por exemplo, ifconfig wlan0 para baixo como root ou via sudo)

4. usou o macchanger -m ##: ## ... wlan0 (como root ou via sudo) para definir o mac android no laptop linux.

5. laptop reconectado ao Starbucks SSID para conectar o laptop diretamente, sem página de login

Como esse é um problema de resolução de DNS. Decidi dar uma olhada no que o Ubuntu está fazendo para resolver esse nome:

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

Então, isso falhou e está sendo usado 127.0.0.53como servidor de nomes. Eu verifiquei meu telefone, que foi capaz de se conectar, para o servidor DNS que está usando. Acabou sendo 8.8.8.8seguido por 8.8.4.4, o que faz sentido para uma rede do Google. Com certeza:

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

Isso obviamente funcionou! Então eu editei minha /etc/resolv.confadição

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

E eis que eu consegui me conectar abrindo o firefox e acionando a página de login novamente.

Você foi especificamente instruído a não editar /etc/resolv.confpor systemd-resolved. Mas acho que isso é culpa de qualquer maneira.

Tentei o conselho listado em todas as outras respostas sem sucesso. Aqui está como eu finalmente consegui funcionar:

1. Desative a placa sem fio do seu laptop.
2. Conecte-se à rede Wi-Fi através do seu telefone e faça login.
3. Use o macchanger para definir o endereço MAC da interface sem fio do laptop para o endereço MAC do telefone:

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

4. Habilite a placa sem fio do seu laptop.
5. Conecte-se à rede Wi-Fi através do seu laptop. Ele se conectará sem solicitar o login, mas a conectividade com a Internet ficará com defeito, até que você…
6. Desconecte da rede Wi-Fi do seu telefone.

Agora você deve ter uma conexão WiFi e Internet estável no seu laptop.

Se você pular a Etapa 2, a rede detectará seu endereço MAC falsificado, mas, como você ainda não está conectado, você será direcionado para a página de logon ao invés da página de logon - os quais falham ao carregar corretamente. Portanto, o truque é conectar-se primeiro usando o telefone.

Isso funcionou para mim várias vezes agora em vários locais diferentes. Espero que ajude!