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 皆連接在同一個共享器（Bridge B）下（同一物理區域）
  • 變更（問題）: 2060 PC 直接接到 Bridge 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 Bridge 是否阻擋廣播。
  • 方法: 在 2060 PC 執行 tcpdump，同時由 Raspi 發送預設指令。
# 2060 PC 終端（接收）
$ sudo tcpdump -ni enp5s0 udp port 9
listening on enp5s0...
#（結果：未捕獲任何封包）
  • 結論: 255.255.255.255 的封包未能穿過 Bridge B 区段。

4. 技術根因 (Root Cause)

本問題源於 廣播範圍（Scope） 與 Bridge 設備的封包轉發策略 的差異。

類型 Limited Broadcast (255.255.255.255) Directed Broadcast (192.168.0.255)
意義 「只到我所在的實體鏈路末端」 「整個使用此 IP 段的網路」
Bridge 行為 被視為本地流量，不會向上層節點轉發 被視為有效的網段流量，會被轉發
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 雖看似全域廣播，實際上屬於 Local（Limited）Broadcast，其傳播範圍受限於物理連接的邊界。 因此在網路被分割（如共享器下的 Bridge）時，使用 指定子網路的目標廣播（192...255） 能更可靠地將封包送達目標機器。