【実務・中級編】 Wi-Fiネットワークにおけるエアチェックとパケットキャプチャ解析（モニターモードとチャンネル固定） – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

夜な夜なオフィスの片隅や自宅のラボで、消えないWi-Fiのパケットロスや、原因不明の「つながりにくい現象」に頭を抱えたことはないでしょうか。

「ルーターの再起動で直ったから良しとしよう」――そんなエンジニアとしての妥協は、今日で終わりにしましょう。現代の無線空間は、あなたが想像している以上に目に見えない電波の衝突と、目まぐるしく変化するリンク速度（MCS）の交差点です。

今回は、Wi-Fiネットワークの深淵を覗き込み、無線空間を飛び交う電波をダイレクトにキャプチャしてトラブルを根本から解決するための実践手法をお届けします。Wiresharkを片手に、空中に浮遊するパケットを捕まえる旅に出発しましょう。

—

1. なぜ「無線パケットキャプチャ」が必要なのか？

有線LAN（Ethernet）であれば、スイッチングハブのポートミラーリング（SPAN）を設定すれば、流れるパケットは手に取るように見えます。しかし、Wi-Fiの世界は共有媒体（Shared Medium）です。空気を媒体として電波が飛び交っているため、通常のOSのネットワークインターフェース（マネージドモード）では、自分宛て以外のフレームや管理フレーム（ビーコンやプローブ要求など）はすべてNICのMAC層でドロップされてしまいます。

ここで登場するのが、ネットワークエンジニアの秘薬「モニターモード（Monitor Mode）」です。

マネージドモード vs モニターモード

  • マネージドモード（通常運用）: 特定のBSSID（アクセスポイント）にアソシエーション（接続）し、自分宛てのデータフレームのみをデコードしてOSに渡す。
  • モニターモード（エアチェック）: APへの接続をせず、特定の無線チャンネルに常駐し、その空気を通過するすべてのIEEE 802.11フレームを無差別かつノーフィルターでキャプチャする。

これを用いることで、例えば「なぜかローミングが頻発する原因はAPの電波出力を上げすぎたことによる隠れ端末問題だった」といった、上位層からは決して見えない真実を暴くことができるのです。

—

2. 実践：Linux環境におけるモニターモードの設定とチャンネル固定

それでは、現場で即座に使える手順を追って解説しましょう。近年のLinuxカーネル（mac80211サブシステム）では、iwコマンドやairmon-ngを使用してクリーンにモニターモードへ移行できます。

ここでは、Intel製やRealtek製の一般的な無線NIC（インターフェース名をwlan0と仮定）を例に進めます。

ステップ1：既存プロセスのキルとインターフェースの状態確認

NetworkManagerやwpa_supplicantがバックグラウンドで動いていると、勝手にチャンネルが切り替わったりスキャンが走ったりして、キャプチャの邪魔になります。まずはこれらを無効化します。

# 既存の無線制御プロセスを停止し、競合を防ぐ
sudo airmon-ng check kill

# 現在の無線インターフェースの状態を確認
iw dev

ステップ2：モニターモードの有効化とチャンネル固定

次に、仮想的なモニターインターフェース（例: wlan0mon）を作成し、ターゲットとなるAPが吹いているチャンネル（例えばWi-Fi 6の5GHz帯であればch 36など）に固定します。

# wlan0をベースにモニターモード用の仮想インターフェースを作成
sudo iw dev wlan0 interface add wlan0mon type monitor

# インターフェースを一旦ダウンさせてからアップする
sudo ip link set wlan0mon down
sudo ip link set wlan0mon up

# キャプチャしたい特定のチャンネル（例: チャンネル 36、帯域幅 20/40/80MHz）に固定
sudo iw dev wlan0mon set channel 36 HT20

ここで重要なのは、「ターゲットがどのチャンネルで通信しているかを事前に調べて固定すること」です。チャンネルを自動ホッピングさせる方法もありますが、特定のトラブルシューティング（ハンドシェイクの瞬間や特定の端末の挙動）においては、チャンネルをガチガチに固定して張り付くのがプロの定石です。

—

3. WiresharkでのキャプチャとRADIOTAPヘッダーの深層解析

準備が整ったら、tsharkやGUI版のWiresharkを起動し、作成したwlan0monを指定してキャプチャを開始します。

# tsharkを使用して、特定のチャンネルのパケットをpcapファイルに保存する例
sudo tshark -i wlan0mon -w capture_result.pcap

Wiresharkを開くと、通常のEthernetフレームとは異なり、各パケットの先頭に「Radiotap Header（ラジオタップ・ヘッダー）」が付与されていることに気づくはずです。

