Wake-On-LAN via fog agent with brand new PC's

rdr

Hi,

I am testing/using FOG project to manage imaging of our 6 PC labs, ~400 PC’s. I confirmed that I can power on a PC via FOG server Web UI, if there is an PC with active FOG agent on that subnet and also if the powered of PC was checked-in with fog agent before. It is working as expected.

What I wonder is, as I am just started to use FOG server and there is no fog agents on the PC’s, can I install fog agent to the PC that I will use to capture image, then somehow I instruct FOG server that the imported hosts are on the same network, so I can power on the PC’s without visiting all of them one by one?

I hope I explained I am trying to achieve.

Regards,

Rahman

Tom Elliott

@rdr there is a feature in the fog agent (although untested at this point) that can tell the fog-agent to try to send a WOL packets. If an agent machine is up, and you need to wol a machine that’s on the same subnet, it can happen. It is disabled by default.

I think that’s what you were attempting to ask? I hope I didn’t butcher it too badly.

https://docs.fogproject.org/en/latest/management/web/fog-agent#waking-a-host-on-a-subnet-with-no-fog-server

rdr

@Tom-Elliott I think you mean “FOG_AGENT_WAKE_RELAY_ENABLED” setting. I already enabled it and it works as expected without any problems. But as I understand, it needs to know the IP addresses of the powered off hosts, so server can decide which alive fog agent it will use to relay WoL requests, am I right? This is OK and I tested, it works.

What I am after is different from “FOG_AGENT_WAKE_RELAY_ENABLED”. Lets say I have PC lab with 100 hosts, I import MAC and Host name list into FOG server. Then install Windows on one of them, install all needed drivers and applications. Then I install FOG agent and approve it. Then capture image from this. Then create deployment tasks for the remaining 99 PC’s. Then I want to send Wake on LAN request via this alive agent to the remaining PC’s so without me powered them on one by one physically, they will power on remotely and start to deploy image. But as FOG server does not know their IP addresses, as they have no fog agent installed previously, is there a way to teach fog server their IP subnet?

Hope it’s clear now

Rahman

Tom Elliott

@rdr I don’t believe the FOG-Agent would be the right thing for this, and neither would the FOG Server.

In very old versions of FOG the IP address was a distinguishing factor of what a “host” was.

Relatively shortely after that became a norm, machines really started to come with multiple NICs, and/or with Wifi. That plus many systems prefering to move to DHCP for their networks (due to Wifi needs, and manual intervention to change an ethernet when a machine moved from one place to the other) FOG stopped trying to use the IP as a definition of what a host was.

WOL Works on macs and generally locally to the subnet the FOG server (or local machines) run on, but with some finagling you can send WOL packets on different network subnets.

Welcome the WOLBroadcast Plugin that already exists. I will admit I’ve not tested this plugin in quite some time now, so please see if that will be more what you’re looking for?

The FOG Agent shouldn’t be simply spamming your network with WOL packets just because it doesn’t know what is on the same subnet (to your initial point), but the FOG Server should be able to especially if you have your network already done for this.

I hope this helps with what you’re looking for. The FOG Agent, in my eyes, should only try to do things it knows about, instead of being a rogue “DDoS” vector.

rdr

@rdr I see your point, but with “FOG_AGENT_WAKE_RELAY_ENABLED”, isn’t the FOG server requesting WOL, and the agent send WOL to the local network because the FOG server asked it? So the agent is not trying to be smart about doing things it does not know about, or I completely misunderstood how “FOG_AGENT_WAKE_RELAY_ENABLED” works

Tom Elliott

@rdr I think I don’t fully understand either.

Basically, behind the scenes as I understand the build:

FOG Server wants to wake a machine. FOG Server tries to send a Magic packet to the MAC address in question. It also checks the ARP table of the network to see what FOG agents might know about the MAC being requested to wake, and if an agent is alive on the same subnet that MAC lives on, it will ask the FOG Agent to also try to wake it up.

So I don’t think it knows it the way we are thinking about things. It’s a bit more nuanced than that, but that’s highly suspected from my understanding of things, not necessarily exactly how it knows.

I’ll ask claude code to see if it can give me a quick rundown of how it works from a design and flow perspective.

Tom Elliott

@rdr

How FOG wakes a host through the fog-agent wake relay

Summary

FOG wakes a host in two ways at the same time. First, the FOG server and the storage nodes send the magic packet on their own subnets. Second, if the relay is on, the server asks up to three awake agents on the host’s subnet to send the packet. The server always picks the target and the senders. An agent only sends.

The problem

A Wake-on-LAN (WoL) magic packet is a broadcast. A broadcast stays on one subnet. Before the relay, only the FOG server and the storage nodes sent the packet. So FOG could not wake a host on a subnet with no FOG server and no storage node.

To send a broadcast to a remote subnet (“directed broadcast”), the routers must forward it. Most networks disable that router feature, because attackers used it for amplification attacks. The wolbroadcast plugin depends on that feature.

The relay removes the gap. Every such subnet has FOG hosts on it. When one of them is awake, it can send the packet for its neighbor.

How FOG knows which hosts share a subnet

