MiniWOL - Forum

Installers.

Anonymous — Mon, 17 Jul 2023 14:01:37 +0000

Currently, the packages appear to be distributed as archives. Tar for Linux and macOS, and Zip for Windows. I'd like to be able to install MiniWOL via Windows's new native package manager, WinGet. However, it doesn't (yet) support archives, and probably won't for some time. I can use something like gomsix fairly easily, but that would probably create more issues for you if the unofficially packaged version has issues that the official version doesn't.

An EXE, MSI, APPX or MSIX package that just extracts the files into ProgramFiles would fix this, and make me a lot more easily able to recommend this to others, since they'd be more confident downloading something from somewhere that they know is trustworthy. Also, it just means less things to manually update for me, when using Windows.

Thanks!

Issue tracker (not forum)?

Anonymous — Mon, 17 Jul 2023 13:57:19 +0000

Does a more formal public issue tracker exist for this project? I'd like to subscribe to others' posts just for issue closure, etc. That's not really possible with Discourse.

Source code availability.

Anonymous — Mon, 17 Jul 2023 13:56:16 +0000

Does a source code repository exist? I'd like to be able to get some other people to use this, but it's hard to convince others nowadays to just download (what appears to be closed-source) software from a forum, regardless of how positive VirusTotal is. It also means I can't use it on some of my more niche devices with weird hardware, etc.

Can't run the main GUI.

Anonymous — Fri, 14 Jul 2023 12:02:37 +0000

I've downloaded https://www.tweaking4all.com/downloads/network/miniWOL-2.1.3-Linux64bit-QT5.tar.gz

439

If I click OK, it simply continues to request confirmation indefinitely, although the main GUI loads after the 3rd acceptance.

440

WOL to different LAN

ben — Sun, 23 Oct 2022 16:37:53 +0000

Recently, I discovered an interesting topic. I try to send a WOL packet into a different subnet. In my case the subnet is also further complicated because it is actually located over the internet and I am connected through a wireguard server and client tunnel. I know that a WOL is normally just broadcast in the local LAN and not forwardet into other LANs but since you provide the option to set an IP address additionally to the MAC I suspect you might be knowledgeable in this area. :)

What I actually CAN do is send a WOL back FROM THE CLIENT side of my tunnel.

It will travel from the client device to the wireguard client where it has to leave the LAN and go into the tunnel LAN. It will then travel over the internet. From there it will reach my other internet connected ISP router, then into my edge router which acts as DHCP, and from there it will go to the wireguard server where it will leave the tunnel IP range and go into the (third) LAN range and will then wake up a client device in that (third) LAN.

I am not shure which device will actually send the broadcast into this LAN.

Maybe it is the edge router which is the gateway for it.

Or maybe it is the wireguard server, which is a Raspberry Pi, a client in that LAN.

Since subnet directed broadcasts are by default deactivated on routers I suspect the Raspberry might be doing it due to a failure in its configuration: When turning it into a wireguard server it will be set to forward packages.

Now, what I CANNOT do is waking up a device the other way around, FROM THE SERVER's LAN to the client's LAN.

Somewhere in this chain a router will not forward the broadcast from the wireguard server’s side into the wireguard client’s side. I did not find any settings on the TP-Link which is involved. But it might also be that the TP-Link delivers the package upstream to the ISP router (after it left the wireguard tunnel) and the ISP router is not broadcasting it.

This explanation sounds complicated but it is actually very straightfoward: The package comes in from the internet but inside the wireguard tunnel. Because of this it will travel through the incoming router until it reaches the wireguard client. On this client it will leave the tunnel and then will have to find the actually correct destination LAN for the WOL broadcast. But this client is one LAN "behind" this target LAN. Therefore it has to find the gateway, travel "upstream" so to speak and then the router between those two LANs has to broadcast it (probably. But maybe it will travel even further to the gateway of the destination LAN and this second router will broadcast it).

Well, maybe someone have something to say to it. :)

After your comments on my initial post I was able to send the WOL over the internet already by giving it the broadcast address "192.168.300.254" in the settings. It will be shown in the wireguard client (this is already on the remote LAN) on eth0 as “wol b8:27:eb:80:e4:60 -> 74:d4:35:fb:22:cc”. It will be shown twice and the source mac changes. So I think it is going out. However, it is not reaching the destination, probably, because from there it would have to travel upwards one LAN still and the TP-Link router over there is not forwarding it.

So I have to solve this.