I’m running an old server at home, an IBM system x3400 m3, rocking two x5675 intel processors.

I currently have Windows Pro (NOT Server) installed on it and connected to it remotely through Parsec (opened a port on my router). I’ve tried using duckDNS to associate my IP with a domain, and got the service running on my server to automatically refresh the IP.

This server is my primary rig, used for gaming but also to host my family’s photos through Plex and backup photos from phones through Resilio file Sync.

However, the server doesn’t have the best power consumption, so I’d like to use WoL to remotely turn it on. I’ve enabled it in the BIOS, have checked the drivers to enable it, and tried using TeamViewer to use Wake on Lan, but it doesn’t seem to work.

Any suggestions on how to remotely turn it on? (the server also has KVM I think, or at least an apparently useless network port, tho I’m not exactly sure what that does)

  • SteveTech
    link
    fedilink
    English
    arrow-up
    12
    ·
    edit-2
    1 year ago

    A lot of people are saying WOL doesn’t work over the internet, but I’ve got it working.

    Basically port forward UDP 9 to your broadcast address (the last possible IP in your subnet), eg. 192.168.1.255. Then send the WOL to your public IP which will then get broadcasted out over your network by your router.

    Typing this out, I realised this seems like a horrible security practice, so I’ll probably disable it soon anyway, now that I’ve got multiple servers and a failover VPN.

    • Gecko@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      ·
      1 year ago

      yeah, tunneling into your local network and then calling WoL from there is the way to go.

      • SteveTech
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Yeah, I only really used it when the computer running my tunnel wasn’t on, but that’s not an issue for me anymore.

    • lemmyvore@feddit.nl
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      It’s not that it doesn’t work, it’s that it’s anybody’s guess if any of the hops will pass it along. The odds are overwhelmingly in favor of it getting snagged somewhere along the way.

      • SteveTech
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Well it’s just UDP so isn’t that just how the internet works, but yeah when I did do it, I’d often spam a bunch of packets, sometimes just sending one didn’t work, but multiple always worked.

        • lemmyvore@feddit.nl
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          Well it’s just UDP so isn’t that just how the internet works

          I mean… just because a packet can be routed doesn’t mean it will be. Don’t be fooled by “mainstream” packets like TCP on 443 which is practically guaranteed to be routed everywhere and prioritized because it’s HTTP. Not all packets get the VIP treatment (if they’re even routed at all), and WoL is a pretty obscure one.

          • SteveTech
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            That’s sort of what I mean by “just how the internet works” where “it’s that it’s anybody’s guess if any of the hops will pass it along.”

            Like yeah I understand TCP has protections against dropped packets, but that’s only because it re-requests the packets it thinks are lost or corrupt.

            Also HTTP and WOL are at a different layer, they’re both TCP and UDP respectively, so it shouldn’t matter whether if the App layer is obscure or not. Heck the routers of the internet only look at the IP layer, so it can’t even tell if it’s TCP 443, and you could probably even write your own Transport layer protocol and route it over the internet.

            Although I guess firewalls could do some prioritisation, and wouldn’t like this new transport layer, but they’re usually near the ends of the connection, not in the middle, and I was taught to prioritise VoIP stuff anyway.

            TCP/IP model for reference:

            • Application (HTTP, WOL, Minecraft, whatever you want)
            • Transport (TCP, UDP, other ones too)
            • IP (IPv4 & IPv6 + older not used (X.25, CLNP, etc) / Sender and Destination)
            • Link (Ethernet and stuff)

            *I have not much experience so I may have made some mistakes, but I’m currently completing a CCNA so it should be somewhat correct.