Wake on WAN

[RMerlin]

Asus is currently planning to reverse the change in a future release.

 

[jmat]

Asus is currently planning to reverse the change in a future release.

Thank you, I think it's great news to start the day. Last night I did the 388.2.2 update on AX86U and the permanent arps are maintained with no problem with the method I am using via VPN. Good morning, until another time. All the best,

 

[MilkyOneWay]

Asus is currently planning to reverse the change in a future release.

Thank you very much for the time spent with this problem!

Best Regards

 

[jmat]

Thank you, I think it's great news to start the day. Last night I did the 388.2.2 update on AX86U and the permanent arps are maintained with no problem with the method I am using via VPN. Good morning, until another time. All the best,

PS: Finally, some time after the 388.2_2 update, the permanent macs disappeared again as per the trick found above, so I'm staying on 388.2 until the issue is resolved, hoping it won't take long. All the best,

 

[Kyjiep]

This morning I did a dirty update from 388.2_2 to 388.4 alpha. No problems are observed. And most importantly, the problem with the disappearance of static entries in the ARP has been fixed.

 

[jmat]

This morning I did a dirty update from 388.2_2 to 388.4 alpha. No problems are observed. And most importantly, the problem with the disappearance of static entries in the ARP has been fixed.

Thank you, Kyjiep, for your good news. Up until now, I have been using version 388.1 on both routers, with the solution we found some time ago, as it seemed to be the most stable one for maintaining permanent entries in the ARP (specifically, in my case, the broadcast address) after the usual restarts or various configuration changes on the router. The method I use doesn't require port forwarding on the WAN because I always do it through the OpenVPN of the router itself for security reasons, essentially treating it as a local connection. I will first test it with version 384.4 alpha on the RT-AX58U, and if everything goes well, I will also do it on the RT-AX86U and will come back to report my experience in this same thread. Regards,

 

[0kk0]

This morning I did a dirty update from 388.2_2 to 388.4 alpha. No problems are observed. And most importantly, the problem with the disappearance of static entries in the ARP has been fixed.

Niceee! Thanks for the update!
I was checking it out now and then last few days...
Im gonna update RT-AX86U PRO when merlin fw is available for it

But verrryyy nice to hear!

 

[jmat]

Thank you, Kyjiep, for your good news. Up until now, I have been using version 388.1 on both routers, with the solution we found some time ago, as it seemed to be the most stable one for maintaining permanent entries in the ARP (specifically, in my case, the broadcast address) after the usual restarts or various configuration changes on the router. The method I use doesn't require port forwarding on the WAN because I always do it through the OpenVPN of the router itself for security reasons, essentially treating it as a local connection. I will first test it with version 384.4 alpha on the RT-AX58U, and if everything goes well, I will also do it on the RT-AX86U and will come back to report my experience in this same thread. Regards,

After several days of monitoring the ARP table behavior of the RT-AX58U and RT-AX86U routers with the new firmware version 388.4 alpha 1, it can be said that at least on these routers, permanent ARPs are functioning normally again. Hopefully, the same will occur in the upcoming firmware updates, and we won't have any more scares for this reason. If anyone requires more specific information about this issue, I'll be happy to provide it. Thanks to RMerlin and everyone who contributed to solving this problem. Best regards to all, and until next time.

 

[Kurai]

Hi all. I made an account here specifically to discuss this topic. It seems the general end consensus is that build 388.4 solved this problem and static ARP works properly, but for me on a GT-AXE16000 and build 388.5, it doesn't work. I added a static IP assignment to my PC and that wasn't enough, I had to also add a static ARP entry for it as well. I SSH into the router and modified the servicesstart file to run an ARP command and that will PERM my PC, for a time. It seems after 10 days, the router will quickly begun flushing the flagged ARP entry and I have to either reboot the router or rerun the command through SSH. What's going on here? Is it back in 388.5? Is the GT-AXE16000 unaffected by the 388.4 fix? Why am I having this problem? It's really frustrating.

 

[jmat]

Hi all. I made an account here specifically to discuss this topic. It seems the general end consensus is that build 388.4 solved this problem and static ARP works properly, but for me on a GT-AXE16000 and build 388.5, it doesn't work. I added a static IP assignment to my PC and that wasn't enough, I had to also add a static ARP entry for it as well. I SSH into the router and modified the servicesstart file to run an ARP command and that will PERM my PC, for a time. It seems after 10 days, the router will quickly begun flushing the flagged ARP entry and I have to either reboot the router or rerun the command through SSH. What's going on here? Is it back in 388.5? Is the GT-AXE16000 unaffected by the 388.4 fix? Why am I having this problem? It's really frustrating.

