I repeated the above procedure only one time and multicast failed to my horror.

This failure of multicast is totally unpredictable.

Jaymes, the syntax sudo stop tftpd-hpa does in fact work. It is confirmed on the following line that tftpd is not running.
But I will use the syntax you recommend from now on.

You wrote: [B]If I were you I would manually type the commands at the restart of the server.[/B]
A have done that [U]everytime[/U] as I listed above. Multicast works sometimes and not others.
This is crazy. I had the TFTP problem with the old fogserver and old HP clients. But that was easily fixed with the start stop syntax.
Never had a problem with multicast, if that is in fact the real problem here.

Reboot
Log in window appears
Have not logged in.
Wait 1 minute.
Multicast to 3 PCs
TFTP… waiting
Cancel fog tasks
Log in to fogserver
Wait 1 minute
Multicast to 3 Pcs
TFTP…
Cancel fog tasks
sudo service tftpd-hpa restart
Multicast to 3 PCs
TFTP works
Multicast failed - same white window with blue frame
Cancel fog tasks

Reboot fogserver
Log in
wait 1 minute
sudo service tftpd-hpa restart
Multicast to 3 PCs
Multicast failed !!! (strange, I thought this would work now)
Cancel fog tasks

Reboot fogserver
Log in
wait 1 minute
sudo service tftpd-hpa restart
Multicast to 3 PCs
Multicast failed again !!!
Cancel fog tasks

Reboot fogserver
Log in
wait 1 minute
sudo stop tftpd-hpa
sudo start tftpd-hpa
Multicast to 3 PCs
Multicast Worked (note that this time I stopped tftp first and then started it 10 seconds later)

I am now going to reboot fogserver and repeat the above procedure 2 more times to confirm working with stop and then start.

Tom you wrote:

Shouldn’t the proper commands to restart the service be:
Code:
sudo service tftpd-hpa restart
I just realized that you are probably referring to the script used in rc.local? I thought you were commenting on when I wrote:

This time I rebooted fogserver, logged in, waited 2 minutes,
sudo stop tftpd-hpa
sudo start tftpd-hpa

I have now used the following line in rc.local, including sudo:

/bin/sleep30 && sudo /etc/init.d/tftpd-hpa restart

Have now multicast the Ubuntu-12 image to the same classroom of old HPs - as expected did not work.
Then for the 3rd time I multicast Win 8.1 successfully to the 3 same new HPs.

3 successful multicasts of Win 8.1
1 failed multicast of Ubuntu to old HPs.

I suspect Firefox or LibreOffice may be the culprits.
I know it is not good practise to use other programs on a dedicated server, but it makes it so much easier to to get this fog stuff done and sorted by using Firefox and LibreOffice on fogserver.

OK I am going to work through this systematically.
I am not touching the fogserver desktop. (remember I only logged in and then stopped and started tftpd-hpa.)
I am now multicasting again for a 2nd time succesfully to the 3 clients. To prove that it wasn’t a one off fluke. It can be repeated.

Now it is working (multicast to the same 3 new PCs)

Trying to understand the sequence of events that leads to it not working and then working.

This time I rebooted fogserver, logged in, waited 2 minutes,
sudo stop tftpd-hpa
sudo start tftpd-hpa

From my PC - multicast to 3 PCs which worked

Multicast does not work again.

TFTP is still not running despite the mod to /etc/rc.local

Here is a copy of the file. Is there anything wrong?

#!/bin/sh -e

rc.local

This script is executed at the end of each multiuser runlevel.

Make sure that the script will “exit 0” on success or any other

value on error.

In order to enable or disable this script just change the execution

bits.

By default this script does nothing.

/bin/sleep30 && /etc/init.d/tftpd-hpa restart
exit 0

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

In order to enable or disable this script just change the execution

bits. (no idea what this means. Do I need to enable this script?)

Tom I just read your comment from last year:
[I]Has anyone in this thread found this issue with 0.33b? Maybe I can append/sed the command into the installation so nobody has to worry about this! [/I]

Sounds like a good idea[I].[/I]

Probably need to implement the delayed startup of TFTP that’s been mentioned earlier.
Obviously that will solve the TFTP … (waiting) on the clients.

But could there also be a connection between this and the image not being multicasted?

I hope a delayed startup of tftpd-hpa will also solve the multicast problem and eliminate the need to reboot fogserver.

When it comes to computers, I just seem to attract bugs and issues.
Computers are not impressed with my natural charm and charisma

I’m so tired and stressed out about this that I didn’t think of the obvious Jaymes that you did think of.
I did what you said.
fogserver, win server 2012, my PC and 2 clients (I used the win server because it was quicker - it had DHCP)

Same result, waiting for image… BUT.

Rebooted fogserver
TFTP …
Restarted tftpd-hpa

Then multitasking worked to the new PCs!!!
Have to go home now. Thanks Jaymes.

The Cisco switch says: By default, all Multicast frames are flooded to all ports of the VLAN

Palo Alto - have not found any relevant info. The guy that helps me with the PaloAlto is uncontactable.

One thing is clear here - everything is in 1 broadcast domain, so it’s unlikely that multicasting has been filtered.

I’m stuck.

[I]We don’t mind helping out but you need to start searching for the basic info you are looking for especially when it’s related to your own hardware. [/I]

Absolutely.

Although we have 6 VLANS, everything we are talking about here is in the same VLAN-1 and physically connected to the same switch.
I’m not sure how to find out if multicast has been disabled or not. But it was not disallowed before, before we set up the VLANS.
Isn’t it normal by default to have multicast enabled in each VLAN?

Our gateways for all our VLANS are on a new PaloAlto PA-200 firewall. Not sure if that is creating a problem for multicast packets.
I’m looking at the PaloAlto user interface but cannot find any reference to multicast traffic yet.

But isn’t it normal by default to have multicast enabled in each vlan?

That’s a good point about multicast because I have just set up a new multi VLAN network on pre-existing switches.
Maybe multicast has been disallowed. hmmm

No the deployment to a single old HP did not work. Exactly the same result as with the multicast to those old HPs yesterday.

Now I’ll try to write down the error messages on both old and new HPs.

The multicast to 3 new USDT PCs stopped, froze waiting at the PartClone white window in a blue frame.

With one line of text at top:
Starting to restore image (-) to device (/dev/sda1)

Notice the image is (-)

Looks like multicast is not finding the image, the same image I have just sent successfully to one of these 3 PCs.

This would also explain why the multicast to the old HPs did not work.

I will now try deploying Linux to a single old HP PC in the same classroom where the Linux multicast did not work yesterday.
I’m hoping that might work, showing that the problem is in multicast.

Tried sending a single image to one of the NEW Elite 8300 USDT.
It worked!
This means that most things must be correct on the fogserver and server 2012 domain controller.
I will now try a multi cast deploy to 3 of the new USDT. If that works, then that points to a problem with the old HP DC7100 PCs or the Linux image or the network in that classroom.

Server 2012
066 = 10.0.1.40 which is the new fogserver.

I’m too tired to do this now. I need to go home now. It’s 10PM.