Actualización:
En aras de la concordia, y ante la insistencia, he estado un rato más a ver si encontraba la especificación, o un estándar, lo cual ha sido infructuoso. Ni la IEEE, ni ISO disponible para consulta.
Sólo hay un whitepaper por parte de AMD, de 1997-1998, con la especificación original en la que sí se contempla tanto que el destino sea la MAC del equipo en suspensión como la de difusión:
Whitepaper Wake-on-LAN(adjunto en este mismo mensaje)
Actualización 2: editado todo aquello que haga referencia a que la MAC de un NIC no es correcta para recibir el paquete.
-----
Conectar es establecer una conexión.
Necesitas establecer una conexión con el servicio encargado de levantar un equipo.
¿Qué es un servicio encargado de levantar un equipo? Aquel que es capaz de enviar una trama ethernet a la MAC de broadcast FF:FF:FF:FF:FF:FF con los datos de broadcast más la MAC del dispositivo a levantar por 16.
Y lo que te está diciendo ap3188, es exactamente eso, que te tienes que establecer una conexión con un servicio en escucha que ejecute el WoL en el dominio de difusión.
Rvilla87 escribió:Te puedo asegurar que yo estando fuera NO me conecto vía VPN ni similar a mi router. Le envío un magic packet al router y el router enciende mi PC.
No te tienes por qué conectar con VPN, es establecer una conexión con el servicio en escucha.
A ver si esta explicación resulta más... clara:
https://superuser.com/questions/889942/ ... it-to-workBasándonos en el funcionamiento de WoL, que configurando tu router con una redirección del puerto 9 a la IP del equipo funcione, no es lo normal.
En el caso de que el router tuviera la IP en su tabla ARP, no enviaría nada a la MAC de broadcast, sino a la MAC de tu equipo,
lo cual, si está bien implementado, para el adaptador de red de tu equipo no significaría nada.
A no ser, como dice la última frase de la respuesta aceptada de ese enlace, que el fabricante de tu NIC tenga una implementación exótica.
Si no tiene la MAC en la tabla ARP, no haría absolutamente nada, salvo preguntar quién tiene esa IP.
Rvilla87 escribió:caja roja escribió:Lo que te está diciendo Dracot en ese párrafo es que si el router tiene que enviar un paquete de capa 3 a un equipo apagado, no puede porque necesitaría una tabla ARP que no tiene.
Lee el párrafo entero y quédate sólo con el segundo párrafo de su mensaje.
Lo que yo entiendo es que Dracot en
el 2º párrafo habla de LAN, donde la tabla ARP no sirve para nada ("
arp no interviene").
Habla de la LAN porque WoL sólo funciona en el mismo dominio de difusión
Aquí tienes otra palabra ambigua como la de conectar. ap3188 decía en la misma red lógica (IPs), Dracot en la misma LAN.
Dominio de difusión. Punto.
Si lees la Wikipedia, también se podría saltar el dominio de difusión, pero no deja de ser lo mismo, pero con un protocolo extra saltando routers.
Rvilla87 escribió:En el último párrafo habla de WAN, donde sí importa la tabla ARP ("si el paquete viene desde fuera, sí que lo va a hacer utilizando la tabla ARP")
¿Por qué dices que me quede con el párrafo 2 si te estoy hablando de Wake on WAN (lo que precisamente habla en su último párrafo)? En este hilo el problema desde un principio es Wake on Wan (levantar desde fuera de la red), el Wake on LAN funciona perfectamente y no ha habido dudas sobre cómo hacerlo funcionar.
Por esto:
"
el Magic Packet tiene una difusión Broadcast a la Mac FF:FF:FF:FF:FF:FF, y un campo con la Mac del equipo a despertar repetida 16 veces ( más un opcional de password que dejamos fuera porque no va a estar utilizando)."
El último párrafo es para decir, después de la explicación, por qué no sirve de nada apuntar a una IP:puerto.
La idea es enviar una trama a la dirección de difusión MAC FF:FF:FF:FF:FF:FF lo cual, salvo que se interprete la conexión y se envíe a difusión, no va a funcionar. Apuntar a una IP, que ya le estás diciendo al router, envíalo a X MAC y si no la conoces, pregunta, no la va a enviar a difusión. El puerto, irrelevante, mientras que la trama se envíe a difusión.
Y no es sólo que no funcione porque el router pierde la tabla ARP, es que no tiene que enviar nada a la MAC del equipo destino siquiera.
Si hay implementaciones exóticas que reconocen el paquete y lo envían a difusión, bien sea mediante configuraciones de router, bien sea por iniciativa propia, bien sea x método, o que el dispositivo de red reconozca la trama, aunque no sea en difusión, es un tema que al final lleva a confusión.
A ti te funciona cuando no debería, por lo menos con los datos que has dado. A otros también, pero no debería.
Rvilla87 escribió:caja roja escribió:Un router, si no tiene un servicio dedicado a levantar equipos, y se configura, no puede levantar equipos, por lo que tener una tabla ARP, aparte que no es necesaria, es totalmente irrelevante.
Aún sigo sin entender cómo afirmas que la tabla ARP es irrelevante cuando varios hemos visto como
cuando en la tabla ARP no tenía la traducción MAC <--> IP_local_PC no funcionaba el Wake on Wan y al informar la tabla ARP ya empezó a funcionar.
Salvo que haya una implementación exótica. Yo no he diseñado el funcionamiento. Es como es. Si a vosotros os funciona, es un caso de estudio el saber cómo está implementado.
No es meramente una cuestión de llevar la contraria, es que es como es. Y dado que no sabemos como está implementado en esos equipos, sólo se puede decir que ese no es su funcionamiento y si os funciona, pues perfecto.
El ejemplo más claro que define la realidad de WoL, o WoL over WAN, como prefieras, es lo que al final ha hecho i3rk (y lo que venía a decir ap3188, usar un intermediario). Ese es el funcionamiento real, y eso que no sabemos la implementación de Alexa.
Rvilla87 escribió:¿Ahora hablas de "un servicio interno, [...], no es accesible desde fuera por defecto" cuando literalmente dijiste "abrir puertos en el router"? Creo que es evidente que cuando dijiste abrir puertos en el router te referías a abrir puertos en el router, no creo que necesite mas explicación porque se está liando de una forma absurda.
Culpa mía si os he interpretado mal, pero me ha parecido entender que decís de abrir puertos, redirigir la conexión al equipo a levantar.
De hecho tú mismo dices que tu configuración se basa en redirigir el tráfico a tu equipo por IP y puerto, lo cual no es necesario.
La cuestión es que, de necesitar abrir puertos, es para que el servicio en escucha que se encargue de levantar equipos reciba la orden. Y eso servicio puede estar en el propio router, puede estar en un NAS, puede estar una Pi, etc.
Vuelvo a lo mismo. Si a algunos os funciona, no sabemos la implementación que hay en vuestros equipos.
Rvilla87 escribió:Insisto que no sé cómo puedes ver incorrecto mi comentario de apertura de puertos cuando tú literalmente dijiste lo mismo (con mas detalle y mas acciones, pero esa en concreta es la que me estás corrigiendo).
Mi mensaje, te lo creas o no, era para corregirte, en mayor medida, porque decías que me parecía que rebatías lo siguiente:
"
Los comandos WOL sólo funcionan desde dispositivos que están en el mismo segmento de red que el dispositivo que quieres despertar"
Luego, según editaba aclaré sobre el ARP.
Dejando de lado la confusión del segmento de red que ya dije, es que esa es la realidad y el funcionamiento de WoL, da igual si se inicia estando tú ya en la red local, o si estás en el bar tomando unas cañas; sólo un equipo con un servicio capaz de levantar otros equipos, y que esté dentro de la red local del equipo a levantar, podrá hacerlo.
Aquí sólo se ha explicado como funciona, qué se necesita para que funcione, por qué no funciona y, bueno, por qué os funcionará a algunos.
Lo demás, a Iker Jiménez
Una nota de humor por dejarlo ya, que hay que dormir.
No le demos más vueltas y no te lo tomes como algo personal. Si ya es por pura semántica dejémoslo correr
![[sati]](/images/smilies/nuevos2/demonio.gif "demoniaco")
). 
