Speaking about LAN, today, I encountered an unexpected event I had never imagined or experienced before.
I was working on a simple HTML/CSS game in VS Code, with Live Server running on port 5500 to serve the site. Feeling a bit tired, I decided to take a break. I put my Windows PC to sleep and moved to another room in my house. There, I spotted my Android tablet and thought it would be interesting to see how the game would perform on a tablet.
I unlocked the tablet, opened Chrome, entered my PC's local IP address and port, and hit 'Go'. To my surprise, the loading spinner appeared and spun for about 3-4 seconds. I was puzzled as to why the request was taking so long to get a response, and then it hit me—my PC was supposed to be sleeping.
Yet, just as I was processing this realization, the game’s web page loaded on the tablet. I was stunned, thinking, "Wait a minute—didn't I put my PC to sleep?" I went back to check my PC, and sure enough, it was awake but showing the lock screen. Out of curiosity, I repeated the experiment: I put the PC to sleep again, then accessed the webpage from my phone, and, once again, my PC awoke in response to the request. It was an eye-opening moment to see how the network request could wake my PC from sleep!
I googled this behavior and turned out to be called Wake on LAN or, WOL for short [1].
WoL relies on a special magic Ethernet frame being sent to the MAC of the sleeping computer. A normal ARP or TCP SYN from an incoming HTTP request won't do it. The wikipedia article has the exact frame format:
https://en.wikipedia.org/wiki/Wake-on-LAN
I've seen setups where the router is configured to send the magic WoL packet when it sees an ARP for the IP of a computer it knows is sleeping, but you'd almost certainly know if you had an exotic configuration like that on your network.
The terminology here can be a little confusing, because WoL isn't a precisely standardized term but rather sort of a general label for a family of behaviors, the most common of which is the "Magic Packet" that originated with AMD. For some time a magic packet was mostly the only thing that could wake a computer, because the NIC had to originate a power-on event and most NICs were only capable of doing so in response to a magic packet. There were, though, particularly in more "enterprise" contexts, NICs that could be configured to wake the machine on other types of traffic. This kind of thing went in the option ROM of high-end NICs.
Today, though, with various low-power states and "hybrid sleep," packets received while in a low-power state can actually be delivered to the operating system to make a decision on waking. That's made WoL a lot more complex: with a supported network adapter and power state, Windows will wake up in response to pretty much any network traffic directed at the sleeping computer. That detection is surprisingly sophisticated, unicast packets addressed to a computer will wake it, but so will certain recognized discovery protocols sent to broadcast when they specify the computer's hostname.
One the one hand, it's pretty neat that e.g. attempting to connect to an SMB share on a Windows computer will wake it. On the other hand, it means that "nuisance" WoL has become an occasional irritation. For that reason you can configure Windows back to the original behavior of only waking on a magic packet specifically. To be fair, the whole idea came about in part because of all the implementation limitations with magic packets that made them very flaky.
Microsoft refers to all of this functionality with the term "WoL," while Apple seems to have decided to avoid the confusion by calling the entire concept "Wake on Demand" instead.
I'd bet on your computer using "modern standby" rather than WoL. Seems unlikely that your tablet would to send the special WoL ethernet packet just from a web browsing context.
WOL is an old feature where you could even boot a PC that is off, not just asleep, but you had to confine it in the BIOS. It has become less useful with computers able to go into power save modes that are almost as good as having it fully off energy-wise.
I would love something like this integrated with OpenWRT so it can also get the DHCP hostname. This is usually the most useful bit of information, but the hardest one to get if you're not the router.
In general "private" WiFi doesn't work like this. Instead it's per SSID. So on iOS [0] and Android [1], a new private MAC is generated once per SSID and preserved until network settings are reset. This is why you won't generally have issues with connecting to and leaving a captive portal (hotel, airplane, etc).
It's always been configurable on a per-network basis. Apple has changed it to some odd, assumptive, defaults now because their new approach will break a number of common network situations.
Also, if you read through comments on how it's been working in the betas it doesn't seem as though it's been working as expected for a number of folks. The Android implementation is a better design, IMO. Persistent / non-persistent "privacy" is an easier follow. Also, many folks want the capabilities of both modes depending on the networks they're connecting to and the devices they're managing touching specific networks. I feel as though Apple is going backwards in a way with this new change, I won't be upgrading to iOS 18 or macOS Sequoia for the foreseeable future though given all the things Apple is adding.
When I did more field work, I would use a tool called Look@Lan. This would scan the network and detect common open ports. Similar functionality to nmap, but in a nice gui so you ended up with an interactive list of results.
The ability with look@lan to connect into a client's network and quickly a list of everything reachable on the network was incredible. All the desktops, laptops, printers, etc. When I was doing WISP work, I could quickly see how many clients were online without logging into the far end (nowadays though, most WISPs will enable client isolation, but still good to see the APs and gateways).
Eventually look@lan was discontinued and then they released a tool called Fing, which also worked on mobile. But that turned into a subscription service. I did like the ability of fing to work from a phone, but the earlier Look@Lan was much more useful. I recently helped out a local non-profit who's network was all over the place, split up between two separate access points, each with their own subnet and they were having trouble reaching printers. Nmap helped out, but couldn't find a comparable tool to look@lan to help.
WatchYourLan looks like it will be a good substitute. I know it's primarily designed to run on one network and track changes to said network. And I will probably use it that way at home and a few other places (for the few customers I still maintain, if they permit, I will drop a small Pi/N100 box on their network for remote access and monitoring). But for dropping into a new location, I could see spinning this container up. I could do it in ephemeral mode or setup a data directory per "site" I visit.
There's a few tweaks I could see to make this more "mobile". such as adding a network or "site name" to the DB that you can config and filter on.
Another feature I'd be interested in would be fleshing out the port scanning a bit. Look@Lan and nmap scans for some common ports automatically. WatchYourLan has a port scanner, but you lose the information if you navigate away. At table for port scan results and an option to pre-scan specific ports. This would be good even for the permanent install - some might configure a set of default ports to scan on all the hosts in network, or they might customize for individual hosts.
But those are just my thoughts comparing it to tools I've used in the past. It's already a satisfying tool that's going to be added to my "toolbox". And since I also am a go dev, I might even be able to make some of those a reality.
I was working on a simple HTML/CSS game in VS Code, with Live Server running on port 5500 to serve the site. Feeling a bit tired, I decided to take a break. I put my Windows PC to sleep and moved to another room in my house. There, I spotted my Android tablet and thought it would be interesting to see how the game would perform on a tablet.
I unlocked the tablet, opened Chrome, entered my PC's local IP address and port, and hit 'Go'. To my surprise, the loading spinner appeared and spun for about 3-4 seconds. I was puzzled as to why the request was taking so long to get a response, and then it hit me—my PC was supposed to be sleeping.
Yet, just as I was processing this realization, the game’s web page loaded on the tablet. I was stunned, thinking, "Wait a minute—didn't I put my PC to sleep?" I went back to check my PC, and sure enough, it was awake but showing the lock screen. Out of curiosity, I repeated the experiment: I put the PC to sleep again, then accessed the webpage from my phone, and, once again, my PC awoke in response to the request. It was an eye-opening moment to see how the network request could wake my PC from sleep!
I googled this behavior and turned out to be called Wake on LAN or, WOL for short [1].
__________________
1. https://learn.microsoft.com/en-us/troubleshoot/windows-clien...