@george1421 noted. When I was initially testing, I did not know this and it took some digging in the forums to find this tidbit of knowledge. Given that having separate storage groups stops replication between the nodes in my mind it makes most sense to have a more distributed setup of normal servers at each site to handle all of my requirements. Thanks for the input!

@george1421 thanks for the detailed response! We are frequently re-imaging lab rooms. The subnet group plugin is vital as when a device moves rooms to a separate subnet, when it ‘checks-in’ to FOG after it is powered on and PXE boots in the new location it will be re-assigned to the proper group associated with the IP range. That subnet group will be used to group all the lab computers in the desired room and thus used to multicast the room.

The issue lies when I have a storage node setup at a new location and acting as the PXE/TFTP server, the client will not ‘check-in’ with the main FOG server and run the plugin hooks until it finishes imaging and the client takes care of it which does not work in my desired process.

At this point I am leaning towards a standalone server for each site just to support the functionality required.

To follow up on this I am looking for any community input on the following:

If anyone has a multi-site setup where they are reliant on the Subnet Group plugin did you:

1. Edit the init.xz file to check in with the master server, if so, I’m curious how
2. Setup each site node as a normal server with your full configuration
3. Another option that I have not thought of

Anyone’s input would be greatly appreciated.

Hello everyone,

I have an interesting issue I am facing. I am testing having a storage node at another physical site. The connection seems fine as it can reach the FOG server but one thing I am facing is I am heavily reliant on the Subnet Groups plugin, specifically for identifying what IP a client is upon booting into FOG and assigning to the associated group.

What I am finding is that when a client boots at the sub-site it will get the boot files from the storage node and get into the ‘DEVICE IS REGISTERED’ screen but the plugin hook never fires thus thwarting my desired process.

My desired process is when computers are setup in a lab: Booted > Check-in with FOG > Subnet Group assigns computers to proper group > boot loop until all devices are in group > assign an image and task > machines are images. I have this working at the main site.

Is my best option to have a separate full FOG setup at each site?

Appreciate anyone’s input!

FOG version: 1.5.10.1733
Server OS: Ubuntu 24.04

@lmoysidis I’m not using fortigate but check out the following article: https://docs.fogproject.org/en/latest/installation/network-setup/proxy-dhcp/?h=
I needed to dynamically assign a boot file based on vendor class and dnsmasq did the trick!

I reverted back to a snapshot I had on the same version and it’s working as expected. Unsure how things got corrupted but I would say it’s safe to assume this is working unless others report the same issue.

LOG Viewer is empty in the GUI. I can however access the logs via the server.

FOG Version: 1.5.10.1733

In the web developer console, I see the following:

fog.about.logviewer.js?ver=141:42  Uncaught TypeError: Cannot read properties of null (reading 'split')
    at LogGetData (fog.about.logviewer.js?ver=141:42:25)
    at fog.about.logviewer.js?ver=141:11:5
    at fog.about.logviewer.js?ver=141:32:3

Seems similar to a previous issue.

@Tom-Elliott latest pull resolved the issue. Appreciate your help on this!

@Tom-Elliott apologies for the delay but I now had time to test and found the following:
I am using Ubuntu 24.04
I updated FOG to version: 1.5.10.1732

I then tested a multicast and confirmed that partclone is still stuck at the first screen.

When I run:

sudo systemctl -l status FOGMulticastManager.service

I see the following:

Nov 03 13:22:12 fog-syd001 systemd[1]: FOGMulticastManager.service: Scheduled restart job, restart counter is at 1.
Nov 03 13:22:12 fog-syd001 systemd[1]: Started FOGMulticastManager.service - FOGMulticastManager.
Nov 03 13:22:13 fog-syd001 env[24152]: PHP Fatal error:  Uncaught Error: Call to undefined function int() in /var/www/fog/lib/service/multicasttask.class.php:460
Nov 03 13:22:13 fog-syd001 env[24152]: Stack trace:
Nov 03 13:22:13 fog-syd001 env[24152]: #0 /var/www/fog/lib/service/multicasttask.class.php(689): MulticastTask->getCMD()
Nov 03 13:22:13 fog-syd001 env[24152]: #1 /var/www/fog/lib/service/multicastmanager.class.php(322): MulticastTask->startTask()
Nov 03 13:22:13 fog-syd001 env[24152]: #2 /var/www/fog/lib/service/multicastmanager.class.php(639): MulticastManager->_serviceLoop()
Nov 03 13:22:13 fog-syd001 env[24152]: #3 /opt/fog/service/FOGMulticastManager/FOGMulticastManager(37): MulticastManager->serviceRun()
Nov 03 13:22:13 fog-syd001 env[24152]: #4 {main}
Nov 03 13:22:13 fog-syd001 env[24152]:   thrown in /var/www/fog/lib/service/multicasttask.class.php on line 460

