# Rapport d'incident WOL et analyse réseau (avec résultats d'expérimentation)

![Image d'un camion transportant des paquets entre deux serveurs](/media/whitedec/blog_img/c5334f31e2784b2cb4cb3d038482f194.webp)

## 1. Contexte {#sec-d90460152eb8}

- **Émetteur :** Raspberry Pi 5 (`192.168.0.xxx`)
- **Récepteur :** PC RTX 2060 (`MAC : AB:CD:EF:GH:IJ:KL`, `IP : 192.168.0.xxx`)
- **Modification de l'architecture réseau :**
  - **Avant (fonctionnel) :** Raspi et PC 2060 connectés au même routeur (bridge B) – même zone physique.
  - **Après (problème) :** Le PC 2060 est relié directement au routeur supérieur (A) du bridge B, séparant physiquement les zones.
- **Symptôme :** La commande WOL habituelle (`255.255.255.255`) ne réveille plus le PC.

## 2. Symptômes {#sec-cd8bf7952942}

- **Cas échoué :** `wakeonlan [MAC]` (Limited Broadcast)
  - Destination d'émission : `255.255.255.255:9`
  - Résultat : aucune réponse du PC 2060.
- **Cas réussi :** `wakeonlan -i 192.168.0.255 [MAC]` (Directed Broadcast)
  - Destination d'émission : `192.168.0.255:9`
  - Résultat : **PC 2060 réveillé avec succès.**

## 3. Expérimentations et vérifications {#sec-7ec2133bb210}

**✅ Expérience 1 : Vérifier l'émission de paquets depuis le Raspi**

- **Objectif :** Écarter un problème d'émission au niveau du système d'exploitation ou du logiciel.
- **Méthode :** Surveillance de l'interface avec `tcpdump`.

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

- **Conclusion :** Le Raspi génère correctement le paquet et le transmet sur le réseau.

**✅ Expérience 2 : Vérifier la réception du paquet sur le PC 2060**

- **Objectif :** Déterminer si le bridge TP‑Link bloque la diffusion.
- **Méthode :** Lancer `tcpdump` sur le PC 2060 pendant l'envoi depuis le Raspi.

```bash
# Terminal du PC 2060 (en écoute)
$ sudo tcpdump -ni enp5s0 udp port 9
listening on enp5s0...
# (Résultat : aucun paquet capturé)
```

- **Conclusion :** Les paquets adressés à `255.255.255.255` ne traversent pas le segment du bridge B.

## 4. Cause technique {#sec-4f5ed2fec746}

image
Le problème provient de la **différence de portée (Scope) du broadcast** et de la **politique de transfert des paquets du bridge**.

| **Type** | **Limited Broadcast (255.255.255.255)** | **Directed Broadcast (192.168.0.255)** |
|---|---|---|
| **Signification** | "Jusqu'à la fin du lien physique auquel j'appartiens" | "Tout le réseau qui utilise cette plage d'IP" |
| **Comportement du bridge** | Considéré comme trafic local, ne passe pas au nœud supérieur. | Considéré comme trafic valide, est transmis. |
| **Résultat WOL** | **Échec de la portée** (bloqué à la frontière du réseau) | **Succès de la portée** (passe par le routeur A jusqu'au PC 2060) |

## 5. Résolution {#sec-44b0bd17641a}

- **Solution :** Utiliser l'option `-i 192.168.0.255` pour spécifier l'adresse de broadcast du sous‑réseau.
- **Mise en place finale :** Création d'un alias dans `.bashrc` pour simplifier l'utilisation.

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

## 💡 Conclusion finale {#sec-9f6e065a5c79}

`255.255.255.255` est en réalité un **Limited Broadcast** qui ne peut pas franchir les limites physiques du réseau. Dans les environnements où les segments sont séparés (ex. bridge sous‑router), il est beaucoup plus fiable d’utiliser une **adresse de broadcast ciblée (`192…255`)** pour garantir la livraison du paquet.

------