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。

詳細な手順

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のようです。

これについてはグーグルWifiサポートに話を聞いた。同じメールアドレスで複数のデバイスを登録すると、スターバックスのスプラッシュページに既知の問題があります。最初に登録したデバイスは機能しますが、2番目のデバイスは機能しません。ワイヤレスカードで複製された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.ログインページに入力して、スターバックスで携帯電話（Android）を動作させました。

2. Network Info II Androidアプリを使用して、電話のMACを見つけました。

3. 電話のwifiとラップトップのwifiをオフにしました（たとえば、ifconfig wlan0をルートとして、またはsudo経由でダウン）

4. 使用さ## ... wlan0：macchanger -m ##のLinuxノートPCでAndroidのMacを設定する（rootまたはsudoを経由して）。

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ネットワークから切断します。

これで、ラップトップで安定したWiFiとインターネット接続ができるはずです。

ステップ2をスキップすると、ネットワークはスプーフィングされたMACアドレスを検出しますが、まだ接続されていないため、ログインの代わりに再ログインページに移動しますページの両方正しくロードに失敗しているの。そのため、最初に携帯電話を使用して接続するのがコツです。

これはいくつかの異なる場所で何度も働いてきました。私はそれが役立つことを願っています！