この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Cisco Unified Wireless Network(CUWN)ソリューションで発生する相互運用性の問題について説明します。
次の項目に関する知識があることが推奨されます。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
注:このドキュメントの対象読者は、これらのトピックの使用、設定、およびトラブルシューティングにすでに精通している、経験豊富なワイヤレスネットワークエンジニアおよび管理者です。
さまざまなクライアントデバイスが存在し、開発が続いていることを考えると、一般的です。ワイヤレスネットワークへの接続を最大限に活用し、インフラストラクチャをサポートするために、確立、維持、または単純に実行されるさまざまな問題が発生する可能性があります。
これは、クライアントデバイスやワイヤレスインフラストラクチャ自体の単純な設定の問題に起因する場合があります。ただし、場合によっては、特定のクライアントデバイスとそれをサポートするコンポーネント(サプリカント、WLANアダプタ、ワイヤレスドライバなど)、および問題のAPに関する相互運用性の問題が原因である可能性があります。ワイヤレスエンジニアにとって、このような相互運用性の問題は、潜在的に複雑な課題を特定し、トラブルシューティングを行い、解決する機会となります。
このドキュメントでは、Cisco Unified Wireless Network(CUWN)ソリューションでワイヤレスの相互運用性に関する問題が発生した場合、それらの問題を効果的に調査してトラブルシューティングするために最初に収集する必要がある情報について詳しく説明します。無線クライアントデバイスとアクセスポイント(AP)無線の数や組み合わせが増え続けるにつれて、このような包括的なアプローチの必要性がますます高まっています。この記事で概説されている内容に関する追加情報が必要になる場合があります。また、要件を規定する変数が無制限に存在することを考慮すると、収集が必要になる場合もあります。ただし、ここで説明する情報は、ワイヤレスクライアントの相互運用性の潜在的な問題に対処するための一般的なガイドラインです。
解決策を得る目的で問題に効果的にアプローチするための最初のステップは、手元の問題を正確に定義することです。そのためには、少なくとも次の質問を行い、その回答を明確に文書化します。
例外なく、顧客が使用する機能やその特定の設定、およびその他の詳細を詳細にレビューするために、WLCの設定を収集することが絶対的に必要です。これを行うには、対象のWLCへのTelnet/SSHセッションを確立し、次のCLIコマンドの出力をテキストファイルに保存する必要があります。
config paging disable show run-config
完全なrun-config出力が常に優先されます。これは、参加しているAPおよび関連するRF情報に関する詳細情報が出力に含まれているためです。ただし、多数のAPが加入しているWLCを最初に使用した場合(2500以上のAPを使用する8510 WLC)など、状況によって異なります。APの完全なshow run-configが特定のAPの数を完了するのに30分以上かかることがあるため、早く確認するために、そのようなAP情報なしでWLCの設定だけを最初に収集することを推奨する場合があります。ただし、完全なrun-config出力を後で収集する必要がある場合もあります。
これを行うには、オプションでこれらのCLIコマンドの出力をテキストファイルに収集できます。
config paging disable show run-config no-ap show wlan apgroups
show run-configまたはshow run-config no-apの出力に加えて、WLC設定の完全バックアップの収集も推奨されます。これは、ラボの再作成をTAC/HTTSとBUエスカレーションの両方で実行する必要がある場合に、シスコのラボ環境で問題を再現しようとする際に役立ちます。WLCのバックアップは、TFTPまたはFTPを使用してコンフィギュレーションファイルを外部のTFTP/FTPサーバに保存することにより、問題のWLCのGUIまたはCLIを介して収集できます。次の例は、TFTPを使用してWLCのバックアップを保存するためのGUIとCLIの両方の使用方法を示しています。
コマンド>アップロードファイル>設定>アップロード(図を参照)。
transfer upload datatype config
transfer upload mode tftp transfer upload serverip <TFTP-Server_IP-address> transfer upload path / transfer upload filename <desired-filename> transfer upload start
この時点で、必要に応じて追加のレビューを行うために、WLCから現在のログを収集することもできます。理想的には、ワイヤレスクライアントでテストを行った直後にこれらのログを収集して、報告された問題が再現されるようにしたいと考えています。顧客がWLCログを外部syslogサーバにエクスポートする場合は、外部syslogサーバからログを取得する必要があります。それ以外の場合は、このCLIセッション出力を別のテキストファイルに保存することで、現在WLC上でローカルに保存されているmsglogとtrapplogを保存できます。
config paging disable show msglog show traplog
次のステップでは、ワイヤレス相互運用性の問題が発生している可能性がある、使用中のクライアントデバイスに関する情報と詳細を収集します。このような情報には、次の情報が含まれている必要がありますが、必ずしもこれらに限定されるわけではありません。
注:WLAN関連の設定のスクリーンショットなどを含む、クライアントデバイスに関する追加情報または注記も、必要に応じて含める必要があります。
トラブルシューティングの取り組みと根本原因分析(RCA)プロセスをさらに促進するために、ネットワークトポロジの詳細かつ完全なダイアグラムを提供することが常に推奨されます。ネットワークトポロジ図には、ネットワークとワイヤレスインフラストラクチャの詳細を含めるだけでなく、ネットワーク内で動作する問題のワイヤレスデバイス(プリンタ/スキャナ、使用されているクライアントVLANなど)と、相互の相対的な位置に関する情報も含める必要があります。
さまざまなツール(Microsoft Visio、draw.ioなど)やさまざまなスタイルを使用して、このようなネットワークダイアグラムを作成できます。重要な側面は、関係するすべての当事者とベンダーがレビューできるように提供される図に、適切な情報が明確に反映されるようにすることです。図に示すように、インフラストラクチャデバイスとクライアントデバイスの両方に関する基本的だが有用な情報をキャプチャするネットワークトポロジの例。
エンドユーザに問題が発生しているクライアントデバイスでのテスト時に、適切な情報が収集されるようにするため。スプレッドシートなどを事前に作成して、テスト時に観察されたすべてのクライアントの問題と関連する詳細(次の例を参照)を記録しておくことをお勧めします。
MAC アドレス | ユーザ名 | 報告された症状の説明 | エンドユーザが症状を確認した時間 | pingデフォルトゲートウェイY/N | WiFi信号の状態(接続中/接続中) | ipconfig /all (または同等の内容)を記録します。 |
xxyy.aabb.0011 | test_user1(ユーザ名:test_user1) | アクセスポイントからの接続を断続的に切断します。 | AP3からのネットワーク接続と無線の関連付けが失われた。 | N | 接続しています | ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 イーサxx:yy:aa:bb:00:11 inet6 fe80::848:cb8f:881a:4cbf%en0 prefixlen 64保護されたscopeid 0x4 inet 192.168.10.237 netmask 0xffffff00 broadcast 192.168.10.255 nd6オプション=201<PERFORMNUD,DAD> メディア:自動選択 ステータス:アクティブ |
この演習の目的は、共通の関心パターンを文書化して決定し、目の前の問題を正確に把握できるようにすることです。このスプレッドシートをデータ収集に使用する準備ができたら、テストを開始する準備が整います。その他の重要な考慮事項を次に示します。
注:ログとの関連付けを容易にするには、収集されたすべてのデバッグとパケットキャプチャを同じNTPサーバに同期する必要があります。また、任意のテストのために同時に実行する必要があります。
注:問題が発生した時点、および問題が回復したと思われる時点(該当する場合)の正確なタイムスタンプを提供してください。
注:APとWLCの両方で、クライアントのMACアドレスごとにフィルタリングされたデバッグを常に収集します。
注:同じTelnet/SSH/コンソールセッション内のAPでshowコマンドとdebugコマンドを実行しないでください。これらは、状況に応じて異なるセッションで個別に実行されます。
注:コンソールは通常、非常に低速であるため効果的ではないため、コンソールではなくTelnet/SSHでAPデバッグを行うことをお勧めします。
ワイヤレスクライアントの相互運用性の潜在的な問題を再現してトラブルシューティングするためのテストを実施する際には、使用中のワイヤレスインフラストラクチャからデバッグと追加ログを収集することが不可欠です。次の2つのセクションでは、WLCとAPからそれぞれ収集される特定のログと初期デバッグ出力について詳しく説明します。
config sessions timeout 0
debug client <MAC_address> debug dhcp message enable
現在の問題の性質に関して、次のWLCデバッグをケースバイケースで追加することもできます。
問題のワイヤレスクライアントで問題が再現されたら、前後のセクションで概説したすべての情報を収集して文書化します。これらのCLIコマンドを実行するには、WLCでデバッグを無効にする必要があります。
debug disable-all
config paging disable show time show client detail <MAC_address> ping <client_IP-address> <repeat count [1-100]>
前述したように、1つのTelnet/SSHセッションでWLCのデバッグが実行されていることを確認し、別のTelnet/SSHセッションでWLCに対して次のshowコマンドの出力を収集します。同じ手順を実行して、APのデバッグおよび次のセクションで説明するshowコマンドの出力を収集する必要があります。
2600、2700、3700以前のモデルのシスコアクセスポイントなど、テストに関係するLightweight Cisco IOS® APでデバッグを開始する前。クライアントのテスト時に問題のAPへのTelnet/SSH/コンソールセッション時のタイムアウトを回避するには、最初にAPで次のCLIコマンドを実行する必要があります。
debug capwap console cli config t line vty 0 4 exec-timeout 0 session-timeout 0
また、次の手順に従ってコンソール接続を使用し、シリアル/コンソール接続のexecタイムアウトとセッションタイムアウトを適宜無効にするために、代わりにline vty 0 4文をline console 0で置き換えることもできます。
テストを開始する前に、まずAPで次のshowコマンドのサンプルを収集する必要があります。対象のワイヤレスクライアントに関係するテストごとに、少なくとも2回、テストの完了前と完了後のshowコマンドの出力を収集します。
term len 0 show clock show tech show capwap client mn show int do1 dfs show logging more event.log show trace dot11_rst display time format local show trace dot11_rst show trace dot11_bcn display time format local show trace dot11_bcn
前述のshowコマンドの初期出力を収集したら、次に示すように、別のTelnet/SSHセッションの同じアクセスポイントでデバッグを有効にできます。出力全体をテキストファイルに保存します。
debug dot11 {d0|d1} monitor addr <client_MAC-address> debug dot11 {d0|d1} trace print clients mgmt keys rxev txev rcv xmt txfail ba
term mon
フラグ | 説明 |
d0 | 2.4 GHz無線(スロット0) |
d1 | 5 GHz無線(スロット1) |
mgmt | 管理パケットのトレース |
ba | トレースブロックACK情報 |
rcv | 受信パケットのトレース |
キー | トレースセットキー |
拡張 | 受信したイベントのトレース |
第10世代 | 送信イベントのトレース |
トラド | 無線への送信のトレース |
xmt | 送信パケットのトレース |
txfail | 送信エラーのトレース |
評価 | トレースレートの変更 |
テストおよびデータ収集プロセスが完了した後にAPでデバッグを無効にするには、APで次のCLIコマンドを実行します。
u all
802.11ac wave 2対応アクセスポイント以降(1800、2800、3800モデルアクセスポイントなど)向け。これらの新しいモデルのAPでは、AP-COSと呼ばれるアクセスポイントプラットフォーム用のまったく新しいオペレーティングシステムが導入されています。そのため、前述のように、従来のLightweight Cisco IOS®ベースのアクセスポイントで使用されていたすべてのコマンドが、引き続き適用されるわけではありません。さまざまなクライアントSTAデバイスおよびAP-COSモデルAPとの相互運用性の問題をトラブルシューティングする場合、これらの情報は、同等のテストに関与するAP-COSアクセスポイントから収集する必要があります。
テストに関係するAP-COSモデルAPでデバッグを開始する前。クライアントのテスト時に問題のAPへのTelnet/SSH/コンソールセッション時のタイムアウトを回避するには、最初にAPで次のCLIコマンドを実行する必要があります。
exec-timeout 0
テストを開始する前に、まずAPで次のshowコマンドのサンプルを収集する必要があります。対象のワイヤレスクライアントに関係するテストごとに、少なくとも2回、テストの完了前と完了後のshowコマンドの出力を収集します。
term len 0
show clock show tech
show client statistics <client_MAC-address>
show cont nss status
show cont nss stats
show log
これらのデバッグは、18xxシリーズのアクセスポイントに固有のものです。これは、1800シリーズのAPに使用されるチップセットが2800/3800シリーズのアクセスポイントで使用されているものとは異なるためです。このため、このシナリオでは、比較のために異なるデバッグセットが必要です。2800/3800シリーズAPの対応するデバッグについては、次のセクションで説明します。
前述のshowコマンドの初期出力を収集したら、次に示すように、別のTelnet/SSHセッションにある同じ1800アクセスポイントでデバッグを有効にする必要があります。出力全体をテキストファイルに保存します。
debug dot11 client level events addr <client_MAC-address> debug dot11 client level errors addr <client_MAC-address> debug dot11 client level critical addr <client_MAC-address> debug dot11 client level info addr <client_MAC-address> debug dot11 client datapath eapol addr <client_MAC-address> debug dot11 client datapath dhcp addr <client_MAC-address> debug dot11 client datapath arp addr <client_MAC-address>
場合によっては、クライアントの相互運用性の問題をさらにトラブルシューティングするために、18xx APで追加のデバッグを有効にする必要もあります。ただし、この作業は、Cisco TACエンジニアが対応するサービスリクエスト/ケースについてリクエストした場合にのみ行う必要があります。
追加のデバッグの出力が非常に詳細になるだけでなく、APの負荷が増加する可能性もあるため、適切な分析を行うために追加の時間が必要になります。特定の条件下では、多数のクライアントデバイスがテストまたは類似の変数によって同じAPへの接続を試みると、サービスが中断される可能性があります。
テストおよびデータ収集プロセスが完了した後にAP-COSバリアント型アクセスポイント(AP-COS)でのデバッグを無効にするには(1800または2800/3800シリーズAPのいずれでも)、APで次のCLIコマンドを実行できます。
config ap client-trace stop
前述のshowコマンドの初期出力を収集したら、次に示すように、別のTelnet/SSHセッションにある同じ2800/3800アクセスポイントでデバッグを有効にする必要があります。出力全体をテキストファイルに保存します。
config ap client-trace address add <client_MAC-address>
config ap client-trace filter all enable
config ap client-trace output console-log enable
config ap client-trace start
term mon
テストおよびデータ収集プロセスが完了した後に1800/2800/3800シリーズAPでデバッグをディセーブルにするには、APで次のCLIコマンドを実行します。
config ap client-trace stop
使用しているクライアントデバイスがノートブックPCやMacBookなどの場合は、問題の再現に使用しているクライアントデバイスのワイヤレスインターフェイスから混合モードパケットキャプチャを収集する必要があります。Netmon 3.4(Windowsのみ)やWiresharkなどの一般的なユーティリティは、簡単にダウンロードして使用し、このキャプチャを収集して*.pcapファイルに保存できます。デバイスによっては、問題のクライアントからtcpdumpなどを収集する手段もあります。その場合は、クライアントデバイスの製造元に問い合わせて、サポートを受ける必要があります。
MacBook ProでワイヤレスインターフェイスのWiresharkキャプチャを設定する例を次に示します。
パケットキャプチャと同様に、収集に使用するユーティリティに関係なく、ファイルはpcapファイル形式(*.pcap、*.pcapng、*.pkt、...)で保存してください。これは、どの部門のシスコのエンジニアもパケットキャプチャファイルを簡単に表示できるようにするだけでなく、他のベンダーや組織(Intel、Appleなど)のエンジニアも表示できるようにするためです。これにより、よりシームレスな連携とコラボレーションのプロセスが可能になり、シスコとクライアントデバイスベンダーの両方が協力して相互運用性の問題を調査し、解決することがさらに容易になります。
潜在的または既存のワイヤレス相互運用性の問題を効果的にトラブルシューティングするには、問題の高品質なOTAパケットキャプチャを収集することが重要です。これにより、対象のワイヤレスクライアントとアクセスポイント無線間の実際の802.11ワイヤレス通信の詳細な分析が可能になり、さらに、クライアント側とワイヤレスインフラストラクチャのログおよびデバッグの詳細な情報が提供されます。これは、ワイヤレスの相互運用性の潜在的な問題のすべてのテストで例外なく実行する必要がある重要な手順です。
ただし、エンドカスタマーがOTAパケットキャプチャを収集するための設備を適切に備えていなかったり、準備ができていなかったりすることがよくあります。これは、無線エンジニアが直面することの多い共通の障害であり、エンジニアはお客様と協力して、さまざまな方法でこれを克服する必要があります。シスコのサポートフォーラムによるこの記事は、お客様への適切なガイドと教育を行うための出発点として役立ちます。
OTAパケットキャプチャは、pcapファイル形式(*.pcap、*.pcapng、*.pkt、...)で収集され、802.11メタデータ(RSSI、チャネル、データレートなど)を含むことが最も重要です。OTAスニファは、テスト中に常に問題のクライアントデバイスの近くに置き、テスト対象のクライアントデバイスとの間で送受信されるトラフィックの正確な視点を確保する必要があります。
注:問題のテストにクライアントデバイスのローミングのシナリオが含まれている場合、集約パケットキャプチャで複数の802.11チャネルを監視する必要があります。その場合、Fluke NetworksのAirMagnet WiFi Analyzerを使用することは現在お勧めできません。
この理由は、このユーティリティを使用して集約されたパケットキャプチャは現在独自のファイル形式で保存されており、Wiresharkやその他の類似のユーティリティで簡単に表示できるpcap形式の形式では保存されていないためです。OTAパケットキャプチャが独自仕様のファイル形式ではないことを確認します。これにより、関係するすべての当事者とベンダーがキャプチャファイルをいつでも簡単に確認でき、最終的には解決の取り組みを促進できます。
OTAパケットキャプチャを収集する一般的な方法を次に示します。
802.11nワイヤレスクライアントを含むOTAパケットキャプチャでは、現在、より柔軟性と使いやすさが向上しています。これは、OmniPeekなどの多くのツールで簡単に使用できるワイヤレスUSB WLANアダプタの種類が増えたためです。
802.11n OTAキャプチャの収集に使用される特定のワイヤレスアダプタの機能と、トラブルシューティングを試みるクライアントデバイスで使用される実際のWLANチップセットの機能を比較する方法に注意してください。たとえば、クライアントデバイスで、2空間ストリーム(2SS)対応の802.11nチップセットを使用したワイヤレスの相互運用性の問題が発生する可能性がある場合です。次に、OTAパケットキャプチャの収集に使用するワイヤレスアダプタも、802.11n以降の仕様の2SS以上のアダプタにすることを強く推奨します。
3空間ストリーム(3SS)802.11acキャプチャの場合は、2014モデルMacBook Pro以降とMac OS X 10.10.x以降のネイティブスニフィング機能を使用できます。2空間ストリームの802.11acクライアントデバイスをトラブルシューティングする場合は、802.11acキャプチャにMacBook Airを使用することもできます。MacBookのAirモデルでは、このドキュメントの執筆時点では2SS専用のWLANチップセットを使用しています。次に示すシスコサポートフォーラムの記事で、Mac OS Xを使用してOTAパケットキャプチャを収集する方法を参照できます。
Mac OS X 10.6以降を使用したワイヤレススニッフィング
また、2702/2802/3702/3802シリーズまたは同様のAPをスニファモードで使用して、3SSによる適切な802.11acパケットキャプチャを収集することもできます。使用可能な802.11acワイヤレスアダプタの最新リストについては、上記のリソースも参照してください。その一部は、OmniPeekなどの一般的なツールで使用することも、802.11acパケットキャプチャ(Ralink、Atherosなどのチップセット)を収集することもできます。
https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters
また、2702/2802/3702/3802シリーズまたは同様のAPをスニファモードで使用して、3SSによる適切な802.11acパケットキャプチャを収集することもできます。Cisco APをスニファモードで設定してOTAパケットキャプチャを収集する方法の手順は、利便性のために次のCiscoサポートフォーラムの記事で確認できます。
ワイヤレスクライアントデバイスを使用したローミングのシナリオのトラブルシューティングでは、複数のチャネルにまたがるOTAパケットキャプチャを効果的に収集することが一般的な課題です。複数の802.11チャネルを同時に監視するこの方法は、集約されたOTAパケットキャプチャの収集によって実現されます。これを実現するには、互換性のある複数の802.11ac対応USB WLANアダプタと、互換性のあるネットワーク解析ソフトウェアを使用することをお勧めします。一般的な802.11ac対応USB WLANアダプタには、OmniPeek(802.11ac)用のSavvius WiFIアダプタ、Netgear A6210、または同様のものが含まれます。
ここでは、CUWNとの潜在的な無線クライアントの相互運用性の問題を効果的にトラブルシューティングするために収集する必要がある情報の要約を示します。このセクションは、必要に応じてクイックリファレンスセクションとして使用することを目的としています。
問題のWLCのCLIから次の情報を収集します。
または、必要に応じて次の出力だけを収集することもできます。
TFTP、FTPなどのWLC設定のバックアップ(GUI:Commands > Upload File > Configuration)
WLCからのsyslog
注:問題のベンダーにより提供されたデフォルト設定から変更されたクライアントパラメータ。(スリープ状態、ローミングパラメータ、U-APSDなど)
これには、ネットワーク内のワイヤレスデバイス(プリンタ/スキャナ、WLCなど)に関する表現や詳細が含まれます。
以下に例を挙げます。
MAC アドレス | ユーザ名 | 報告された症状の説明 | エンドユーザが症状を確認した時間 | pingデフォルトゲートウェイY/N | WiFi信号の状態(接続中/接続中) | ipconfig /all (または同等の内容)を記録します。 |
この演習の目的は、共通のパターンを特定し、目の前の問題をより正確に把握できるようにすることです。
CLIを使用して、次のWLCデバッグを収集します。
追加のデバッグをケースバイケースで追加します。
CLIを使用して、WLCのshowコマンドの出力を収集します。
テストが完了したら、次のコマンドを使用して、WLCの現在のデバッグをすべて停止します。
このセクションでは、1700/2700/3700シリーズ以前のモデルのアクセスポイントに必要なデバッグについて詳しく説明します。
Telnet/SSH/コンソールセッション時にAPセッションタイムアウトを回避するには、次のコマンドを使用します。
テストを開始する前に、APに関するこれらのshowコマンドの例を収集します。少なくとも、CLIで次のAP showコマンドを使用して、テストの完了前後に、この出力の2つのサンプルを収集します。
CLIを使用して、次のAPデバッグを収集します。
テストが完了したら、次のコマンドを使用してデバッグを無効にします。
このセクションでは、1800/2800/3800シリーズAPに必要なデバッグについて詳しく説明します。
Telnet/SSH/コンソールセッション時にAPセッションタイムアウトを回避するには、次のコマンドを使用します。
テストを開始する前に、APでのshowコマンドの例を収集します。少なくとも、CLIで次のAP showコマンドを使用して、テストの完了前後に、この出力の2つのサンプルを収集します。
1800シリーズアクセスポイントの場合は、CLIを使用して次のAPデバッグを収集します。
2800/3800シリーズアクセスポイントの場合は、CLIで次のAPデバッグを収集します。
テストが完了したら、次のコマンドを使用してデバッグを無効にします。
クライアントデバイスのWLANアダプタから、無差別Netmon 3.4(Windows XPまたは7のみ)またはWiresharkパケットキャプチャを収集します。
C:\Users\engineer>netsh wlan show ? These commands are available: Commands in this context: show all - Shows complete wireless device and networks information. show allowexplicitcreds - Shows the allow shared user credentials settings. show autoconfig - Shows whether the auto configuration logic is enabled or disabled. show blockednetworks - Shows the blocked network display settings. show createalluserprofile - Shows whether everyone is allowed to create all user profiles. show drivers - Shows properties of the wireless LAN drivers on the system. show filters - Shows the allowed and blocked network list. show hostednetwork - Show hosted network properties and status. show interfaces - Shows a list of the wireless LAN interfaces on the system. show networks - Shows a list of networks visible on the system. show onlyUseGPProfilesforAllowedNetworks - Shows the only use GP profiles on GP configured networks setting. show profiles - Shows a list of profiles configured on the system. show settings - Shows the global settings of wireless LAN. show tracing - Shows whether wireless LAN tracing is enabled or disabled.
C:\Users\engineer>netsh wlan show interfaces There are 3 interfaces on the system: Name : Wireless Network Connection 8 Description : WildPackets Conceptronic Nano Wireless 150Mbps USB Adapter #5 GUID : 6beec9b0-9929-4bb4-aef8-0809ce01843e Physical address : c8:d7:19:34:d5:85 State : disconnected Name : Wireless Network Connection 4 Description : WildPackets Conceptronic Nano Wireless 150Mbps USB Adapter GUID : 23aa09d4-c828-4184-965f-4e30f27ba359 Physical address : 48:f8:b3:b7:02:6e State : disconnected Name : Wireless Network Connection Description : Intel(R) Centrino(R) Advanced-N 6200 AGN GUID : 8fa038f8-74e0-4167-98f9-de0943f0096c Physical address : 58:94:6b:3e:a1:d0 State : connected SSID : snowstorm BSSID : 00:3a:9a:e6:28:af Network type : Infrastructure Radio type : 802.11n Authentication : WPA2-Enterprise Cipher : CCMP Connection mode : Profile Channel : 157 Receive rate (Mbps) : 300 Transmit rate (Mbps) : 300 Signal : 80% Profile : snowstorm Hosted network status : Not started
C:\Users\engineer>netsh wlan show networks bssid | more Interface name : Wireless Network Connection There are 21 networks currently visible. SSID 1 : snowstorm Network type : Infrastructure Authentication : WPA2-Enterprise Encryption : CCMP BSSID 1 : 00:3a:9a:e6:28:af Signal : 99% Radio type : 802.11n Channel : 157 Basic rates (Mbps) : 24 39 156 Other rates (Mbps) : 18 19.5 36 48 54 BSSID 2 : 00:3a:9a:e6:28:a0 Signal : 91% Radio type : 802.11n Channel : 6 Basic rates (Mbps) : 1 2 Other rates (Mbps) : 5.5 6 9 11 12 18 24 36 48 54 -- More --
Windows PCでipconfig /allコマンドと同等の出力を収集するには、代わりに、ifconfigの一般的なLinux/Unixコマンドを使用して、Apple MacBook上のすべてのネットワークインターフェイスの詳細情報を一覧表示します。必要に応じて、特定のMacBookのネイティブ無線インターフェイス(モデルに応じてen0またはen1のいずれか)のみの出力を受信するように指定することもできます。次に例を示します。
bash-3.2$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 14:10:9f:de:df:f3 inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4 inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255 nd6 options=1<PERFORMNUD> media: autoselect status: active
MacBook上の現在のワイヤレス接続に関する迅速かつ詳細な情報を取得する。図に示すように、キーボードのoptionボタンを押しながら、デスクトップの右上隅にあるWiFiアイコンを選択することもできます。
もう1つの便利なオプションは、airportという隠しコマンドラインユーティリティを使用することです。独自のMacBookまたはラボ環境で使用しているMacBookでのみ使用することを強くお勧めします。一部のネットワーク管理者は、エンドユーザのMacBookでこのユーティリティへのアクセスを許可したくない場合があるため、適切なレベルの注意を払ってください。続行するには、該当するMacBookのTerminalで次のように入力します。
sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport /usr/local/bin/airport
これで、空港のCLIユーティリティを簡単に呼び出すことができます。次に、その例を示します。
bash-3.2$ airport -I agrCtlRSSI: -61 agrExtRSSI: 0 agrCtlNoise: -90 agrExtNoise: 0 state: running op mode: station lastTxRate: 216 maxRate: 300 lastAssocStatus: 0 802.11 auth: open link auth: wpa2 BSSID: 0:3a:9a:e6:28:af SSID: snowstorm MCS: 13 channel: 157,1
MacBook Proなどの機能を使用して、信頼性の高い単一の802.11チャネルOTAパケットキャプチャを収集するプロセスをさらに簡単にする。macOSの組み込み機能は、Wireless Diagnostics > Snifferメソッドを使用するか、前述のように使用できますが、オプションでAirtoolと呼ばれるサードパーティのユーティリティを使用することもできます(OS X 10.8以降)。利点は、OTAパケットキャプチャをすばやく収集するためのシンプルなインターフェイスです。このキャプチャは、画面の上部メニューバーからアプリUIを数回クリックするだけでデスクトップに直接保存されます。
Airtoolの詳細とダウンロードリンクについては、次のURLを参照してください。
改定 | 発行日 | コメント |
---|---|---|
2.0 |
14-Feb-2023 |
再認定 |
1.0 |
14-May-2016 |
初版 |