FOG Multicast issue - stuck on starting to restore image - version 7547

[arainero]

@Sebastian-Roth

If I use this modifed version of that line from the log it works.

cat /opt/fog/.fogsettings | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 600 --full-duplex --nokbd --nopointopoint --mcast-data-address 192.168.1.255

I had to remove portbase and the ttl flags and add the --mcast-data-address 192.168.1.255 flag. After doing that I was able to receive the fog settings files.

I tried the command with just removing the portbase and ttl flags and not adding --mcast-data-address 192.168.1.255, but that didnt work.

[Sebastian Roth]

@arainero Why did you have to remove --ttl and --portbase?? I still think something is wrong with the network setup. From the udp-cast man page I get that it would default to use 232.168.1.x (where x would be the last byte of the server IP address). Possibly your switch is layer 3 switch and does not allow those “out of range” IPs?

[arainero]

@Sebastian-Roth I removed those to test to see if different scenarios would work. I tested with --mcast-data-address 232.168.1.255, 232.168.1.1, 232.168.1.0, etc, and those worked too.

I actually added --ttl 32 and that worked. It’s just when I add --portbase 65102 it stops working. I tried a few different port variations with no luck.

The switches in the letwork are layer 2. Multicast used to work fine and there have been no changes to the network. I will double check the switch configurations again though.

[Wayne Workman]

@arainero are you sure fog firewall is off? Some places configure special ports for use with multicast (like mine).

[Wayne Workman]

@arainero said in FOG Multicast issue - stuck on starting to restore image - version 7547:

It’s just when I add --portbase 65102 it stops working. I tried a few different port variations with no luck.

Working off of this finding - I may have a fix for you.

Open up this file on your master node:
/var/www/html/fog/lib/service/multicasttask.class.php

Comment out line 91, do that by putting two forward slashes at the beginning of the line, like this:

Then restart the FOGMulticastManager like this:
service FOGMulticastManager restart

And then try multicast again. With any luck, it’ll work.

Even if it DOES work - we need to figure out what it is about your network that’s preventing you from defining a port, I hope you understand.

[Sebastian Roth]

@arainero said:

Multicast used to work fine and there have been no changes to the network.

Can’t remember how many times I’ve heard this. But those kind of things usually don’t just stop working from one day to the other. Maybe it wasn’t you who changed anything. I really hope we can find out what’s wrong here and find a solution to it. Keeping my fingers crossed. Are you absolutely sure there are only layer 2 switches between the FOG server and the clients?

[arainero]

@Wayne-Workman

iptables and selinux are off. Firewalld is not installed either. Is there a firewall somewhere else that I have missed?

[arainero]

@Wayne-Workman I tried this with no luck, but I expected it to work as you did. I had some interesting observations.

The new command I found in the multicast log was

cat /images/6_16_16/d1p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/6_16_16/d1p2.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/6_16_16/d2p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;

As expected there were no ports involved, but the multicast still didn’t work. However, if I took the first part of it and replaced it with the fogsettings file like in the wiki test it works. (This test was the test from the wiki and not a GUI multicast)

cat /opt/fog/.fogsettings | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint

The only difference between the two commands is the file and the fact that I am running the second one manually through the terminal and receiving it manually with udp-receiver.

Is there a different process when doing this test manually compared to when it is done through the GUI?

Here is the multicast log

[07-09-16 1:08:48 pm] | Task (1) Multi-Cast Task has started.
[07-09-16 1:08:48 pm] | CMD: cat /images/6_16_16/d1p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/6_16_16/d1p2.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/6_16_16/d2p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;
[07-09-16 1:08:48 pm] | Task (1) Multi-Cast Task sending on base port: 53324
[07-09-16 1:08:48 pm] | Task (1) 1 client(s) found.
Broadcasting control to 224.0.0.1
UDP sender for (stdin) at 192.168.1.3 on eth0 
[07-09-16 1:08:48 pm] | Task (1) /images/6_16_16 image file found.
Udp-sender 20120424
[07-09-16 1:08:48 pm] | Task (1) Multi-Cast Task has been cleaned.
[07-09-16 1:08:48 pm] | Task (1) Multi-Cast Task is new!
[07-09-16 1:08:48 pm] | 1 task found
[07-09-16 1:08:48 pm] | 0 tasks to be cleaned
[07-09-16 1:08:38 pm] | Sleeping for 10 seconds to ensure tasks are properly submitted
[07-09-16 1:08:28 pm] * No tasks found!
[07-09-16 1:08:18 pm] * No tasks found!
[07-09-16 1:08:18 pm] * Starting service loop
[07-09-16 1:08:18 pm] * Checking for new items every 10 seconds
[07-09-16 1:08:18 pm] * Starting MulticastManager Service

[arainero]

@Sebastian-Roth I know, I turned into one of those people. But as far as I can tell nothing on the network has changed. It is a very basic setup. Internet comes in, hits the pfsense router which goes to a layer 2 meraki switch (which is trunked to another identical one) and out to the computers.

