# WOL-Fehlerbehebung und Netzwerk-Analysebericht (inkl. Testergebnisse)

![2대의 서버간 패킷을 전달하는 트럭 이미지](/media/whitedec/blog_img/c5334f31e2784b2cb4cb3d038482f194.webp)

## 1. Überblick (Background) {#sec-d90460152eb8}

- **Sender:** Raspberry Pi 5 (`192.168.0.xxx`)
- **Empfänger:** RTX 2060 PC (`MAC: AB:CD:EF:GH:IJ:KL`, `IP: 192.168.0.xxx`)
- **Änderung der Netzwerk-Topologie:**
  - **Normal:** Raspi und 2060‑PC waren beide an demselben Router (Bridge B) angeschlossen (physisch im selben Segment).
  - **Problem:** Der 2060‑PC wurde direkt an den übergeordneten Router A angeschlossen, also in ein anderes physisches Segment.
- **Symptom:** Der bisher verwendete Standard‑WOL‑Befehl (`255.255.255.255`) schaltet den PC nicht ein.

## 2. Symptome (Symptoms) {#sec-cd8bf7952942}

- **Fehlgeschlagener Fall:** `wakeonlan [MAC]` (Limited Broadcast)
  - Zieladresse: `255.255.255.255:9`
  - Ergebnis: Keine Reaktion des 2060‑PC.
- **Erfolg:** `wakeonlan -i 192.168.0.255 [MAC]` (Directed Broadcast)
  - Zieladresse: `192.168.0.255:9`
  - Ergebnis: **2060‑PC wird erfolgreich eingeschaltet.**

## 3. Experimente und Verifikation (Experiments) {#sec-7ec2133bb210}

**✅ Experiment 1: Überprüfung, ob der Sender (Raspi) Pakete sendet**

- **Ziel:** Ausschluss von Fehlern auf OS‑ oder Software‑Ebene.
- **Methode:** Netzwerk‑Interface mit `tcpdump` beobachten.

```bash
# Raspi Terminal
$ 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
```

- **Ergebnis:** Der Raspi erzeugt das Paket korrekt und sendet es ins Netzwerk.

**✅ Experiment 2: Prüfen, ob das Paket beim Empfänger (2060‑PC) ankommt**

- **Ziel:** Feststellen, ob das TP‑Link‑Bridge‑Gerät Broadcasts blockiert.
- **Methode:** Auf dem 2060‑PC `tcpdump` laufen lassen, während der Raspi das Standard‑Kommando sendet.

```bash
# 2060 PC Terminal (Listening)
$ sudo tcpdump -ni enp5s0 udp port 9
listening on enp5s0...
# (Ergebnis: Keine Pakete wurden erfasst)
```

- **Ergebnis:** Pakete an `255.255.255.255` passieren die Bridge B nicht.

## 4. Technische Ursache (Root Cause) {#sec-4f5ed2fec746}
image
Das Problem entsteht durch die **Unterschiede im Broadcast‑Scope** und die **Weiterleitungs‑Policy des Bridge‑Geräts**.

| **Typ** | **Limited Broadcast (255.255.255.255)** | **Directed Broadcast (192.168.0.255)** |
|---|---|---|
| **Bedeutung** | "Nur bis zum Ende meines physischen Segments" | "Das gesamte Netzwerk dieses IP‑Bereiches" |
| **Bridge‑Verhalten** | Wird als lokaler Traffic behandelt und nicht nach oben weitergeleitet. | Wird als gültiger Netzwerk‑Broadcast erkannt und weitergeleitet. |
| **WOL‑Ergebnis** | **Nicht erreicht** (Blockierung an der Netzwerkgrenze) | **Erreicht** (Durch Router A zum 2060‑PC) |

## 5. Ergebnis der Maßnahme (Resolution) {#sec-44b0bd17641a}

- **Lösung:** Das Subnetz‑Broadcast‑Adress‑Argument `-i 192.168.0.255` explizit angeben.
- **Dauerhafte Anwendung:** Alias in `.bashrc` hinterlegen.

```bash
alias wake2060='wakeonlan -i 192.168.0.255 ab:cd:ef:gh:ij:kl'
```

## 💡 Abschließende Erkenntnis (Insight) {#sec-9f6e065a5c79}

`255.255.255.255` ist ein **Local/Limited Broadcast** und kann nicht über physische Netzwerkgrenzen hinausgehen. In getrennten Netzwerk‑Umgebungen (z. B. Router‑Bridges) ist daher ein **gerichteter Broadcast (`192…255`)** wesentlich zuverlässiger.

------