Wake on WAN

[Kyjiep]

Hi, I've just done about six reboots with my ff:ff:ff:ff:ff:ff setup and the permanent MACs are kept to my delight, and the position of the IPs is random in each case, but I'm sorry it doesn't work for you your own proposed solution. When I have time I will describe in more detail the entire procedure that I use so that you can try to reproduce it and see if you have more luck. All the best,

And so, I'm back on the 388.2 release and experimenting.
My experiments show that if there is more than one entry for static ARP assignments in a services-start script, then only one of them dies. And it seems that it does not even depend on which subnet these entries are for.
I added the following to the services-start script:

#!/bin/sh
arp -i br0 -s 192.168.50.253 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.50.254 ff:ff:ff:ff:ff:ff

In the port forwarding menu, I created two rules that differ only in internal IP addresses - 192.168.50.253 and 192.168.50.254. The remaining items in them are the same - this is the service name, external port, internal port (9) and protocol (UDP).
In the WOL application, I entered the router's DDNS domain name, the device's MAC address, and the external port that I specified in the port forwarding rules.
As a result, some time after the router reboots, one of the two static entries in ARP dies, but the second remains alive until the next reboot of the router (waited twice for an hour, and four times for 30 minutes) and if after that I press the button in the WOL application to wake up the device, it will wake up.
But to be sure, I need to observe this for several days.

