Multicast does not start after quick inventory

[Rivybeast]

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.

[Sebastian Roth]

@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.

[Rivybeast]

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.

[Sebastian Roth]

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

[processor]

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?

[Sebastian Roth]

@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

[processor]

@Sebastian-Roth

Hi Sebastian,

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

[Sebastian Roth]

@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.

[processor]

@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.

Thx

[Sebastian Roth]

@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
./installfog.sh