Hello, Kurai, I would just like to tell you in case this helps, that with version 3004.388.5 on the RT-AX58U and RT-AX86U routers the command in the "services-start" file: arp -i br0 -s 192.168.xx. 254 ff:ff:ff:ff:ff:ff, executed as: chmod +x /jffs/scripts/services-start, and with the same IP and MAC entered in the "wake.sh" file, executed as: chmod + x /jffs/scripts/wake.sh, continues to maintain a PERMANENT ARP after the issue is resolved in version 3004.388.4. Later, in the "Wake on Lan/Wan" mobile application I replace the MAC ff:ff:ff:ff:ff:ff with the specific MAC of the PC I want to wake up and everything works perfectly. I would also like to tell you that personally for security reasons I do not open any ports on the router, since both the "Wake on Lan" and the "RDP" are always used through an OpenVPN connection created on the Asus router itself. Alternatively, instead of using "Wake on Lan/Wan" to wake up the PCs, you can use the Asus router application through the "Network Tools" option, an application that I also use through the same OpenVPN connection. It is possible that in some cases, such as after updating the router firmware, you will have to re-execute the commands and reboot. Hopefully this procedure, if you were not already using it, resolves your case. Otherwise, you should focus on resolving the issue as a specific problem with your own GT-AXE16000 router. I will be happy to clarify anything you need. Good luck and greetings...

 

[jmat]

Hi all. I made an account here specifically to discuss this topic. It seems the general end consensus is that build 388.4 solved this problem and static ARP works properly, but for me on a GT-AXE16000 and build 388.5, it doesn't work. I added a static IP assignment to my PC and that wasn't enough, I had to also add a static ARP entry for it as well. I SSH into the router and modified the servicesstart file to run an ARP command and that will PERM my PC, for a time. It seems after 10 days, the router will quickly begun flushing the flagged ARP entry and I have to either reboot the router or rerun the command through SSH. What's going on here? Is it back in 388.5? Is the GT-AXE16000 unaffected by the 388.4 fix? Why am I having this problem? It's really frustrating.

Just in case, if you are using Asus DDNS in Wake on Lan or OpenVPN, also check that everything is correct after any firmware update. In the "Forced update interval (in days)" option I usually indicate "1" and then apply to prevent the www.asus.com server from taking a long time to replicate any IP change.

 

[Kurai]

Thanks for the replies jmat. My current method is to modify services-start file with basically the same arp command you suggested. It works for about 10 days, then the ARP entry gets deleted (presumably by the Network Map service as Merlin found above in the thread) and then if I rerun the command through SSH, that entry will get removed usually within 24 hours or less. I tried setting up a cron job to run every 30 minutes to rerun the ARP command, but this caused my router to lag out tremendously. I typically get 940/940 mbps on my WAN connection, but after a day or so of running that cron job every 30 minutes, the router gets bogged down to 400/400, and another day later it could be as low as 80/80. Rebooting the router solves it. Because of this, I am extremely hesitant to ever setup any more cron jobs on the router and would greatly prefer a clean, native code solution that doesn't require such a method. I am currently investigating using a VPN running on the router and seeing if I can still wake the PC without the perm'd ARP entry by sending the magic packet to the broadcast IP over VPN. If that works, then whatever I'll just use that method. But I would really like to know why my ARP perm entries are getting cleared from the cache even on a supposedly fixed firmware.

 

[jmat]

Thanks for the replies jmat. My current method is to modify services-start file with basically the same arp command you suggested. It works for about 10 days, then the ARP entry gets deleted (presumably by the Network Map service as Merlin found above in the thread) and then if I rerun the command through SSH, that entry will get removed usually within 24 hours or less. I tried setting up a cron job to run every 30 minutes to rerun the ARP command, but this caused my router to lag out tremendously. I typically get 940/940 mbps on my WAN connection, but after a day or so of running that cron job every 30 minutes, the router gets bogged down to 400/400, and another day later it could be as low as 80/80. Rebooting the router solves it. Because of this, I am extremely hesitant to ever setup any more cron jobs on the router and would greatly prefer a clean, native code solution that doesn't require such a method. I am currently investigating using a VPN running on the router and seeing if I can still wake the PC without the perm'd ARP entry by sending the magic packet to the broadcast IP over VPN. If that works, then whatever I'll just use that method. But I would really like to know why my ARP perm entries are getting cleared from the cache even on a supposedly fixed firmware.

As an alternative solution, I seem to remember that if you use a VPN from the Asus router to connect to the Asus application on your mobile, Wake on Lan DOES work through Network Tools simply using the "specific MAC" of the PC/PCs you want to boot without this MAC being registered as permanent in the ARP list. In any case, good luck and in the meantime let's hope that someone can give you some clue to solve the problem with the permanent MAC on the GT-AXE16000 router...

 

