日本で買ったNintendo Switch 2がアメリカのWi-Fiに繋がらなかった話（解決済み）

-

 なかなか気づきにくい、チャンネル帯の問題

日本では大人気のNintendo Switch 2。米国では普通に店頭で買えます
出典: Nintendo US Website




私は幸運にも日本の任天堂本家の初回抽選販売に当選し、発売日に多言語対応版のNintendo Switch 2を入手しておりました。

ちょうど配送時には日本滞在中だったので無事に発売日に受け取り、しばらく日本で楽しく遊んでおりました。ゼルダの伝説 ティアーズオブキングダムのワープやロードがめちゃ速いので快適に遊んでおります。

さて、そんなSwitch 2を米国に住む家族にお披露目すべく今回日本から米国に持ち帰ったのですが、我が家のWi-Fiに繋ごうとしても、なぜか繋がらない。本ポストでは、その顛末を記録しておきたいと思います。


症状：「接続できませんでした。設定を確認してください」となる

接続できない時のエラーメッセージ


※完全に新しいネットワークに繋ごうとする場合、そもそもネットワークの名前が一覧に表示されないと思います。

私の場合、元々Nintendo Switch Liteユーザーで、Switch 2の初期セットアップ時に「お引越し」をしています。このため、おそらくSwitch Liteで使ったことのあるWi-Fiの記録は、Switch 2にデータが移行されたのだろうと思います。

このため、私がつなぎたい自宅のWi-Fiは、Switch 2のネットワーク一覧に表示されていました。ただし、何度パスワードが正しいことを確認しても、上記症状のメッセージが出て接続できません。

パスワードが間違っている場合には「電波環境が悪いか、インターネット設定で入力したパスワードが間違っている可能性があります」となるため、パスワードの問題ではなさそうです。


パスワードが間違っている場合のメッセージ


私は知識として、日本とアメリカでWi-Fi 5Ghz帯において使えるチャンネル帯が違うことを知っていました。なので、ここで原因の仮説として「日本のSwitch 2では対応できないチャンネル帯を私の家のWi-Fiが使っているのではないか？」と思いつきました。検証してみます。

実は我が家には2つのWi-Fiがある

我が家のインターネット回線はComcastというケーブルTVのXfinityというインターネットサービスを利用していて、この会社が提供するケーブルモデム兼Wi-FiルーターのWi-Fiも念のため有効にしてあります。

で、実はSwitch 2はこのComcastのWi-Fiには普通に接続できました。このComcast Wi-Fiのチャンネルを調べてみると、44となっています。

一方、私が独自においているWi-Fiルーターの設定を見てみると、チャンネル157になっていました。
Channelという欄が157になっています




で、Wi-Fi規格の157チャンネルが使える国を調べてみると…Wikipediaによれば、日本は「No」、つまりこのチャンネルは日本では使えない、と記載されています。
Wikipedia 'List of WLAN channels' より


ここまで分かれば自明ですね。日本で購入したSwitch 2は、おそらく日本では使えないチャンネル帯のWi-Fiには接続できないような設定、ないしそのようなハードウェアが使われているのでしょう。

我が家のWi-Fiは別に好んでチャンネル157を選んでいるわけではなく、たまたまそうなっていた、というだけです。もしかしたら先にXfinityが44を使っていたので、そこから周波数帯的に遠い157が自動的に選ばれていただけかもしれません。

チャンネルを157から48に手動で変更し、Wi-Fiルーターを再起動。その後Switch 2から目的のWi-Fiに繋ぎに行ったところ、無事に接続できました。

新しい設定。Channel 48にしました




めでたし、めでたし。


このブログの人気の投稿

ドメイン参加PCで時刻同期先のTime Serverが Local CMOS Clock になってしまった場合の対処方法

-
イメージ
 長らくハマってましたが   ここがLocal CMOS Clockになってしまい、時刻がズレる症状に悩まされ。 会社で使っているWindows PCはほぼすべてActive Directoryに参加させていて、時刻が自動的に同期される設定になるはずなんです。 こちらが正常、というか期待される状態。 一部隠していますが、Time Serverにドメインコントローラーが表示されるのが期待される動作。 調べても w32tm コマンドを使ってゴニョゴニョ したり、 手動でTime Serverをドメコンに指定 させなおしたり、というあたりが引っかかってたんですが、私が遭遇したケースはどちらでも解決せず。 で、ふとこの問題が出るPCのネットワーク設定を見てみたところ、静的IP指定になっているのはいいんですが（これは意図通り）、DNSサーバーがドメコンになっていない。 Ncpa.cpl > ネットワークアダプタを右クリック > Properties > IPv4 > Properties ウチで入れているSD-WANのゲートウェイを向いている。SD-WANにて社外DNSと社内DNSを別々に指定していて、社内DNSの名前解決はちゃんとドメコンに向いているのでDNS的にはこれでも問題なく社内・社外ともに名前解決はできている。 ただ、どうもActive Directoryの動作上はよろしくないようですな。 DNSサーバーにドメコンのIPアドレスを直指定し、しばらく待ったら上記の通りTime Serverにドメコンのうちのひとつが設定され、無事に時刻同期が復活しました。 こんなこともあるんですな。はーやれやれ。 これ、リモートワークとかが進んで、長らくVPNに繋がなかったりすると普通に発生し得るよね。Microsoftさん、何とかしてよ。NTPサーバーは別にドメコンじゃなくても良いでしょうに。
