Exactly the same has happened to me on the RT-AX58U and RT-AX86U routers, which then seems to be a generic problem of the 388.2 update, to which no response has been given at the moment, and the only solution that I found it has been reverting to version 388.1... The problem occurs because the ARP table of permanent IPs and MACs is deleted over time and especially when the PCs are turned off...
Okay, I hope so too. However, as an alternative, if you are a router administrator, you can wake up the pcs you want through the Asus router application on your mobile in the Network Tools option, but to make it work outside lan, you have to connect from the mobile to a VPN of the router, for example to the OpenVPN...
It`s not. I am unable to reproduce the issue on my GT-AXE16000, a static ARP entry I created was still there two days later when I last tested it.
www.snbforums.com
Hi, I've always believed that each device or installation is a world by itself, although in this case the only difference I see with what you're counting is that you're talking about hibernation, and maybe it's also valid for suspend, but in my case These are pcs that are turned off normally and that when necessary are turned on from outside the lan through the ethernet cards (not wifi), a procedure that I use by using a VPN from the router itself (OpenVPN) as if These were local connections without having to open any virtual port on the router. The problem I'm having is from the 388.2 update on the AX58U and AX86U routers, but it works perfectly on older versions like 388.1. However, your case gives me some hope that the issue can be resolved through some change in procedure. Thanks for your interest. All the best...
Fantastic, for me that I am not a technician you are like a genius, since I would never have reached that conclusion. I have reproduced your solution on my broadcast IP 192.168.10.254 on the AX86U router with version 388.1 and at first it has worked perfectly, then I have updated to 388.2, and likewise the permanence in the ARP table has been maintained until now when I report the experiment. Tomorrow and in the next few days I will continue to report on the maintenance of permanence, and also on the transfer of this solution to the AX58U router. And in any case, I thank you very much for your effort to solve this problem that at least for me is very important. All the best,
Yep i can confirm that in official 3.0.0.4.388_22525 it is working and arp is not getting cleared / deleted...
I went back to 388.2alpha1 again, becous the method I described in the post https://www.snbforums.com/threads/a...available-for-select-models.84524/post-836943 didn't work today and the static entry (192.168.50.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 died several times in a row. I noticed a pattern here - if, after rebooting the router, the entry (192.168.1.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 in the console after the arp -a command is above the entry (192.168.50.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0, then the entry (192.168.50.254) at ff:ff:ff:ff:ff:ff [ether] PERM on br0 does not die, and if it is below, then it dies . I thought it depends on the sequence of lines in the script, but it turned out not.
Okay, we agree that developers should give this issue some thought to see if they can come up with a technically sound solution, since I'm not very technically savvy myself. I have checked what you say about the position of the IPs after the arp -a command and in my case the MACs remain permanent in the correct position, but I would like to tell you that I have found another way to indicate the MACs in services-start and wake.sh (in jffs partition) following your procedure, which so far has not failed me, although I need more time to confirm it definitively:
Earlier, even before the appearance of this malfunction, I also used the real mac address of the device, but then I decided that it would be right to use the broadcast mac ff:ff:ff:ff:ff:ff. This is due to the fact that when using the real MAC addresses of the device's, you will have to create a port forwarding for each device that needs to wake on wan. And if you use a broadcast mac, then you need only one forwarding rule for all. But when I have time, I will try again with the device's real mac address and see.
Hi, yes, I think you're right in what you say, and I haven't tried it with port forwarding for security reasons, but anyway I would like to tell you that when I did the experiment with real MACs, I later realized that Wi-Fi was activated on the mobile and that when I deactivated it, the WOL stopped working. However, I would also like to tell you that your proposal with MACs of type ff:ff:ff:ff:ff:ff for the Jffs scripts (services-start and wake.sh) that I reproduced last night continues to work perfectly for me today in the morning in the AX86U router with firmware 388.2, where you can effectively wake up any PC on the network by indicating the real MAC of each device in the Wake On Lan mobile application. After the arp -n (-a) command, the IP 192.168.1.254 appears first, and on the other hand, for security reasons I always use the OpenVPN of the router to connect with the different PCs. It is clear that an administrator can always wake up any pc from outside the lan simply by using the Asus router mobile application also with a previous connection to the router's OpenVPN, whose subnet has connection permission in the router's System Administration. In any case, I will confirm if the results continue to be positive over time, in which case I would also implement them in the same way in another AX58U router to see if this solution also works there. Good weekend with the work party in between. All the best,
I tried with the real mac address of the device, the result is the same as with ff:ff:ff:ff:ff:ff - it all depends on some kind of chance. After four reboots, the static entry in the ARP did not die, after the fifth it died again. The will of chance does not suit me, and i again returned to 388.2alpha1.Hi, yes, I think you're right in what you say, and I haven't tried it with port forwarding for security reasons, but anyway I would like to tell you that when I did the experiment with real MACs, I later realized that Wi-Fi was activated on the mobile and that when I deactivated it, the WOL stopped working. However, I would also like to tell you that your proposal with MACs of type ff:ff:ff:ff:ff:ff for the Jffs scripts (services-start and wake.sh) that I reproduced last night continues to work perfectly for me today in the morning in the AX86U router with firmware 388.2, where you can effectively wake up any PC on the network by indicating the real MAC of each device in the Wake On Lan mobile application. After the arp -n (-a) command, the IP 192.168.1.254 appears first, and on the other hand, for security reasons I always use the OpenVPN of the router to connect with the different PCs. It is clear that an administrator can always wake up any pc from outside the lan simply by using the Asus router mobile application also with a previous connection to the router's OpenVPN, whose subnet has connection permission in the router's System Administration. In any case, I will confirm if the results continue to be positive over time, in which case I would also implement them in the same way in another AX58U router to see if this solution also works there. Good weekend with the work party in between. All the best,
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,
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!
