Multicast Task Completing immediately

[adowns]

I am on Trunk 1.5.2 installed on a Debian server. Trying to get a multicast session setup and having an interesting issue. I create the Session for my Windows 7 x64 Image for multicast. I set the session name, client count and timeout and click start. The session shows under Current Sessions for a moment or 2 and then disappears. No active multicasting tasks shown. In the multicast.log it shows the following:

[05-11-18 12:00:39 pm] | Task (10) Batch6 is new!
[05-11-18 12:00:39 pm] | Task (10) /images/Win7x64 image file found.
[05-11-18 12:00:39 pm] | Task (10) Batch6 12 clients found.
[05-11-18 12:00:39 pm] | Task (10) Batch6 sending on base port: 57468.
[05-11-18 12:00:39 pm] | Command: /usr/local/sbin/udp-sender --interface eth0 --min-receivers 12 --max-wait 600 --portbase 57468 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win7x64/d1p1.img;/usr/local/sbin/udp-sender --interface eth0 --min-receivers 12 --max-wait 10 --portbase 57468 --full-duplex --ttl 32 --nokbd --nopointopoint --file /images/Win7x64/d1p2.img;
[05-11-18 12:00:39 pm] | Task (10) Batch6 has started!
[05-11-18 12:00:39 pm] | Cleaning 1 task as they have been removed
[05-11-18 12:00:39 pm] | Task (10) Batch6 is being cleaned.
[05-11-18 12:00:39 pm] | Task (10) Batch6 has been completed.

No clients imaged since I didn’t have any time to initiate a connection. Any help would be appreciated.

P.S. The multicast Session names appear to not be able to be reused, Is this just for the day or does this function always need a unique session name?

[Tom Elliott]

@adowns the session names cannot be reused if another session is already in place witch that session name. Once the session is removed it should blank the name field out.

That said I’m aware of a problem with multicast sessions but haven’t been able to pinpoint what it is.

[maxabercrombie]

@adowns Seems like it is the same issue i’m having.

I’ve detailed in the topic I raised how I get this to ‘work’ for a small number of machines, but I would not call it a fix by any stretch of the imagination.

There is definately an underlying issue, and Tom is aware.

Please see https://forums.fogproject.org/topic/11799/1-5-2-on-debian-multicast-session