WOL障害対応とネットワーク分析レポート（実験結果含む）

2台のサーバ間でパケットを運ぶトラックの画像

1. 概要 (Background)

  • 送信側: Raspberry Pi 5 (192.168.0.xxx)
  • 受信側: RTX 2060 PC (MAC: AB:CD:EF:GH:IJ:KL, IP: 192.168.0.xxx)
  • ネットワーク構成の変更:
  • 従来（正常）: Raspi と 2060 PC が同一のルータ（ブリッジB）に接続（物理的に同一エリア）
  • 変更後（問題）: 2060 PC をブリッジB の上位ルータ（A）へ直接接続し、物理的エリアを分離
  • 症状: 従来使用していたデフォルトの WOL コマンド（255.255.255.255）では PC の電源が立ち上がらない。

2. 障害現象 (Symptoms)

失敗ケース: wakeonlan [MAC]（Limited Broadcast）

  • 送信先: 255.255.255.255:9
  • 結果: 2060 PC が応答せず

成功ケース: wakeonlan -i 192.168.0.255 [MAC]（Directed Broadcast）

  • 送信先: 192.168.0.255:9
  • 結果: 2060 PC の電源が正常にオン

3. 実験と検証 (Experiments)

✅ 実験 1: 送信側（Raspi）でパケットが送出されているか確認

  • 目的: OS やソフトウェアレベルでの送信エラーを除外する
  • 方法: tcpdump でインターフェースをモニタリング
# Raspi ターミナル
$ sudo tcpdump -ni eth0 udp port 9
19:25:35.861285 IP 192.168.0.xxx.52072 > 255.255.255.255.9: UDP, length 102
  • 結論: Raspi はパケットを正常に生成し、ネットワークへ送出していることが確認できた。

✅ 実験 2: 受信側（2060 PC）でパケットが届いているか確認

  • 目的: ネットワーク機器（TP‑Link ブリッジ）がブロードキャストを遮断しているかを確認する
  • 方法: 2060 PC で tcpdump を実行し、Raspi からデフォルトコマンドを送信
# 2060 PC ターミナル（受信待機）
$ sudo tcpdump -ni enp5s0 udp port 9
listening on enp5s0...
# （結果: パケットは一切キャプチャされなかった）
  • 結論: 255.255.255.255 パケットはブリッジB 区間を通過できていない。

4. 技術的原因 (Root Cause)

image 本問題は ブロードキャストのスコープ と ブリッジ機器のパケット転送ポリシー の違いに起因する。

区分 Limited Broadcast (255.255.255.255) Directed Broadcast (192.168.0.255)
意味 "自分が所属する物理リンクの範囲まで" "この IP 範囲全体のネットワーク"
ブリッジの挙動 ローカルトラフィックとみなして上位ノードへ転送しない 有効なネットワークアドレスを持つトラフィックとして転送
WOL 結果 到達失敗（ネットワーク境界で遮断） 到達成功（上位ルータ A 経由で 2060 PC に到達）

5. 対応結果 (Resolution)

  • 解決策: -i 192.168.0.255 オプションでサブネットブロードキャストアドレスを明示指定する
  • 最終適用: .bashrc にエイリアスを登録し、操作性を向上
alias wake2060='wakeonlan -i 192.168.0.255 ab:cd:ef:gh:ij:kl'

💡 最終的な洞察 (Insight)

255.255.255.255 は見た目とは異なり ローカルまたは Limited Broadcast の性質を持ち、物理的な接続範囲を超えることはできない。

したがって、ネットワークが物理的に分離された環境（ルータ下のブリッジなど）でパケットを送信する場合は、 「特定エリアを指定したターゲットブロードキャスト（192...255）」 の方がはるかに効率的かつ確実に届くことが実証された。