RADIOTAPヘッダーが語る「生データ」の真実

Radiotapは、OSの無線ドライバから上位のキャプチャソフト（Wireshark等）へ、電波の物理的な状態を伝えるメタデータです。ここを見ることで、そのパケットが受信された瞬間のリアルな物理環境が手に取るようにわかります。

Wiresharkのパケット詳細ペインで Radiotap Header を展開すると、以下のようなパラメータが並んでいます。

  • TSFT (Timestamp): パケットがNICのMAC層でヒットした正確なマイクロ秒単位のタイムスタンプ。
  • Flags: プレミアムな情報として、プリアンブルの種類やFCS（フレームチェックシーケンス）のエラー有無が含まれます（Bad FCSのパケットをあえてキャプチャできるように設定することも重要です）。
  • Rate: そのフレームが送信された際の物理レート（例: MCS 9、VHT、HEなど）。
  • Channel / Frequency: 受信時の周波数（MHz）とチャンネル番号。
  • dBm Antenna Signal (RSSI): 受信信号強度。ここが -80 dBm を下回っているのに通信しようとしていれば、それがパケットロスの直接の原因です。

—

4. トラブルシューティングの実践シナリオ：4ウェイハンドシェイクの失敗を暴く

では、現場で遭遇しがちなトラブルを例に、パケット解析のフローを見てみましょう。

課題：特定のクライアントがWPA3/WPA2-PSKの認証（Association）を完了できず、接続ループに陥っている。

1. フィルタリングの適用
Wiresharkのフィルターバーに wlan.sa == AA:BB:CC:DD:EE:FF（対象端末のMACアドレス）を入力し、ノイズを除外します。
2. フレーム種別の確認

  • Association Request と Association Response が正常にやり取りされているか確認します。ここでステータスコードが Successful 以外（例: AP is full や Invalid authentication）になっていれば、認証手前の問題です。

3. 4ウェイハンドシェイク（4-Way Handshake）の追跡
暗号化キーの確立プロセスであるEAPOLフレームに注目します。

  • Message 1 of 4: APからクライアントへ (Nonce送信)
  • Message 2 of 4: クライアントからAPへ (MIC付きレスポンス)
  • Message 3 of 4: APからクライアントへ (Group Key配布)
  • Message 4 of 4: クライアントからAPへ (完了確認)

もし Message 2 が送信されているにもかかわらず Message 3 が返ってこない場合、あるいは Message 3 に対してクライアントが応答しない場合、原因の切り分けが劇的に進みます。パスワード（Pre-Shared Key）の不一致であれば、Message 2 のMIC（Message Integrity Code）検証に失敗してAP側が破棄しています。電波の減衰によるパケットロスであれば、そもそも再送制御（Retry bit）がONになったフレームが空中を飛び交っているのがRadiotapのフラグから読み取れます。

—

5. 次世代Wi-Fi（Wi-Fi 6/6E/7）時代におけるキャプチャの心構え

Wi-Fi 6 (802.11ax) や Wi-Fi 6E (6GHz帯)、そして最新の Wi-Fi 7 (802.11be) では、OFDMAやMU-MIMO、さらには320MHz幅という非常に広いチャンネルボンディングが導入されています。

これに伴い、従来の2.4GHz/5GHz用のUSB Wi-Fiドングルでは、6GHz帯のキャプチャが物理的に不可能であるケースが多々あります。6GHz帯をエアチェックするためには、その帯域をサポートする専用のトライバンドNIC（あるいはIntel Wi-Fi 6E AX210/AX211などを搭載したLinuxマシン）が必須となります。

また、Wi-Fi 7で導入されるMLO（Multi-Link Operation）のトラブルに直面した際は、複数のチャンネルを同時に監視するか、あるいはターゲットとなるマルチリンクデバイスがどのリンク（Band）でハンドシェイクを行っているかを、Radiotapのチャネル情報と照らし合わせて綿密に追跡する必要があります。

—

おわりに

無線LANのトラブルシューティングは、目に見えない電波を相手にするため、一見すると「黒魔術」のように感じられるかもしれません。しかし、今回紹介したモニターモードによるキャプチャと、Radiotapヘッダー、そしてIEEE 802.11のフレーム構造を武器にすれば、すべての挙動は必ず論理的な「ログ（パケット）」として目の前に現れます。

「なんとなく再起動」を卒業し、パケットの囁きに耳を傾けるエンジニアへ。あなたの次の現場でのデバッグが、鮮やかなものになることを願っています。

スポンサーリンク

コメント

タイトルとURLをコピーしました