[Deetlemore]

I think this would fit here, rather than starting a new thread. I have WoWLAN enabled on my PC, using an Asus PCE-AX58BT (essentially a PCI-E carrier board that uses an Intel AX210). I'm running an AX86U Pro with Merlin firmware 3004.388.6.

Long story short, I have WoWLAN working reliably, but my PC will also wake up every time an arp request is sent out. I figured a static arp entry along with a cron job that runs once a day to re-enter that entry may be my solution, but I'm still a nocive with scripting. Does this look correct to you guys? This is my services-start:

#!/bin/sh

/jffs/scripts/scmerlin startup & # scMerlin

nvram set wl0.3_ap_isolate=0
nvram commit
service restart_wireless

arp -i br0 -s 192.168.XXX.7 F4:XX:XX:XX:XX:XX

cru a staticarp "0 10 * * * arp -i br0 -s 192.168.XXX.7 F4:XX:XX:XX:XX:XX"

 

[jmat]

I think this would fit here, rather than starting a new thread. I have WoWLAN enabled on my PC, using an Asus PCE-AX58BT (essentially a PCI-E carrier board that uses an Intel AX210). I'm running an AX86U Pro with Merlin firmware 3004.388.6.

Long story short, I have WoWLAN working reliably, but my PC will also wake up every time an arp request is sent out. I figured a static arp entry along with a cron job that runs once a day to re-enter that entry may be my solution, but I'm still a nocive with scripting. Does this look correct to you guys? This is my services-start:

#!/bin/sh

/jffs/scripts/scmerlin startup & # scMerlin

nvram set wl0.3_ap_isolate=0
nvram commit
service restart_wireless

arp -i br0 -s 192.168.XXX.7 F4:XX:XX:XX:XX:XX

cru a staticarp "0 10 * * * arp -i br0 -s 192.168.XXX.7 F4:XX:XX:XX:XX:XX"

Hello, personally I have always worked with the router's own OpenVPN to connect remotely either with the router itself, with Wake on Lan or with my work computer network without having to open any port on the router for security reasons, as I explain. in my two previous posts, and it works great for me, so I'm sorry I can't help you with the script, since I don't have experience with that method, but I have read that other people do well, and I hope someone can help you . Good luck and greetings...

 

[Deetlemore]

Hello, personally I have always worked with the router's own OpenVPN to connect remotely either with the router itself, with Wake on Lan or with my work computer network without having to open any port on the router for security reasons, as I explain. in my two previous posts, and it works great for me, so I'm sorry I can't help you with the script, since I don't have experience with that method, but I have read that other people do well, and I hope someone can help you . Good luck and greetings...

If I can't get this to work as I intend, I'll give your method a shot as well. So far I can confirm that the script is working as intended, so I guess I'll see tonight if the PC turns back on.

 

[Deetlemore]

I can confirm that the static arp is working as expected (though I changed the interval to 20 minutes). Unfortunately, my PC wakes up on its own whenever the WPA handshake occurs (which is hourly). I find another post elsewhere that came to the same conclusion, specifically that the wireless adapter isn't properly handling the hourly handshake, and is instead waking up the system to that it can perform the handshake itself.

I'll just chalk this up to another half-baked feature that doesn't work as inteded and leave my PC on.

 

[rung]

If this is a windows PC, you may want to compare sleep vs hibernate. Mine doesn't wake up from hilbernate until I send the WWOL packer. Sleep suffers from occasional wakeups from network activity.

 

[Deetlemore]

If this is a windows PC, you may want to compare sleep vs hibernate. Mine doesn't wake up from hilbernate until I send the WWOL packer. Sleep suffers from occasional wakeups from network activity.

I used to hide hibernate to avoid unnecessary writes to my SSD, but in the grand scheme of things I'm writing considerably more every day just using my PC. I'll give that a try this weekend and see what happens.

 

[Deetlemore]

Just to tie up loose ends, I figured out what was ACTUALLY waking up my PC. I mistakenly assumed it was an ARP request, but it was in fact the WPA key rotation. The GTK offload feature seems to be bugged in windows as I found multiple reports of the same issue with different wireless adapters.

To get around this, I initially set the 5GHz rotation to one week since my 5GHz band doesn't extend outside my house, but that seemed to cause the 2.4GHz band to also rotate weekly. I can't seem to set a separate interval per band despite there being two distinct settings. Not sure if rekeying is even that vital while running WPA3, but I'd rather not chance it, so I just gave up on the idea of WoWLAN. Seems to be a half-baked feature that was never fully debugged. Either way, it's not the router's fault so it is what it is.