D_L Posted December 14, 2021 Share Posted December 14, 2021 TL;DR: the v3.0.394 update broke reaching devices after they have been offline for more than a couple of minutes, therefore breaking PC-waking functionality (from sleep, hibernate and shutdown states). Context: I was able to wake my PC from hibernation remotely (from a different country) for the whole of last year without issues, but it seems that updating to firmware v3.0.394 has broken this setup. I am sure that the issue is with the router rather than with the PC since replacing the router with the one from my internet provider and applying the same DHCP and port forwardings works fine (and because no significant PC updates or settings-changes occurred around the time of this loss of functionality). Details: The port forwarding works fine while the PC is awake (I can see the packets arriving). Even more interestingly and worryingly though, whatever went wrong does not seem to be fixable even by a factory reset followed by a rollback to v3.0.205 followed by another factory reset. I did consider the idea that perhaps some setting survived until v3.0.394 even from v3.0.179, but this should not be the case since I followed the suggestion of factory-resetting the router after every update since I got it. The only settings involved in this remote Wake-on-LAN setup are the following: A fixed IP for the PC under DHCP Port-forwarding UDP 7-9 to said IP (and also TCP 3389 for Remote Desktop, but that requires the PC to be awake and has always worked) I frequently rely on this functionality, but especially so if I am not in the country, therefore unfortunately I will be forced to not use the R2 over the holidays (unless it is fixed this week, which I am aware is not a reasonable timeframe ). Link to comment Share on other sites More sharing options...
D_L Posted December 14, 2021 Author Share Posted December 14, 2021 Separately from fixing the issue, I have a few suggestions w.r.t. the DumaOS networking interface which would have made the debugging process reach definite conclusions much faster and without relying on trying a different router: 1. Allow setting port forwardings by MAC as an alternative to by IP since the latter has to rely on the separate DHCP setting, obfuscating the point of failure (previously mentioned in this thread) 2. Allow port forwarding to the broadcast IP x.x.x.255 in order to make sure every reachable connected device gets forwarded the packets Further expanding the scope of suggestions, here are two functionalities which would be of great usefulness, not just for this situation: 3. Allow remoting into the router itself, ideally to the GUI, though ssh or telnet access with perhaps DumaOS-custom commands would also be great. On the GUI-side of things the DumaOS phone app could just have the remoting as an option. Obvious security concerns could be reduced by making remoting-in optional, hidden (say at an arbitrary port and login packet) or using two-factor authentication 4. Add a "send wake packets" button when selecting in the device information interface or in a dedicated Wake-on-LAN Rapp (also suggested a while ago in a different thread) Link to comment Share on other sites More sharing options...
Administrators Netduma Fraser Posted December 14, 2021 Administrators Share Posted December 14, 2021 So WOL isn't something we've specifically accounted for so it's not really something we could fix right away as we'd have to look into it. I'm not sure why it worked previously on the other versions or why it isn't now, could be more of a bug that you actually managed to make it work. I will pass this onto the team to have a look, thanks for the suggestions as well, we'll add them to the list! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.