続きを読む

フィットネストラッカーアプリを比較してみた、という話

-
イメージ
意外と差があるもんですね 今回比較するアプリ3種、左からFitbit、Google Fit、Runtastic ちょっと自分の体重…というか腹回りというか首（顔）回りの肉付きが気になってきたので（顔の肉ってどうやって落とすんじゃー！）、多少ムリヤリにでも全体的に脂肪を落とそうと決意。 せっかくですから、楽しみながら、時には目的と手段を意図的に入れ替えながら、ガジェットやらスマホアプリやらで遊んでみよう、と思い立ち、いろいろ調べてみました。 今回はその中から、特に外部ツール無しでも使えるフィットネストラッカーアプリを比較しての考察についてまとめてみます。対象としたのは以下3つのアプリ。「なぜこの3つ？」と聞かれるとあまり考えていないのですが、Fitbit / Google FitはGoogle Playで検索した上位2つ、Runtasticは日本の友人たちが使っていたから、というだけの理由です。 Fitbit - Android版 / iPhone版 基本的には対応リストバンド/デバイスの存在が前提のアプリですが、基本的な機能はそれなしでも使えるようです。セットアップ時にすっ飛ばせます。 Google Fit - Android版 Google謹製のフィットネストラッカーアプリ。Fitbitをはじめ外部デバイスにも対応、もちろんそれらなしでAndroidスマートフォン単体でも十分な機能を使えます。UIがGoogleのMaterial Designベースで、GmailのInboxアプリと似た使い勝手で心地よいです。 Runtastic - Android版 / iPhone版 フィットネストラッカーとしては割と老舗の部類じゃないかと思います。どちらかというと友人たちとの共有や連携が強い印象、一部の機能は有料版のみサポートです。 いきなり比較表 まどろっこしいことは嫌いな私なので、いきなり一覧表に行きます。◎は完璧、○は実用上問題ないけどもう一工夫欲しい、▲はイマイチ、空欄は未対応です。 各アプリの機能比較 2016/03/20時点の最新版をベースに比較しています Fitbit Google...
続きを読む

越境社内DNSでAkamai化が逆効果になる事象を発見した

-
イメージ
まさかこんな影響があるとは思わなかった… サンフランシスコにある私のオフィスから、San Francisco Chronicleという新聞社のWebサイトへのtraceroute結果 ある日のこと、オフィスで仕事をしていて「どうもWebサイトが開くの遅いよな、ウチのオフィス…」とボンヤリ考えていました。 遅いけれども、別に開かないわけじゃない。ちゃんとWebサイトは表示される。でも、画像がちょっとずつ表示されたり（スパっ、と出るのではなく、がっががっ、と出る、と言えば伝わりますでしょうか）、リンクをクリックしてから一瞬、時間にして1.5秒くらいブラウザが考え込んでから次のページのロードが始まったり、といった具合です。 最初は「Wi-Fiが混雑してるんだろうな、どうせ」と思っていましたが、有線LANにしても同じく遅い。これは何かがおかしいぞ、ということで調べてみることにしました。 まずはPingとTracerouteだよね ネットワークエンジニアとしては、PingとTraceroute。最近はPingに応答しないWebサーバーも増えてきているので、インターネット上のHTTPを調べる時はいきなりTracerouteで途中の経路まで調べるのが私の中で常態化しています。 とりあえず遅いと感じたのが、私の地元にある地方紙新聞のSan Francisco Chronicle。さすがに地方紙だから地元にあるだろう、と思ってTracerouteしてみたら…。 その結果が、冒頭にも掲出したコチラ。 私のオフィスからwww.sfchronicle.comにtracerouteした結果（再掲） 異常が出ていること、お分かりでしょうか？ 11ホップ目で、なんと日本のkddi.ne.jpを通っていて、その直前と直後で100ミリ秒（＝0.1秒）のレイテンシ差が出ています。 そして最終到達点はAkamai。最初はなんでこんなことになるのか分からなかったのですが、この画像をFacebookにシェアしたところ、友人の一人から「AkamaiのDNSが日本のサーバーのIPを返している、ということだ」とのご指摘。 このご指摘でピンと来ました。これ、原因はウチの社内DNSです。 どういうことか、というと… セキュリティ的に詳...
続きを読む