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）無法喚醒電腦。

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）是否有發出封包

  • 目的: 排除作業系統或軟體層面的發送錯誤。
  • 方法: 使用 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)

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

類型 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 雖看似全域廣播，實際上屬於 Local 或 Limited Broadcast，無法跨越實體連接的限制。
因此，在網路被實體分割（如路由器下的橋接）時，使用 指定子網路的目標廣播（192...255） 能夠更有效且可靠地傳遞封包。