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

Question

Relatório de erros

Resumo

Por alguma razão, o Ubuntu perde o rastro do endereço IP associado à URL do roteador que processa o login no roteador. Eu postei uma resposta que aborda isso. Procure o endereço IP do roteador em seu telefone e coloque-o em /etc/hosts sob o nome que está tentando processar o login do seu roteador. Isso resolveu para mim. Existem outras respostas também no caso de a configuração do SB ser diferente onde você está.

Detalhes

Uma postagem que encontrei no meu telefone disse para adicionar o IP do host do serviço de conexão a /etc/hosts . A url exibida 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 Wi-Fi que não consigo conectar.

Por favor, atualize-nos se você sabe quando o Google WIFI / Starbucks corrigiu 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, experimentei um laptop completamente diferente e ainda estou com a mesma tranquilidade. A mensagem diz:

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

Até agora, nada está funcionando para mim. Esteve em contato com o suporte ao Starbucks WIFI e seu suporte geral ao cliente e até o momento 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 dar o número e eles vão consertar isso. Quando eu fiz suporte Wifi disse que eles não precisam do número e não há nada que eles possam fazer. Para uma empresa que sai de sua maneira de proporcionar ótimas experiências para o cliente, isso é muito triste. Já faz mais de um mês desde que eles rolaram e ainda não há conserto.

Ao tentar se conectar em um navegador, essa é a URL para a 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 pensou que eu era um novo laptop, e assim ele abriu a inscrição inicial da página inicial novamente, mas depois de concluir as entradas, ele ainda trava em https://aruba.odyssys.net/cgi-bin/login .

    

Answer 1

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 em torno

• Encontre o endereço IP desse roteador e adicione-o a /etc/hosts .
• Em algumas situações, talvez seja necessário também adicionar uma linha a /etc/resolv.conf .

Etapas detalhadas

1. Encontre o ip do roteador - em uma execução de terminal:

   ip route
   

   (Exemplo de saída: default via 172.31.98.1 )

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

   172.31.98.1 aruba.odyssys.net
   

3. Opcional? sudo nano /etc/resolv.conf para adicionar a linha antes de qualquer outra entrada de servidor de nomes:

   nameserver 172.31.98.1
   

Depois disso, a conexão passa sem problemas.

Relatório de erros

O problema parece ser relatório de erros: 1766969 .

    

Answer 2

Falou para o suporte do google Wifi sobre isso. Existe um problema conhecido na 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ê registrou funcionará, mas não o segundo. Se você puder usar um endereço MAC clonado em sua placa sem fio, poderá acessar a página de registro novamente e usar um endereço de e-mail diferente.

    

Answer 3

whois não é a ferramenta certa para pesquisar endereços, e lida com nomes de domínio de qualquer maneira. Para encontrar IPs, use nslookup ou dig ou mesmo 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 confirmará adicionalmente se o lado está acessível, mas não obter uma resposta também pode significar que o site não responde a ping de solicitações).

    

Answer 4

sucesso: 1. tenho meu telefone (android) trabalhando na Starbucks, preenchendo a página de login.

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

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

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

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

Answer 5

Como este é um problema de resolução de DNS. Eu 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á usando 127.0.0.53 como 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.8 seguido 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 meu /etc/resolv.conf adicionando

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

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

Você recebe instruções específicas para não editar /etc/resolv.conf por systemd-resolved . Mas acho que isso é culpa mesmo.

    

Answer 6

Eu tentei o conselho listado em todas as outras respostas sem sucesso. Aqui está como eu finalmente consegui trabalhar:

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

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

4. Ative o cartão sem fio do seu laptop.
5. Conecte-se à rede Wi-Fi através do seu laptop. Ele se conectará sem solicitar login, mas a conectividade com a Internet será falha, até você…
6. Desconecte-se da rede Wi-Fi no seu telefone.

Agora você deve ter uma conexão Wi-Fi 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, ele levará você para a página relogin em vez do login página - ambos não são carregados corretamente. Então, o truque é primeiro se conectar usando seu telefone.

Isso já funcionou várias vezes em vários locais diferentes. Espero que ajude!