Ubuntu 17.10でGoogle Starbucks wifiに接続できません
概要
何らかの理由で、Ubuntuは、ルーターへのログインを処理するルーターURLに関連付けられたIPアドレスの追跡を失います。これに対処する回答を投稿しました。電話機でルーターの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
それで私はそれをしましたが、結果は同じです。何か案は？スターバックスは私が接続できない唯一のWIFIです。
Google WIFI/Starbucksがこの問題を修正した時期をご存知の場合は、更新してください。
私はmacchangerを使用して別のMACアドレスを使用してみました：
Permanent MAC: a0:88:69:15:f0:cc (Intel Corporate)
New MAC: 00:11:22:33:44:55 (CIMSYS Inc)
しかし、それはうまくいきませんでした。
今日4月18日、まったく別のラップトップを試しましたが、まだ同じハングアップが続きます。メッセージは言う：
Error resolving "aruba.odyssys.net": Name or service not known.
これまでのところ、私には何も機能していません。 Starbucks WIFIサポートとその一般的なカスタマーサポートの両方に連絡しており、これまでのところ、これがいつ修正されるかについての見積もりを提供することはできません。スターバックスのサポートは、この参照番号を提供してくれました。
180413-010073
彼らはWifiサポートに電話して番号を伝え、これを修正すると言った。私がWifiサポートをしたとき、彼らは番号を必要とせず、彼らにできることは何もないと言った。優れた顧客体験を提供する方法から抜け出す会社にとって、これは非常に悲しいことです。彼らがこれを展開してからまだ1ヶ月が経ちましたが、まだ修正されていません。
ブラウザで接続しようとすると、これはリダイレクト先のURLであり、https://aruba.odyssys.net/cgi-bin/loginがハングします。
更新
また、今日、私の電話のMACアドレスを使用してみました。うまく行かなかった。 Starbucks Wifiは私が新しいラップトップだと思ったので、最初のスプラッシュページサインアップを再び開きましたが、エントリを完了した後、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にも行を追加する必要があります。
詳細な手順
ルーターの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サポートに話しかけました。同じメールアドレスで複数のデバイスを登録すると、スターバックスのスプラッシュページに既知の問題があります。最初に登録したデバイスは機能しますが、2番目のデバイスは機能しません。ワイヤレスカードで複製されたMACアドレスを使用できる場合は、登録ページに再度アクセスして、別の電子メールアドレスを使用できます。
成功：1.ログインページに入力して、スターバックスでスマートフォン（Android）を動作させました。
Network Info II Android appを使用して電話のmacを見つけました。
電話のwifiとラップトップのwifiをオフにしました（例：ifconfig wlan0 downrootまたはSudo経由）
Android macを設定するためにmacchanger -m ##：## ... wlan0（rootまたはSudo経由）を使用Linuxラップトップ。
ログインページなしでラップトップを直接接続するためにラップトップをStarbucks SSIDに再接続しました
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リクエストに応答しないことも意味します）。
これは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ネットワークに接続します。ログインを要求せずに接続しますが、インターネット接続はグリッチになります。…
- 電話機のWiFiネットワークから切断します。
これで、ラップトップで安定したWiFiとインターネット接続ができるはずです。
ステップ2をスキップすると、ネットワークはスプーフィングされたMACアドレスを検出しますが、まだ接続されていないため、loginではなくreloginページに移動します=ページ-どちらも適切にロードできません。そのため、最初に携帯電話を使用して接続するのがコツです。
これはいくつかの異なる場所で何度も働いてきました。私はそれが役立つことを願っています！