P.S.:
No luck, the second entry disappeared after an hour and a half (. I'll try to add the entry arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff to them and observe again.

P.P.S.:
Again, failure, after a few hours all records die, except for ? (192.168.1.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 if they are higher than entry ? (192.168.1.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 in the list of static entries output by arp -a |grep PERM. I'm tired of this stupid fuss, we need someone smart to cure the disease, and not try to treat the symptoms. I again returned to 388.2alpha1.

 

[ColinTaylor]

Just curious... can you post the output of the following three commands:

cat /proc/sys/net/ipv4/neigh/default/gc_*
cat /proc/sys/net/ipv4/neigh/br0/gc_*
arp -an | wc -l

For example:

# cat /proc/sys/net/ipv4/neigh/default/gc_*
30
60
128
512
1024
# cat /proc/sys/net/ipv4/neigh/br0/gc_*
60
# arp -an | wc -l
15

 

[Kyjiep]

Just curious... can you post the output of the following three commands:

cat /proc/sys/net/ipv4/neigh/default/gc_*
cat /proc/sys/net/ipv4/neigh/br0/gc_*
arp -an | wc -l

For example:

# cat /proc/sys/net/ipv4/neigh/default/gc_*
30
60
128
512
1024
# cat /proc/sys/net/ipv4/neigh/br0/gc_*
60
# arp -an | wc -l
15

First, I entered these commands on the mobile phone, and the third command returned 7. And then on the PC, the third command returned 8.

After returning to 388.2alpha1, these commands return the same values as on the 388.2 release, except for the third one, which now returns 6.

 

[ColinTaylor]

First, I entered these commands on the mobile phone, and the third command returned 7. And then on the PC, the third command returned 8.

After returning to 388.2alpha1, these commands return the same values as on the 388.2 release, except for the third one, which now returns 6.

Ok thanks. That's fine.

Are you using the AdGuardHome addon script by any chance?

 

[Kyjiep]

Ok thanks. That's fine.

Are you using the AdGuardHome addon script by any chance?

Yes, I am currently using AGH. But before that, I experimented more than once on clean firmware after resetting to factory settings, and the malfunction of static entries in ARP also manifested itself on clean ones, starting from 388.2alpha2, which I already wrote about above. https://www.snbforums.com/threads/wake-on-wan.84737/post-838031

 

[0kk0]

I havent used AGH, and also same issue...

 

[jmat]

La última vez que estuve revisando /etc/dnsmasq.conf y hubo algunas diferencias para la entrada de dhcp de arp manual de wol entre 388.2alpha1 y versiones más nuevas. Los publicaré más tarde cuando esté en casa... En 388.2alpha1 había algo como

dhcp-host=AC:TU:AL:MA:C:X:X",establecer:FF:FF:FF:FF:FF:FF,COMPUTER,192.168.1.254

En versiones posteriores, establece: FF... Se cambia también por la dirección mac real... También algunas otras diferencias. Solo quería comparar cuáles son los cambios entre el trabajo estático arp asuswrt Merlin y las versiones en las que no

Gracias, 0kk0, entre nosotros poco a poco nos vamos acercando al origen del problema, aunque lo que más nos interesa son las implicaciones efectivas y prácticas del tema. Así que estamos a la espera de que detalle más las diferencias entre las nuevas versiones y las anteriores en dnsmasq.conf para ver si se pueden sacar algunas conclusiones. Mis mejores deseos,

Y así, estoy de vuelta en la versión 388.2 y experimentando.
Mis experimentos muestran que si hay más de una entrada para asignaciones ARP estáticas en un script de inicio de servicios, solo una de ellas muere. Y parece que ni siquiera depende de para qué subred son estas entradas.
Agregué lo siguiente al script de inicio de servicios:
[CÓDIGO]#!/bin/sh
arp -i br0 -s 192.168.50.253 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.50.254 ff:ff:ff:ff:ff:ff[/CÓDIGO]
En el menú de reenvío de puertos, creé dos reglas que difieren solo en las direcciones IP internas: 192.168.50.253 y 192.168.50.254 . Los elementos restantes en ellos son los mismos: este es el nombre del servicio, el puerto externo, el puerto interno (9) y el protocolo (UDP).
En la aplicación WOL, ingresé el nombre de dominio DDNS del enrutador, la dirección MAC del dispositivo y el puerto externo que especifiqué en las reglas de reenvío de puertos.
Como resultado, algún tiempo después de que el enrutador se reinicia, una de las dos entradas estáticas en ARP muere, pero la segunda permanece activa hasta el siguiente reinicio del enrutador (se esperó dos veces durante una hora y cuatro veces durante 30 minutos) y si después que presiono el botón en la aplicación WOL para activar el dispositivo, se activará.
Pero para estar seguro, necesito observar esto durante varios días.

PD:
Sin suerte, la segunda entrada desapareció después de una hora y media (. Intentaré agregarles la entrada arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff y observar de nuevo.

ppd:
Nuevamente, falla, después de unas pocas horas, todos los registros mueren, excepto ? (192.168.1.254) en ff:ff:ff:ff:ff:ff [ether] PERM en br0 si son más altos que la entrada ? (192.168.1.254) en ff:ff:ff:ff:ff:ff [ether] PERM en br0 en la lista de entradas estáticas generadas por arp -a |grep PERM . Estoy cansado de este estúpido alboroto, necesitamos a alguien inteligente para curar la enfermedad y no tratar de tratar los síntomas. Volví de nuevo a 388.2alpha1.

And so, I'm back on the 388.2 release and experimenting.
My experiments show that if there is more than one entry for static ARP assignments in a services-start script, then only one of them dies. And it seems that it does not even depend on which subnet these entries are for.
I added the following to the services-start script:

#!/bin/sh
arp -i br0 -s 192.168.50.253 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.50.254 ff:ff:ff:ff:ff:ff

In the port forwarding menu, I created two rules that differ only in internal IP addresses - 192.168.50.253 and 192.168.50.254. The remaining items in them are the same - this is the service name, external port, internal port (9) and protocol (UDP).
In the WOL application, I entered the router's DDNS domain name, the device's MAC address, and the external port that I specified in the port forwarding rules.
As a result, some time after the router reboots, one of the two static entries in ARP dies, but the second remains alive until the next reboot of the router (waited twice for an hour, and four times for 30 minutes) and if after that I press the button in the WOL application to wake up the device, it will wake up.
But to be sure, I need to observe this for several days.

P.S.:
No luck, the second entry disappeared after an hour and a half (. I'll try to add the entry arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff to them and observe again.

P.P.S.:
Again, failure, after a few hours all records die, except for ? (192.168.1.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 if they are higher than entry ? (192.168.1.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 in the list of static entries output by arp -a |grep PERM. I'm tired of this stupid fuss, we need someone smart to cure the disease, and not try to treat the symptoms. I again returned to 388.2alpha1.

Anyway, I am very sorry for the dizziness you are suffering, but I have to say that your procedure is working perfectly for me on an AX86U in version 388.2 of the AX86U router after many tests and reboots. I know that each device and installation is different, but in case it can help, I am going to pass my personal configuration that has been working perfectly for several days until now, and by the way, all the configured records remain in the ARP table:

1. /jffs/scripts/services-start (chmod 777):
#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff

2. /jffs/scripts/wake.sh (chmod 755):
#!/bin/sh

INTERVAL=5
NUMP=1
OLD=""
TARGET=192.168.1.254
TARGET=192.168.10.254
IFACE=br0
MAC=ff:ff:ff:ff:ff:ff
MAC=ff:ff:ff:ff:ff:ff
WOL=/usr/sbin/ether-wake
LOGFILE="/var/log/ether-wake.log"
..................................
..................................

3. Before restarting the router it is important to check that the following settings have not been changed:

* Administration/System/Persistent JFFS2 partition:
-Format JFFS partition at next boot: No
-Enable JFFS custom scripts and configs: Yes

* Firewall/General:
-Logged packets type: Accepted

4. I personally use the router's OpenVPN set to "lan only" before waking up and connecting to any device on the network from outside the lan, as this way we add more security, no need to configure port fowarding on the router and we work as if we were in the local network.

5. On the mobile or pc from outside the lan I connect the OpenVPN application first and then I use a Wake On Lan application to wake up the pcs I need using the broadcast IP 192.168.10.254 with the real MAC of the pc I want to wake up, a WOL port for the Windows firewall and optionally the real IP of the corresponding PC.

Please, I will be happy to answer any questions or clarifications. All the best,

 

[ColinTaylor]

@jmat English only please. It's a forum rule.

 

[jmat]

@jmat English only please. It's a forum rule.

Excuse me, I know, but anyone can make a mistake, right? I'll try to fix it anyway...

 

[Kyjiep]

Gracias, 0kk0, entre nosotros poco a poco nos vamos acercando al origen del problema, aunque lo que más nos interesa son las implicaciones efectivas y prácticas del tema. Así que estamos a la espera de que detalle más las diferencias entre las nuevas versiones y las anteriores en dnsmasq.conf para ver si se pueden sacar algunas conclusiones. Mis mejores deseos,



Anyway, I am very sorry for the dizziness you are suffering, but I have to say that your procedure is working perfectly for me on an AX86U in version 388.2 of the AX86U router after many tests and reboots. I know that each device and installation is different, but in case it can help, I am going to pass my personal configuration that has been working perfectly for several days until now, and by the way, all the configured records remain in the ARP table:

1. /jffs/scripts/services-start (chmod 777):
#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff

2. /jffs/scripts/wake.sh (chmod 755):
#!/bin/sh

INTERVAL=5
NUMP=1
OLD=""
TARGET=192.168.1.254
TARGET=192.168.10.254
IFACE=br0
MAC=ff:ff:ff:ff:ff:ff
MAC=ff:ff:ff:ff:ff:ff
WOL=/usr/sbin/ether-wake
LOGFILE="/var/log/ether-wake.log"
..................................
..................................

3. Before restarting the router it is important to check that the following settings have not been changed:

* Administration/System/Persistent JFFS2 partition:
-Format JFFS partition at next boot: No
-Enable JFFS custom scripts and configs: Yes

* Firewall/General:
-Logged packets type: Accepted

4. I personally use the router's OpenVPN set to "lan only" before waking up and connecting to any device on the network from outside the lan, as this way we add more security, no need to configure port fowarding on the router and we work as if we were in the local network.

5. On the mobile or pc from outside the lan I connect the OpenVPN application first and then I use a Wake On Lan application to wake up the pcs I need using the broadcast IP 192.168.10.254 with the real MAC of the pc I want to wake up, a WOL port for the Windows firewall and optionally the real IP of the corresponding PC.

Please, I will be happy to answer any questions or clarifications. All the best,

Please explain to me what exactly your wake.sh script does. And how does it start? I thought that in order for a script with a custom name to be launched at system startup, the path to it must be entered in the services-start script, for example, as follows:

/jffs/scripts/wake.sh startup

, or is it not necessary?

 

[jmat]

Please explain to me what exactly your wake.sh script does. And how does it start? I thought that in order for a script with a custom name to be launched at system startup, the path to it must be entered in the services-start script, for example, as follows:

/jffs/scripts/wake.sh startup

, or is it not necessary?

Hello, I think I got the scripts and the procedure for Wake on Lan from outside the lan on Asus routers in these forums a few years ago and perhaps a technician from this forum can tell us in detail about the specific function of the file wake.sh. The fact is that in principle services-start and wake.sh have to go in the same folder of the jffs partition, and you must activate them (with Putty, for example) before restarting the router with the following commands:

chmod +x /jffs/scripts/wake.sh
chmod +x /jffs/scripts/services-start

I advise you to use the WinSCP application in Windows to be able to enter the jffs partition of the router with the username and password of the Asus router, although you must first enable SSH in the router's Administration/System. In the event that you do not have the scripts in that folder, there you can create, edit and paste them, the full content of which is given below:

1. services-start:

#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff

2.wake.sh:

#!/bin/sh

INTERVAL=5
NUMP=1
OLD=""
TARGET=192.168.1.254
TARGET=192.168.10.254
IFACE=br0
MAC=ff:ff:ff:ff:ff:ff
MAC=ff:ff:ff:ff:ff:ff
WOL=/usr/sbin/ether-wake
LOGFILE="/var/log/ether-wake.log"

while sleep $INTERVAL;do
NEW=`dmesg | awk '/ACCEPT/ && /DST='"$TARGET"'/ {print }' | tail -1`
SRC=`echo $NEW | awk -F'[=| ]' '/SRC/{for(i=1;i<=NF;i++) if($i ~ /SRC/) print $(i+1)}'`
DPORT=`echo $NEW | awk -F'[=| ]' '/DPT/{for(i=1;i<=NF;i++) if($i ~ /DPT/) print $(i+1)}'`
PROTO=`echo $NEW | awk -F'[=| ]' '/PROTO/{for(i=1;i<=NF;i++) if($i ~ /PROTO/) print $(i+1)}'`

if [ "$NEW" != "" -a "$NEW" != "$OLD" ]; then
if ! ping -qc $NUMP $TARGET >/dev/null; then
# echo "NOWAKE $TARGET was accessed by $SRC, port $DPORT, protocol $PROTO and is already alive at" `date`>> $LOGFILE
#else
echo "WAKE $TARGET requested by $SRC, port $DPORT, protocol $PROTO at" `date`>> $LOGFILE
$WOL -i $IFACE $MAC
sleep 5
fi
OLD=$NEW
fi
donate

In addition, in the "properties" of the scripts you can also check the permission values that they must have: 0777 for services-start and 0755 at least for wake.sh. Then, you already know that after each operation of this type or activation by commands, you have to restart the router. Good luck and hope it works for you...

 

[jmat]

Hello, I think I got the scripts and the procedure for Wake on Lan from outside the lan on Asus routers in these forums a few years ago and perhaps a technician from this forum can tell us in detail about the specific function of the file wake.sh. The fact is that in principle services-start and wake.sh have to go in the same folder of the jffs partition, and you must activate them (with Putty, for example) before restarting the router with the following commands:

chmod +x /jffs/scripts/wake.sh
chmod +x /jffs/scripts/services-start

I advise you to use the WinSCP application in Windows to be able to enter the jffs partition of the router with the username and password of the Asus router, although you must first enable SSH in the router's Administration/System. In the event that you do not have the scripts in that folder, there you can create, edit and paste them, the full content of which is given below:

1. services-start:

#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff

2.wake.sh:

#!/bin/sh

INTERVAL=5
NUMP=1
OLD=""
TARGET=192.168.1.254
TARGET=192.168.10.254
IFACE=br0
MAC=ff:ff:ff:ff:ff:ff
MAC=ff:ff:ff:ff:ff:ff
WOL=/usr/sbin/ether-wake
LOGFILE="/var/log/ether-wake.log"

while sleep $INTERVAL;do
NEW=`dmesg | awk '/ACCEPT/ && /DST='"$TARGET"'/ {print }' | tail -1`
SRC=`echo $NEW | awk -F'[=| ]' '/SRC/{for(i=1;i<=NF;i++) if($i ~ /SRC/) print $(i+1)}'`
DPORT=`echo $NEW | awk -F'[=| ]' '/DPT/{for(i=1;i<=NF;i++) if($i ~ /DPT/) print $(i+1)}'`
PROTO=`echo $NEW | awk -F'[=| ]' '/PROTO/{for(i=1;i<=NF;i++) if($i ~ /PROTO/) print $(i+1)}'`

if [ "$NEW" != "" -a "$NEW" != "$OLD" ]; then
if ! ping -qc $NUMP $TARGET >/dev/null; then
# echo "NOWAKE $TARGET was accessed by $SRC, port $DPORT, protocol $PROTO and is already alive at" `date`>> $LOGFILE
#else
echo "WAKE $TARGET requested by $SRC, port $DPORT, protocol $PROTO at" `date`>> $LOGFILE
$WOL -i $IFACE $MAC
sleep 5
fi
OLD=$NEW
fi
donate

In addition, in the "properties" of the scripts you can also check the permission values that they must have: 0777 for services-start and 0755 at least for wake.sh. Then, you already know that after each operation of this type or activation by commands, you have to restart the router. Good luck and hope it works for you...

I am trying to transfer to the AX58U with version 388.2 the same procedure carried out successfully up to now in the AX86U to check if the permanent MACs are kept in the ARP table. The experiment is carried out under the same conditions already reported for the AX86U, but since in this case it is a 192.168.0.0/24 network, I have respected an order from lowest to highest IP, since I previously tested in reverse order and after some time the permanence of the IP 192:168.0.254 ended up dying. This is the content of the services-start script:

#!/bin/sh
arp -i br0 -s 192.168.0.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff

After a few hours, almost the whole afternoon here in Spain, everything works perfectly, but obviously we have to wait longer and I'll report back tomorrow to confirm that the MACs remain in the ARP table. Good luck and regards,

 

[jmat]

Hello, I think I got the scripts and the procedure for Wake on Lan from outside the lan on Asus routers in these forums a few years ago and perhaps a technician from this forum can tell us in detail about the specific function of the file wake.sh. The fact is that in principle services-start and wake.sh have to go in the same folder of the jffs partition, and you must activate them (with Putty, for example) before restarting the router with the following commands:

chmod +x /jffs/scripts/wake.sh
chmod +x /jffs/scripts/services-start

I advise you to use the WinSCP application in Windows to be able to enter the jffs partition of the router with the username and password of the Asus router, although you must first enable SSH in the router's Administration/System. In the event that you do not have the scripts in that folder, there you can create, edit and paste them, the full content of which is given below:

1. services-start:

#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff

2.wake.sh:

#!/bin/sh

INTERVAL=5
NUMP=1
OLD=""
TARGET=192.168.1.254
TARGET=192.168.10.254
IFACE=br0
MAC=ff:ff:ff:ff:ff:ff
MAC=ff:ff:ff:ff:ff:ff
WOL=/usr/sbin/ether-wake
LOGFILE="/var/log/ether-wake.log"

while sleep $INTERVAL;do
NEW=`dmesg | awk '/ACCEPT/ && /DST='"$TARGET"'/ {print }' | tail -1`
SRC=`echo $NEW | awk -F'[=| ]' '/SRC/{for(i=1;i<=NF;i++) if($i ~ /SRC/) print $(i+1)}'`
DPORT=`echo $NEW | awk -F'[=| ]' '/DPT/{for(i=1;i<=NF;i++) if($i ~ /DPT/) print $(i+1)}'`
PROTO=`echo $NEW | awk -F'[=| ]' '/PROTO/{for(i=1;i<=NF;i++) if($i ~ /PROTO/) print $(i+1)}'`

if [ "$NEW" != "" -a "$NEW" != "$OLD" ]; then
if ! ping -qc $NUMP $TARGET >/dev/null; then
# echo "NOWAKE $TARGET was accessed by $SRC, port $DPORT, protocol $PROTO and is already alive at" `date`>> $LOGFILE
#else
echo "WAKE $TARGET requested by $SRC, port $DPORT, protocol $PROTO at" `date`>> $LOGFILE
$WOL -i $IFACE $MAC
sleep 5
fi
OLD=$NEW
fi
donate

In addition, in the "properties" of the scripts you can also check the permission values that they must have: 0777 for services-start and 0755 at least for wake.sh. Then, you already know that after each operation of this type or activation by commands, you have to restart the router. Good luck and hope it works for you...

Sorry, It looks like we had a goblin asking for money in the last word of the wake.sh script, since obviously the word should be "done" instead of "donate". Just in case, I am attaching the two original files with ".txt" extension added. Regards,

 

[Kyjiep]

Hello, I think I got the scripts and the procedure for Wake on Lan from outside the lan on Asus routers in these forums a few years ago and perhaps a technician from this forum can tell us in detail about the specific function of the file wake.sh. The fact is that in principle services-start and wake.sh have to go in the same folder of the jffs partition, and you must activate them (with Putty, for example) before restarting the router with the following commands:

chmod +x /jffs/scripts/wake.sh
chmod +x /jffs/scripts/services-start

I advise you to use the WinSCP application in Windows to be able to enter the jffs partition of the router with the username and password of the Asus router, although you must first enable SSH in the router's Administration/System. In the event that you do not have the scripts in that folder, there you can create, edit and paste them, the full content of which is given below:

1. services-start:

#!/bin/sh
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff

2.wake.sh:

#!/bin/sh

INTERVAL=5
NUMP=1
OLD=""
TARGET=192.168.1.254
TARGET=192.168.10.254
IFACE=br0
MAC=ff:ff:ff:ff:ff:ff
MAC=ff:ff:ff:ff:ff:ff
WOL=/usr/sbin/ether-wake
LOGFILE="/var/log/ether-wake.log"

while sleep $INTERVAL;do
NEW=`dmesg | awk '/ACCEPT/ && /DST='"$TARGET"'/ {print }' | tail -1`
SRC=`echo $NEW | awk -F'[=| ]' '/SRC/{for(i=1;i<=NF;i++) if($i ~ /SRC/) print $(i+1)}'`
DPORT=`echo $NEW | awk -F'[=| ]' '/DPT/{for(i=1;i<=NF;i++) if($i ~ /DPT/) print $(i+1)}'`
PROTO=`echo $NEW | awk -F'[=| ]' '/PROTO/{for(i=1;i<=NF;i++) if($i ~ /PROTO/) print $(i+1)}'`

if [ "$NEW" != "" -a "$NEW" != "$OLD" ]; then
if ! ping -qc $NUMP $TARGET >/dev/null; then
# echo "NOWAKE $TARGET was accessed by $SRC, port $DPORT, protocol $PROTO and is already alive at" `date`>> $LOGFILE
#else
echo "WAKE $TARGET requested by $SRC, port $DPORT, protocol $PROTO at" `date`>> $LOGFILE
$WOL -i $IFACE $MAC
sleep 5
fi
OLD=$NEW
fi
donate

In addition, in the "properties" of the scripts you can also check the permission values that they must have: 0777 for services-start and 0755 at least for wake.sh. Then, you already know that after each operation of this type or activation by commands, you have to restart the router. Good luck and hope it works for you...

It just seems to me that the wake.sh script, the one that you brought under number 2, simply does not work for you. The chmod +x /jffs/scripts/wake.sh command only gives it execution rights, but this does not run the script itself either after this command or after rebooting the router. That's why I asked how this script is launched and showed a way to make it run automatically after each reboot of the router. That's why I asked what exactly this script does, what effect it gives.
It seems to me that in this script there is a more complex implementation of the same thing that the commands give you
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff
in the services-start script.
The services-start script itself is always automatically launched after the router is rebooted. its name is a system name, and for scripts with a custom name, autorun must be registered in the system ones.
Or am I deeply mistaken?

 

[jmat]

Me parece que el script wake.sh, el que trajiste en el número 2, simplemente no funciona para ti. El comando chmod +x /jffs/scripts/wake.sh solo le otorga derechos de ejecución, pero no ejecuta el script en sí mismo ni después de este comando ni después de reiniciar el enrutador. Es por eso que pregunté cómo se inicia este script y mostré una forma de hacerlo funcionar automáticamente después de cada reinicio del enrutador. Es por eso que pregunté qué hace exactamente este script, qué efecto da. Me parece que este script tiene una implementación más compleja de lo mismo que te dan los comandos
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff
en el script de inicio de servicios.
El script de inicio de servicios siempre se inicia automáticamente después de reiniciar el enrutador. su nombre es un nombre de sistema, y para los scripts con un nombre personalizado, la ejecución automática debe estar registrada en los del sistema.
¿O estoy profundamente equivocado?

It just seems to me that the wake.sh script, the one that you brought under number 2, simply does not work for you. The chmod +x /jffs/scripts/wake.sh command only gives it execution rights, but this does not run the script itself either after this command or after rebooting the router. That's why I asked how this script is launched and showed a way to make it run automatically after each reboot of the router. That's why I asked what exactly this script does, what effect it gives. It seems to me that this script has a more complex implementation of the same thing that the commands give you
arp -i br0 -s 192.168.1.254 ff:ff:ff:ff:ff:ff
arp -i br0 -s 192.168.10.254 ff:ff:ff:ff:ff:ff
in the services-start script.
The services-start script itself is always automatically launched after the router is rebooted. its name is a system name, and for scripts with a custom name, autorun must be registered in the system ones.
Or am I deeply mistaken?

I'm sorry I'm having some problems with the translator. Anyway, regarding what you are telling me, it is possible that it is as you say, and that is why I told you that perhaps a technician could explain it to us a bit. The only thing I can tell you is that, whether that file works or not, the wake on lan function has worked well for me for a few years, and in any case I think it's not bad to leave the file there just in case. The important thing is that it works for you, let's be practical, right? - Regards

 

[Kyjiep]

I'm sorry I'm having some problems with the translator. Anyway, regarding what you are telling me, it is possible that it is as you say, and that is why I told you that perhaps a technician could explain it to us a bit. The only thing I can tell you is that, whether that file works or not, the wake on lan function has worked well for me for a few years, and in any case I think it's not bad to leave the file there just in case. The important thing is that it works for you, let's be practical, right? - Regards

No problem. I also use google translator to write here). I'm glad that this method of fixing a static entry in ARP works for you. Regards.

 

[jmat]

I'm sorry I'm having some problems with the translator. Anyway, regarding what you are telling me, it is possible that it is as you say, and that is why I told you that perhaps a technician could explain it to us a bit. The only thing I can tell you is that, whether that file works or not, the wake on lan function has worked well for me for a few years, and in any case I think it's not bad to leave the file there just in case. The important thing is that it works for you, let's be practical, right? - Regards

Hi, you seem to be right because I have deleted the wake.sh file from my testing installation and nothing has happened, wake on lan is still working fine. So, I thank you for showing me something new and stop doing something useless, hehe...

 

[jmat]

Hi, you seem to be right because I have deleted the wake.sh file from my testing installation and nothing has happened, wake on lan is still working fine. So, I thank you for showing me something new and stop doing something useless, hehe...

Well, we don't know how wake.sh works, but a bit later wake on lan failed on my test installation and I had to put the file back, so I feel a bit more useful for now. That's probably why they call it "Magic Packet", hehe...

 

[Kyjiep]

Well, we don't know how wake.sh works, but a bit later wake on lan failed on my test installation and I had to put the file back, so I feel a bit more useful for now. That's probably why they call it "Magic Packet", hehe...

Well, let's wait, maybe someone who understands scripts more than we do will bring some clarity.

 

[jmat]

Well, let's wait, maybe someone who understands scripts more than we do will bring some clarity.

Hi, I just wanted to confirm that the IPs with permanent MAC addresses configured using our procedure for the AX86U router, and also for the AX58U model, at least in my case, remain active in the ARP table as days go by according to the procedure I have already reported in this forum. This makes the Wake-on-LAN process work perfectly with update 388.2. However, as it seems that this procedure does not work in all cases, we will have to keep an eye on the topic to try to find a solution with more technical foundation and more universal.

On the other hand, I would like to mention that I have found out that the "wake.sh" file is a shell script that listens for requests to access the local network and triggers the Wake-on-LAN action when a request to the target IP address is detected. In summary, the script checks if the destination IP address is alive using the ping command, and if it is not active, it uses the ether-wake command to send the Wake-on-LAN magic packet. Regards,