# Informe de resolución de fallos WOL y análisis de red (incluye resultados de pruebas)

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

## 1. Resumen {#sec-d90460152eb8}
**Emisor:** Raspberry Pi 5 (`192.168.0.xxx`)  
 **Receptor:** PC RTX 2060 (`MAC: AB:CD:EF:GH:IJ:KL`, `IP: 192.168.0.xxx`)  
 **Cambio en la topología:**  
  - **Anterior (funcional):** Raspi y PC 2060 conectados al mismo router (puente B) en la misma zona física.  
  - **Actual (problemático):** PC 2060 conectado directamente al router superior (A) del puente B, separando físicamente las zonas.  

 **Síntoma:** El comando WOL por defecto (`255.255.255.255`) ya no enciende el PC.
## 2. Síntomas  {#sec-cd8bf7952942}

**Caso fallido:** `wakeonlan [MAC]` (Broadcast limitado)

  - Destino del envío: `255.255.255.255:9`  
  - Resultado: No hay respuesta del PC 2060.  
 
**Caso exitoso:** `wakeonlan -i 192.168.0.255 [MAC]` (Broadcast dirigido)

  - Destino del envío: `192.168.0.255:9`  
  - Resultado: **PC 2060 se enciende correctamente.**  

## 3. Experimentos y validación  {#sec-7ec2133bb210}

**✅ Experimento 1: Verificar si el Raspi envía paquetes**

- **Objetivo:** Descartar errores a nivel de SO o software en el envío.
- **Método:** Monitorear la interfaz con `tcpdump`.

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

- **Conclusión:** El Raspi genera y lanza paquetes correctamente.

**✅ Experimento 2: Comprobar la llegada de paquetes al PC 2060**

- **Objetivo:** Detectar si el puente TP‑Link bloquea el broadcast.
- **Método:** Ejecutar `tcpdump` en el PC 2060 mientras el Raspi envía el comando por defecto.

```Bash
# Terminal del PC 2060 (escuchando)
$ sudo tcpdump -ni enp5s0 udp port 9
listening on enp5s0...
# (Resultado: no se captura ningún paquete)
```

- **Conclusión:** Los paquetes a `255.255.255.255` no atraviesan el puente B.

## 4. Causa raíz  {#sec-4f5ed2fec746}
image
El problema se origina por la **diferencia de alcance (Scope) del broadcast** y la **política de reenvío del puente**.

| **Tipo** | **Broadcast limitado (255.255.255.255)** | **Broadcast dirigido (192.168.0.255)** |
| -------- | ------------------------------------------ | --------------------------------------- |
| **Significado** | "Solo hasta el extremo de mi enlace físico" | "Toda la red que usa esta subred" |
| **Comportamiento del puente** | Lo trata como tráfico local y no lo pasa al nodo superior. | Lo considera tráfico válido y lo reenvía. |
| **Resultado WOL** | **Fallo de entrega** (bloqueado en el límite de la red) | **Entrega exitosa** (pasa por el router A y llega al PC 2060) |

## 5. Resultado de la solución  {#sec-44b0bd17641a}

- **Método:** Especificar la dirección de broadcast de la subred con la opción `-i 192.168.0.255`.
- **Implementación final:** Añadir un alias en `.bashrc` para mayor comodidad.

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

## 💡 Conclusión final  {#sec-9f6e065a5c79}

`255.255.255.255` es, a diferencia de lo que parece, un **broadcast local o limitado** y no puede superar barreras físicas. En entornos donde la red está segmentada (puentes, routers secundarios, etc.), usar un **broadcast dirigido a una subred específica (`192...255`)** resulta mucho más eficaz y garantiza la entrega del paquete.

------