The only other device on the network is a wireless AP and a few gaming consoles. Other than that every computer has a direct ethernet cord to it. All of these devices were here before when multicast was working.

It truly sounds network related somehow, but I have no idea what could be causing it at this point.

On Monday I plan to hook the router (for the pxe boot routing), 2 pc’s for multicasting, and an admin computer (for the web GUI access) to a dumb switch and see what happens when I cut everything else out. That should rule out any network issues, right?

[Wayne Workman]

@arainero wait a second there, the multicast is going through the router? That could be the problem, it’s probably blocking the needed port and/or UDP traffic.

[arainero]

@Wayne-Workman The multicast doesn’t go through the router, it is just the edge device and I was just giving a brief rundown of the network and how basic it was.

As far as I know the router can’t block interlan traffic. Also, no changes have been made to the router either (I know how much you guys love hearing that).

[Wayne Workman]

@arainero

What side of the router is the fog server on? You didn’t include that part, you just said three computers on a dumb switch. Where is the fog server?

[Sebastian Roth]

@arainero Thanks for the new logs, tests and explanations. I am pretty sure we are headed the right way with that. Doing the test with a dump switch and just the FOG server and two clients on it is definitely a good idea - although your other setup also sounds quite simple. Still give it a try with that dump switch I’d say. A couple of things that got my attention:

• The timestamps in the last log output you posted are in reverse?!? That does not make any sense to me.
• two meraki switches being trunked (was this setup always like that? which trunking protocol is being used?) - I’ve never done multicasting over a trunked link
• have you ever checked on your FOG server if those udp-sender processes are actually started? After checking the log also run ps ax | grep udp
• AFAIK there should be no difference between running the command by hand and it being run by FOG when scheduling a task. But please give the following steps a try to see if it makes any difference. Schedule a multicast task for two of your clients plus unicast debug deploy tasks for another two clients. Make sure the multicast clients do not boot up (disconnect from the LAN so they don’t wake up) and start the two unicast clients. When they are up run udp-receiver --nokbd --ttl 32 --mcast-rdv-address 192.168.1.3 | gunzip > /dev/sda1

[Wayne Workman]

@Sebastian-Roth said in FOG Multicast issue - stuck on starting to restore image - version 7547:

The timestamps in the last log output you posted are in reverse?!?

In Fog’s web interface, there’s a check box to reverse the logs, that way the newest ones appear at the top. I feel it should be default, because with a large log you can’t always get to the bottom of the file by using the web interface to show 1000 lines.

[arainero]

@Sebastian-Roth

Could the time stamps be like that since I had the log sorted from top down?

Trunking might have been the wrong term. They are simply connected to each other through SFP ports with twinax cable. Like plugging a switch into another switch with ethernet.

The udp sender appears to be in working order. This is what I get after starting a multicast session:

[root@fogserv ~]# ps ax | grep udp
28869 ?        S      0:00 sh -c cat /images/6_16_16/d1p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/6_16_16/d1p2.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/6_16_16/d2p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint;
28871 ?        S      0:00 /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --mcast-data-address 232.168.1.0 --full-duplex --ttl 32 --nokbd --nopointopoint
28881 pts/1    S+     0:00 grep udp

Doing the debug test seems to have worked.

One thing I noticed that might be odd is that when I went to the task management page and to active multicast tasks it said 4 hosts. There are only 2 members in the group. Is this indicative of anything wrong?

[arainero]

@Wayne-Workman The fog server is on the LAN along with the client computers. The router is the edge device and handles the DHCP for the network.

[Sebastian Roth]

@arainero Do I get this right? You did as I suggested: started a multicast using the web gui and started the multicast receive on two clients by hand. That worked!? So why wouldn’t it work when the other two clients run into the multicast session???

Could you please do this same test again but remove the --mcast-data-address 232.168.1.0 setting. This should not be necessary I reckon. After that give it another try with a plain multicast session. But first make sure that you don’t have any old udp-sender processes running on the FOG server (ps ax | grep udp and killall udp-sender in case there are orphaned processes around) and clear the (multicast) task lists in the web gui!

[Tom Elliott]

@arainero I would think the reasoning for the maxClients to show up as 4 is because you’ve rebooted/reran the same multicast tasking for the host at least 1 per each host and possibly more times on each (maybe only one host) by hand?

[arainero]

@Sebastian-Roth Once I removed the --mcast-data-address 232.168.1.0 from the multicast settings page and attempted the manual debug multicast it didn’t work. I made sure no udp process was running in the background either. For some reason a mcast address is needed now for these tests. (This was never necessary when multicasting used to work)

[Sebastian Roth]

@arainero Why were those different IPs (.109 and .110) than last time (.127 and .128)? Did you use different clients for the test or do your clients change IP address on every reboot because they get it from a dynamic pool?

Have you tried this on just the simple setup with a dump switch yet?

Could you please run the same test again but use --mcast-data-address 232.168.1.4 for example. Just want to see what exactly this is about. Not making sense to me that it does receive the data on 232.168.1.0 but not on 232.168.1.3.