UNSOLVED Multicast does not start after quick inventory

  • I have several machines fresh built. If I set up a multicast to a fresh built computer without Quick Registration and Inventory, it works perfectly. If I perform Quick Registration and Inventory, I can no longer multicast to that machine - the client just waits forever at the Partclone window. I have tested this on four computers so far and can repeat the failure every time. If I delete the host entry in the database, it still fails. Once the machine is inventoried, it will no longer multicast.

    FOG version 1.5.7
    There are no errors or events that I can see in the logs.
    FOGMulticastManager is running and udp-sender is running.

  • Senior Developer

    @processor In this case I’d ask you to update to the latest development version. There is a minor issue with 1.5.7 on Ubuntu and it’s better you use the latest version in case we still need to work on fixing the multicast issue.

    sudo -i
    apt-get update
    apt-get install git
    git clone https://github.com/FOGProject/fogproject
    cd fogproject
    git checkout dev-branch
    cd bin

  • @Sebastian-Roth

    Hi I’m using fog 1.5.7 (upgrade from 1.5.6 and/or 1.5.5, I could not remember) on ubuntu 16.04.3.

    I used the the script in the tar file to install it.


  • Senior Developer

    @processor Which version of FOG do you have currently installed? Which method did you use to install (tar.gz/ZIP or git)? Which Linux OS version do you use?

    Depending on your answers I will give you detailed instructions.

  • @Sebastian-Roth

    Hi Sebastian,

    thanks for your answer. Sorry but I don’t now how to do this.

  • Senior Developer

    @processor Could you possibly update to dev-branch and try again. I just found there was a major fix pushed to multicast manager: https://github.com/FOGProject/fogproject/commit/77a94cf43a32b856f49f34b94fed1b4a019a1406

  • Hi,

    I exactly have the same behaviour.

    I mean if I create a multicast session for 2 machines and I join with 2 already registered PCs, the session won’t start,
    whereas it does with 2 unregistered ones.

    This is what I see from Images>Multicast

    This what I have in active tasks :


    And this in Active Multicast :


    In shell this is what “ps aux | grep udp” gives :

    root      3571  0.0  0.0   4500   744 ?        S    09:57   0:00 sh -c /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 64776 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img;/usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 10 --portbase 64776 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p2.img;
    root      3572  0.0  0.0   8704   828 ?        S    09:57   0:00 /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 64776 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img
    root      7774  0.0  0.0   4500   844 ?        S    10:35   0:00 sh -c /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 62458 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img;/usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 10 --portbase 62458 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p2.img;
    root      7775  0.0  0.0   8704   828 ?        S    10:35   0:00 /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 62458 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img
    root     11289  0.0  0.0   4500   852 ?        S    11:09   0:00 sh -c /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 55058 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img;/usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 10 --portbase 55058 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p2.img;
    root     11290  0.0  0.0   8704   780 ?        S    11:09   0:00 /usr/local/sbin/udp-sender --interface ens32 --min-receivers 2 --max-wait 300 --portbase 55058 --full-duplex --ttl 32 --nokbd --nopointopoint --file /mnt/FOG_iSCSI/FOG/W10_Remote_20191029/d1p1.img
    fog-adm+ 11896  0.0  0.0  14228   868 pts/0    S+   11:20   0:00 grep --color=auto udp

    I have only one session running. Is it normal to get so much processes?

  • Senior Developer

    @Rivybeast Sorry this has gone lost on my side. Are you still around!?

  • Is the udp-sender command built from anything in the host inventory on the server? We also modify the DMI area of the motherboards, e.g. manufacturer, model, serial number, etc… I’m no programmer by any means, but I was thinking if we were putting a character in there that isn’t being parsed correctly (spaces, parenthesis, etc.), could that cause the built udp-sender command to fail? We also don’t name the machines, we just let FOG use the MAC address to name them.

  • Senior Developer

    @Rivybeast This still doesn’t make sense to me. Not saying it’s not possible but I just don’t understand how registering the clients should break multicasting in general.

    Please try scheduling a multicast session using the groups to see if that works for you.

  • I was multicasting to a single machine only for testing. I had previously been multicasting to 16 at a time. If any one of the 16 is registered, then the whole multicast session hangs. I usually schedule it manually with session ID, something simple like 1 or a.

    This problem seems to be occurring more with certain motherboards, the Asus H310M-E R2.0, and the Asus B360M-C/CSM specifically. I have tried this with HP, Dell, and older Asus boards and there doesn’t seem to be a problem multicasting. I have tried every possible combination of settings in the BIOS of these boards and cannot find any reason why they would not work only after being registered.

  • Senior Developer

    @Rivybeast I am fairly sure I have tested multicast deploy before we released 1.5.7 and I usually register the test machines as this is the workflow I am used to.

    I can no longer multicast to that machine - the client just waits forever at the Partclone window

    To me this sounds like you are multicasting to a single machine. While it shouldn’t be impossible to do I am still wondering why one would do this?!? There is a slight chance this is not working in 1.5.7 simply because it’s not something I would test as multicasting to a single machine doesn’t make sense to me.

    Does multicast to more than one machine work? How do you schedule the multicast session - through groups or manually with session ID?