Just to provide more details. It seems that the multicast service is not functioning post update.

Here is a sample of the log file:

[10-23-25 10:34:19 am] * Starting MulticastManager Service
[10-23-25 10:34:19 am] * Checking for new items every 10 seconds
[10-23-25 10:34:19 am] * Starting service loop

The service is starting but seems to be stuck starting the service loop and never proceeds. I restarted the service, but the issue persists.

@Tom-Elliott thank you for the detailed response and quick change.

Two things to note:

• Multiplying the value of UDPCAST_MAXWAIT by 10 worked in v.1726 resolving the issue.
• I performed the update to .1727 and attempted a multicast but it was stuck on the initial multicast screen advising there are no multicast task jobs created, or no task numbers assigned. I am curious if anyone’s multicast is currently working in the updated dev branch.

Let me know if you need me to perform further tests upon review.

Hello everyone,

I am currently facing a challenge when multicasting an older desktop (Lenovo M800). When the desktop is imaged using a deploy task it will complete as expected (just take a fair amount of time). When it is grouped with more modern computers it will all start out fine, it will make it through the first phase of part clone but as soon as it gets to the resizing phase, the modern computers will quickly complete this task, while the older desktop takes a minute.

As soon as the modern computers resize their disks, wait at the last partclone screen for ~30 seconds, they will then complete and go to postdownload scripts. The desktop however hangs on resizing for around a minute, and by the time it makes it to the last partclone screen it will wait indefinitely as I believe it is left behind.

From the log perspective (/opt/fog/log/multicast.log) I see that as soon as the modern computer finishes it begins stating “$Groupname is no longer running”. On the contrary the multicast task will continue to show in the GUI for the stuck host.

I have adjusted UDPCAST MAXWAIT setting but it seems this just affects the first screen. I have also tried rebooting the stuck host, and it will return to the multicast screen and continue to wait indefinitely.

FOG Version: 1.5.10.1726

I am looking for input on how others have dealt with this before.

@Tom-Elliott, disregard this request.

I edited ‘addsubnetgroup.hook.php’ which simplified getting the client IP and adding the host to the respective group. I understand this also removes certain checks that were in place but for my environment it is now working as intended.

Old ‘addSubnetgroupHost’ function:

public function addSubnetgroupHost($arguments)
    {
        if (!in_array($this->node, (array)self::$pluginsinstalled)) {
            return;
        }

        $Host = $arguments['Host'];
        $mac = $Host->get('mac');

        if (!isset($mac)) {
            return;
        }

        // Setup for tests
        $name = $ipn = $Host->get('name');
        $ip = $Host->get('ip');
        $ipr = self::resolveHostname($name);

        // Perform all tests.
        $ip1t = filter_var($ip, FILTER_VALIDATE_IP);
        $ip2t = filter_var($ipn, FILTER_VALIDATE_IP);
        $ip3t = filter_var($ipr, FILTER_VALIDATE_IP);

        // If resolve hostname returns a valid IP, set IP appropriately.
        // Otherwise, if the name is valid, use it.
        // Otherwise, return if base $ip is false.

        if (false !== $ip3t) {
            $ip = $ipr;
        } elseif (false !== $ip2t) {
            $ip = $ipn;
        } elseif (false === $ip1t) {
            return;
        }

        // Now list our subnet groups.
        Route::listem('subnetgroup');
        $SNGroups = json_decode(Route::getData());
        foreach ($SNGroups->subnetgroups as &$SNGroup) {
            if (in_array($SNGroup->groupID, $Host->get('groups'))) {
                $Host->removeGroup($SNGroup->groupID)->save();
            }

            $subnetList = str_replace(' ', '', $SNGroup->subnets);
            $subnets = explode(',', $subnetList);
            foreach ($subnets as &$subnet) {
                if ($this->_ipCIDRCheck($ip, $subnet)) {
                    $Host->addGroup($SNGroup->groupID)->save();
                    unset($subnet);
                    continue 2;
                }
                unset($subnet);
            }
            unset($SNGroup);
        }
    }

New code:

public function addSubnetgroupHost($arguments)
{
    if (!in_array($this->node, (array)self::$pluginsinstalled)) {
        return;
    }

    $Host = $arguments['Host'];
    $mac = $Host->get('mac');

    if (!isset($mac)) {
        return;
    }

    // Use the real source IP from the request
    $ip = $_SERVER['REMOTE_ADDR'];

    // Now list our subnet groups.
    Route::listem('subnetgroup');
    $SNGroups = json_decode(Route::getData());
    foreach ($SNGroups->subnetgroups as &$SNGroup) {
        if (in_array($SNGroup->groupID, $Host->get('groups'))) {
            $Host->removeGroup($SNGroup->groupID)->save();
        }

        $subnetList = str_replace(' ', '', $SNGroup->subnets);
        $subnets = explode(',', $subnetList);
        foreach ($subnets as &$subnet) {
            if ($this->_ipCIDRCheck($ip, $subnet)) {
                $Host->addGroup($SNGroup->groupID)->save();
                unset($subnet);
                continue 2;
            }
            unset($subnet);
        }
        unset($SNGroup);
    }
}