Each fog-agent reports its network interfaces to the server on every poll. For each interface, the report gives:

the IPv4 address and the prefix length (for example, 10.1.5.23 and /24)
whether the interface is up and has a link (a NIC with no cable is not up)
whether the interface is wireless

The server does not trust a network address from the agent. It calculates the network address and the broadcast address itself, from the address and the prefix. It stores one row for each address in the hostNetwork table.

Example:

Host	Reported	Network the server calculates
Host 41 (asleep)	`10.1.5.23/24`	`10.1.5.0/24`
Host 77 (awake)	`10.1.5.80/24`	`10.1.5.0/24`
Host 90 (awake)	`10.1.0.12/16`	`10.1.0.0/16`

Hosts 41 and 77 share a subnet: the network address and the prefix are both equal. Host 90 does not share it. Its network address is different, and a /16 and a /24 are never one subnet.

To find senders, the server does one database lookup. It takes the rows of the sleeping host, and it finds other hosts with the same network address and the same prefix. It then keeps only the hosts that meet all of these conditions:

The interface is up and has a link.
The interface has a broadcast address. A /31 or /32 link has none.
The interface is not wireless. An access point does not pass a broadcast to a machine that is asleep, because that machine is no longer connected to the access point.
The host polled in the last 900 seconds, so it is probably awake.
The host is not the sleeping host.

The server sorts the result by the most recent poll and keeps the first three.

Limits of this method

The sleeping host must run fog-agent. The server uses the sleeping host’s own last report to find its subnet. A host with the legacy FOG Client, or with no client, has no rows, so the relay cannot help it. The old path still runs for it.
The sleeping host’s subnet is its last report. A laptop that moved to a different subnet while off is looked for on the old subnet.
Only IPv4. A magic packet uses an IPv4 broadcast.

The flow, step by step

Step: someone asks for a wake. The source is the Wake Up button, a group wake, or a scheduled wol task. Each of these calls Host::wakeOnLAN().

Step: the old path runs first, and it does not change. The server sends a request to every storage node and to itself. Each of them sends the magic packet on its own subnets. If a storage node shares the host’s subnet, this path is enough.

Step: the relay path runs as an addition. It does nothing unless the global setting FOG_AGENT_WAKE_RELAY_ENABLED is 1. The default is 0. The server finds up to three senders, as described above. It writes one agentWake row for each pair of sleeping host and sender. Each row expires after 600 seconds.

Step: the sender agent receives the request on its next poll. The agent does not listen on a network port. The request is part of the normal poll answer:

"wake": {"targets": [{"id": 41, "macs": ["00:11:22:33:44:55"]}]}

The block contains no destination address. It contains only the host id and the MACs of that host. The server leaves out pending MACs that nobody approved.

Step: the agent sends the packet.

The agent parses each MAC and builds it again. It refuses a MAC that is not valid.
It builds the 102-byte magic packet.
It sends the packet to UDP port 9, at 255.255.255.255 and at the broadcast address of each of its own interfaces.
It sends to at most 32 hosts per poll, and at most one packet for each MAC on each interface.

Step: the agent reports the result. The result is sent with a packet count, or failed with a reason. The server accepts the result only if a pending agentWake row names this sender and this sleeping host. Otherwise it returns 404. So an agent cannot report on a host that the server did not ask it to wake.

Why the design has this shape

Choice	Reason
The server picks the target and the senders	A magic packet has no authentication. The control must be on who can ask. Only the server knows which hosts are real FOG hosts.
The request is part of the poll, with no network port on the agent	An open port lets anyone who can reach it ask for a broadcast.
The request has no address field	An agent that accepts a destination can be used to send traffic at any address.
Three senders, not one	Extra packets cost almost nothing. With one sender, the wake fails silently if that sender goes to sleep.
Requests expire after 600 seconds	A laptop that comes back next week must not send an old wake.
Off by default	One customer machine sends traffic for another. The estate owner must choose that.
Wireless interfaces are never senders	The access point does not deliver the broadcast to a sleeping machine.

The cost: delay

A relayed wake goes out on the sender’s next poll. With the default interval, that is up to 5 minutes. Most WoL use in FOG is a scheduled overnight task, so the delay is acceptable. The old path still sends immediately.

What the relay is not

It cannot wake a device that FOG does not manage.
It does not replace the storage-node path or the wolbroadcast plugin.
Agents do not talk to each other. Every decision is the server’s.
It does not wake a host across the internet. A magic packet stays on one subnet.

Sources

Design: fog-agent/docs/design/0011-wake-relay.md
Wire format: fog-agent/docs/design/protocol-v1.md, section “Wake”
Server: packages/web/src/Agent/WakeRelay.php (senders()), packages/web/src/Agent/NetworkFacts.php, packages/web/src/Items/Host.php (wakeOnLAN())
Agent: internal/network/network.go, internal/provider/wake/

rdr

@rdr I see what you mean now. I thought FOG server saves the last IP address to its database and use it to determine if the powered off host is on the same subnet. If it is using live ARP lookups via agents to determine the subnets/agents matching then I can not customize or hardcode it.