こんにちは。現場の第一線でネットワークの設計やインフラ運用に向き合っていると、「Wi-Fiがつながらない」「ローミングがうまくいかない」といったトラブルに直面することがあります。
ブラウザでWeb APIを叩くとき、私たちはついトランスポート層（TCP）やアプリケーション層（HTTP/JSON）の挙動ばかりに目を奪われがちです。しかし、スマートフォンやIoTデバイスが最初に世界へ接続するための「無線区間（Wi-Fi）」では、目に見えない空気を伝って、極めて緻密なMAC層の「会話」が繰り広げられています。
今回は、IEEE 802.11無線LANの根幹を支える「管理フレーム（Management Frames）」の構造と、接続シーケンスのリアルな挙動を、シニアエンジニアの視点から体系的に解説します。パケットキャプチャの画面を頭に思い浮かべながら、一緒に無線LANの深淵を覗いてみましょう。
—
1. 無線LANの「言葉遣い」：MAC層管理フレームの基本構造
有線LAN（イーサネット）の世界では、ケーブルを挿せば物理層のリンクアップを経てすぐにIPの疎通確認（DHCPなど）に入れますが、Wi-Fiは「共有された電波」というカオスな空間です。そのため、通信を始める前に「私はここにいます」「接続させてください」という綿密な挨拶（ネゴシエーション）が不可欠となります。
IEEE 802.11のMACフレームは、大きく分けて以下の3つに分類されます。
1. データフレーム（Data Frames）: 実際のユーザーペイロード（IPパケットなど）を運ぶ。
2. 制御フレーム（Control Frames）: RTS/CTSやACKなど、媒体アクセス制御（CSMA/CA）を補助する。
3. 管理フレーム（Management Frames）: APとステータス（クライアント）間の接続、認証、切断を司る。
今回フォーカスする管理フレームは、MACヘッダーの Frame Control フィールドにおいて、Type が 00（Management）に設定されています。その内側の Subtype によって、ビーコンやアソシエーション要求といった個別の役割が決まります。
一般的な802.11管理フレームの共通ヘッダー構造は以下のようになっています。
+-------------------+-------------------+-------------------+-------------------+
| Frame Control (2B)| Duration/ID (2B) | Address 1 (6B) | Address 2 (6B) |
+-------------------+-------------------+-------------------+-------------------+
| Address 3 (6B) | Sequence Control (2B)| Frame Body (Variable) |
+-------------------+-------------------+-----------------------------------+
| FCS (4B) |
+-------------------+- Address 1: 受信局（RA: Receiver Address）。ブロードキャストの場合は
ff:ff:ff:ff:ff:ff。 - Address 2: 送信局（TA: Transmitter Address）。フレームを送ったデバイスのMACアドレス。
- Address 3: BSSID（基本サービスセット識別子）。多くの場合、無線親機（AP）の無線インターフェースのMACアドレスが入ります。
- Frame Body: ここにビーコンのタイムスタンプや、SSID、サポートレート、セキュリティ情報（RSN情報要素）といった可変長の「情報要素（IE: Information Elements）」が詰め込まれます。
—
2. 接続までのリアルなシーケンス：4つの主要管理フレーム
デバイスがWi-Fiの電波を掴み、IPアドレスを要求できるようになるまでには、以下のステップを踏んだ管理フレームの往来があります。
[クライアント (STA)] [無線親機 (AP)]
| |
|<===== 1. ビーコン (Beacon) ================| (定期ブロードキャスト)
| |
|===== 2. 認証要求 (Authentication Req) ===>|
|<==== 3. 認証応答 (Authentication Resp) ===| (オープンシステム or 共有キー)
| |
|===== 4. アソシエーション要求 (Assoc Req)->|
|<==== 5. アソシエーション応答 (Assoc Resp)-| (AIDの付与)
| |
v (ここから4-WayハンドシェイクやDHCPへ移行) v現場でパケットキャプチャ（Wireshark等）を開いたとき、このシーケンスがどこで途切れているかを確認するのが、トラブルシューティングの第一歩です。それぞれのフレームの中身を詳しく見ていきましょう。
—
① ビーコンフレーム (Beacon Frame)
APが自身の存在を周囲に知らせるために、通常100ms（TUs）おきにブロードキャストし続ける最も基本的な管理フレームです (Subtype: 1000)。
- 主な役割: SSIDの報知、電波の到達確認、サポートしている通信速度の通知、および暗号化方式（WPA2/WPA3など）の提示。
- 重要な情報要素 (IE):
- SSID: ネットワーク名（ステルスAPの場合は空欄になるか、NULL SSIDが入る）。
- Supported Rates: このAPが対応している物理層の変調方式。
- RSN (Robust Security Network) IE: WPA2やWPA3の暗号スイート（CCMPやGCMPなど）の指定。
—
② 認証フレーム (Authentication Frame)
クライアントがAPに対して「あなたのネットワークに参加したい」と最初に意思表示を行うフレームです (Subtype: 1011 / 1100)。
- 実務上の注意点: 現代のWi-Fi（WPA2/WPA3）において、この段階で行われる「認証」は、実は形骸化したオープンシステム認証（Open System Authentication）であることがほとんどです。ここでパスワードの検証が行われるわけではありません。「私はこのAPと通信を試みます」という単なる参加表明であり、実際の暗号化キーのハンドシェイクは、接続確立後の4-Wayハンドシェイク（EAPOLフレーム）で行われます。
—
③ アソシエーション要求 / 応答フレーム (Association Request / Response)
認証をパスした（形式的に受け入れられた）クライアントが、APとの間で論理的な「リンク（Association）」を確立するためのフレームです (Subtype: 0000 for Req, 0001 for Resp)。
- アソシエーション要求: クライアントが「私はこれらの機能（Wi-Fi 6のHE Capabilitiesや、チャンネル幅など）をサポートしています。このSSIDに参加させてください」と要求します。
- アソシエーション応答: APがこれを受け入れ、AID (Association ID)という識別子をクライアントに割り当てます。この応答フレームの
Status Codeが0 (Successful)であれば、無事に無線レイヤーでのリンクアップが完了したことになります。
—
3. 実務でのトラブルシューティング：PythonとScapyによる管理フレームの解析
イン現場で「特定の端末だけがなぜか繋がらない」という現象に遭遇した際、管理フレームの Status Code や理由コード（Reason Code）を確認することはエンジニアの必須スキルです。
例えば、Pythonのパケット操作ライブラリである Scapy を用いると、キャプチャしたpcapファイルから管理フレームのステータスコードをプログラムで集計・解析することができます。以下に、実務のデバッグで役立つスクリプトのサンプルを示します。
from scapy.all import rdpcap, Dot11, Dot11Beacon, Dot11AssoResp
def analyze_management_frames(pcap_file):
"""
pcapファイルから管理フレーム（ビーコンやアソシエーション応答）を読み込み、
APの電波状態や接続拒否のステータスコードを集計・分析するスクリプト。
"""
print(f"[*] 解析対象ファイル: {pcap_file}")
packets = rdpcap(pcap_file)
beacon_count = 0
association_failures = 0
for pkt in packets:
# 802.11レイヤーが存在するか確認
if pkt.haslayer(Dot11):
# ビーコンフレームの検知 (Subtype 8)
if pkt.type == 0 and pkt.subtype == 8:
beacon_count += 1
# SSIDの取得（情報要素から抽出）
ssid = pkt.info.decode('utf-8', errors='ignore') if pkt.info else "<Hidden SSID>"
bssid = pkt.addr3
# 必要に応じてシグナル強度(dBm)を取得 (RadioTapヘッダーが必要)
# dbm_antsignal = pkt.dBm_AntSignal if pkt.haslayer(RadioTap) else "N/A"
# アソシエーション応答フレームの検知 (Subtype 1)
elif pkt.haslayer(Dot11AssoResp):
status_code = pkt.status
if status_code != 0:
association_failures += 1
print(f"[!] 警告: アソシエーション拒否を検知しました。")
print(f" - クライアント: {pkt.addr1}")
print(f" - AP (BSSID): {pkt.addr2}")
print(f" - ステータスコード: {status_code} (0以外は接続失敗を意味します)")
print("\n--- 解析サマリー ---")
print(なf"総ビーコン検出数: {beacon_count}")
print(f"アソシエーション失敗検知数: {association_failures}")
if __name__ == "__main__":
# 実務ではここにキャプチャしたファイルパスを指定します
# 例: analyze_management_frames("wifi_trouble_log.pcap")
print("このスクリプトは、Scapyがインストールされた環境でpcapファイルを読み込んで実行します。")よくあるトラブルのステータスコード（Status Code）
アソシエーション応答や認証応答で返される主なエラーコードには、以下のようなものがあります。インフラ運用の現場でログを見るときに暗記しておくと非常に重宝します。
- Code 1:
Unspecified failure（原因不明のエラー。APの負荷高騰やドライバのバグでよく見られます） - Code 12:
Invalid information element（サポートしていない暗号化方式や、IEの不整合） - Code 17:
Association denied because AP is unable to handle additional associated stations（キャパシティオーバー。APの最大接続台数制限に達している場合）
—
4. シニアエンジニアからの実務Tips
Wi-Fiの設計や運用において、管理フレームの挙動を理解していると、次のような現場のトラブルをスマートに解決できるようになります。
1. プローブ要求のプライバシー問題: クライアントが接続先を探す際に発信する「プローブ要求（Probe Request）」には過去に接続したSSIDの履歴が含まれることがあります。最新の規格（Wi-Fi 7世代や近年のモバイルOS）ではランダムMACアドレスが標準ですが、古いIoTデバイスでは固有MACがダダ漏れになるため、セキュリティ設計上、管理フレームの挙動を把握しておくことがセキュリティ監査の第一歩となります。
2. ローミングの最適化: 端末が別のAPへ移動する際、再アソシエーション（Reassociation）がスムーズに行われない場合、AP側の電波出力（RSSI）のしきい値調整や、802.11k/r/vといったローミング支援プロトコルの有効性を管理フレームのやり取りから逆算してチューニングします。
見えない電波の海も、パケットの構造とフレームの対話を知り尽くせば、確実な論理的裏付けを持ったインフラストラクチャに変わります。日々の運用の片隅で、この記事が皆さんのトラブルシューティングの助けとなれば幸いです。
コメント