I’ve done some trivial troubleshooting, and it seems that the ‘RequestClientInfo’ action is not taking place thus the plugin is never being called to run.

I’ve tried installing the FOG Client (rather than relying on the machine booting to fog via PXE), and power cycling a test machine, but this did not make a difference.

Reviewing previous forum post @mattmurdock78 had a similar issue and wrote a trigger, unfortunately the file he attached is not available.

@Tom-Elliott, I understand you were not the main author of the plugin but if you have the opportunity to review and advise if the plugin ‘should’ be working or is deprecated and potentially how I can try to proceed it would be greatly appreciated.

Hello, I have a FOG server setup on version 1.5.10.1719.

I have multicast working across VLANS/Subnets and it’s all splendid.

My challenge now is that I want to provision a subset of computers based on what subnet they are on. As different labs will need different images pushed to them and computers can get moved between labs at any time.

I saw that the ‘Subnet Groups’ add-in existed and thought this was the exact answer I needed! I added it, I created a group with the address range of one of my test machines, and booted it into FOG, but alas it was never added to the group.

I don’t quite grasp how the add-in works and how it interacts with the hosts IP addresses.

If anyone has any insight into this it would be greatly appreciated!

My RP address was not pointing to my FOG server

Once this was adjusted, multicast is functional. Definitely a good reminder to start small.

I was able to create a multicast task from the FOG server, and while the main client was stuck in the partclone screen, I was able to launch another client on the same VLAN in debug mode and run “udp-receiver --portbase <PORT FROM LOGS>” and it was receiving the stream of traffic and showed up in the ‘multicast.log.udpcast’ logs.

This makes me curious as to what udp-receiver command the client is running when booting into partclone as it never joins the session and just sits at that screen indefinitely.

I see that the images did not load so I uploaded my multicast settings to imgur.
https://imgur.com/EU7FOkm

Also wanted to note no ports are being blocked within the VLAN.

I’ll continue troubleshooting but appreciate anyone’s 2 cents on this.

Hello everyone,

I’m back with more multicasting issues. When I attempt to multicast the task starts, but on the client end, they are left sitting at the first partclone screen after listing the image.

On the networking side, we intend on using 3 VLANS but I have kept it all on the same VLAN to get the initial test working before complicating things.

I am on Ubuntu 24.04 and FOG v 1.5.10.1719

We have the following setup in regards to networking:

1. Option 66 + 67 (Unicast is confirmed working, and it boots successfully
2. IGMP snooping enabled
3. PIM (SM)
4. RP

I have also followed the steps to test multicast manually with the udp-sender and udp-receiver commands and that is working within the same VLAN and outside.

If anyone has any suggestions I would really appreciate it. I understand this is a common issue judging by similar forum posts but I was unable to find a resolution from past posts.

When I start the task the log has the following:```
[09-24-25 5:53:03 am] * No new tasks found
[09-24-25 5:53:13 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup is new
[09-24-25 5:53:13 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup image file found, file: /images/Win11
[09-24-25 5:53:13 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup 1 client found
[09-24-25 5:53:13 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup sending on base port 64622
[09-24-25 5:53:13 am] | Command: /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 240 --mcast-rdv-address 192.168.77.254 --portbase 64622 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win11/d1p1.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 24 --mcast-rdv-address 192.168.77.254 --portbase 64622 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win11/d1p2.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 24 --mcast-rdv-address 192.168.77.254 --portbase 64622 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win11/d1p3.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 24 --mcast-rdv-address 192.168.77.254 --portbase 64622 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win11/d1p4.img;
[09-24-25 5:53:13 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup has started
[09-24-25 5:53:23 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup is already running with pid: 3753
[09-24-25 5:53:33 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup is already running with pid: 3753
[09-24-25 5:53:43 am] | Task ID: 16 Name: Multicast Quick Deploy - testGroup is already running with pid: 3753

I've attached an image of my multicast settings within FOG.
![multicastFogSettings.jpeg](/assets/uploads/files/1758694967352-multicastfogsettings.jpeg)
(/assets/uploads/files/1758695329020-f2dd9e34-65e5-4700-a710-70a0a7ae7b5d-multicastfogsettings.jpeg)

I found the issue!

The udpsender path on my system was “/usr/sbin/udp-sender”

The path that is set within config.class.php is:

define('UDPSENDERPATH', '/usr/local/sbin/udp-sender');

I ran the following and restarted the FOGMulticastManager to resolve:

sudo ln -s /usr/sbin/udp-sender /usr/local/sbin/udp-sender

And we have logs now! Time to begin multicast testing 🥳