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



  • Hey everyone and @Developers ,

    Just me again with another fun multicast problem! Ha ha. It seems that multicast problems always creep up after several months of no issues. I was running trunk version 5624 for the longest time (with a special init from @Sebastian-Roth) and I just upgraded to the latest trunk to see if that would fix the problem, but it didn’t.

    As the the title says, when I attempt to do a multicast I get to this screen:

    alt text

    The multicast log shows this when I attempted to multicast to one computer:

    [05-09-16 2:55:37 pm] | Sleeping for 10 seconds to ensure tasks are properly submitted
    [05-09-16 2:55:47 pm] | 0 tasks to be cleaned
    [05-09-16 2:55:47 pm] | 1 task found
    [05-09-16 2:55:47 pm] | Task (1) Multi-Cast Task is new!
    [05-09-16 2:55:47 pm] | Task (1) Multi-Cast Task has been cleaned.
    Udp-sender 20120424
    [05-09-16 2:55:47 pm] | Task (1) /images/5516 image file found.
    Using mcast address 232.168.1.3
    UDP sender for (stdin) at 192.168.1.3 on eth0 
    Broadcasting control to 224.0.0.1
    [05-09-16 2:55:47 pm] | Task (1) 1 client(s) found.
    [05-09-16 2:55:47 pm] | Task (1) Multi-Cast Task sending on base port: 65102
    [05-09-16 2:55:47 pm] | CMD: cat /images/5516/d1p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 600 --portbase 65102 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/5516/d1p2.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 600 --portbase 65102 --full-duplex --ttl 32 --nokbd --nopointopoint;cat /images/5516/d2p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 1 --max-wait 600 --portbase 65102 --full-duplex --ttl 32 --nokbd --nopointopoint;
    [05-09-16 2:55:47 pm] | Task (1) Multi-Cast Task has started.
    [05-09-16 2:55:57 pm] | 0 tasks to be cleaned
    [05-09-16 2:55:57 pm] | 1 task found
    [05-09-16 2:55:57 pm] | Task (1) Multi-Cast Task is already running PID 9405
    [05-09-16 2:56:07 pm] | 0 tasks to be cleaned
    [05-09-16 2:56:07 pm] | 1 task found
    [05-09-16 2:56:07 pm] | Task (1) Multi-Cast Task is already running PID 9405
    [05-09-16 2:56:17 pm] | 0 tasks to be cleaned
    [05-09-16 2:56:17 pm] | 1 task found
    [05-09-16 2:56:17 pm] | Task (1) Multi-Cast Task is already running PID 9405
    [05-09-16 2:56:27 pm] | 0 tasks to be cleaned
    [05-09-16 2:56:27 pm] | 1 task found
    [05-09-16 2:56:27 pm] | Task (1) Multi-Cast Task is already running PID 9405
    New connection from 192.168.1.106 (#0) 00000009
    Starting transfer: 00000009
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:56:37 pm] | 0 tasks to be cleaned
    [05-09-16 2:56:37 pm] | 1 task found
    [05-09-16 2:56:37 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:56:47 pm] | 0 tasks to be cleaned
    [05-09-16 2:56:47 pm] | 1 task found
    [05-09-16 2:56:47 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:56:57 pm] | 0 tasks to be cleaned
    [05-09-16 2:56:57 pm] | 1 task found
    [05-09-16 2:56:57 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:57:08 pm] | 0 tasks to be cleaned
    [05-09-16 2:57:08 pm] | 1 task found
    [05-09-16 2:57:08 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:57:18 pm] | 0 tasks to be cleaned
    [05-09-16 2:57:18 pm] | 1 task found
    [05-09-16 2:57:18 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:57:28 pm] | 0 tasks to be cleaned
    [05-09-16 2:57:28 pm] | 1 task found
    [05-09-16 2:57:28 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:57:38 pm] | 0 tasks to be cleaned
    [05-09-16 2:57:38 pm] | 1 task found
    [05-09-16 2:57:38 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:57:48 pm] | 0 tasks to be cleaned
    [05-09-16 2:57:48 pm] | 1 task found
    [05-09-16 2:57:48 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:57:58 pm] | 0 tasks to be cleaned
    [05-09-16 2:57:58 pm] | 1 task found
    [05-09-16 2:57:58 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:58:08 pm] | 0 tasks to be cleaned
    [05-09-16 2:58:08 pm] | 1 task found
    [05-09-16 2:58:08 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:58:18 pm] | 0 tasks to be cleaned
    [05-09-16 2:58:18 pm] | 1 task found
    [05-09-16 2:58:18 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:58:28 pm] | 0 tasks to be cleaned
    [05-09-16 2:58:28 pm] | 1 task found
    [05-09-16 2:58:28 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:58:38 pm] | 0 tasks to be cleaned
    [05-09-16 2:58:38 pm] | 1 task found
    [05-09-16 2:58:38 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:58:49 pm] | 0 tasks to be cleaned
    [05-09-16 2:58:49 pm] | 1 task found
    [05-09-16 2:58:49 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:58:59 pm] | 0 tasks to be cleaned
    [05-09-16 2:58:59 pm] | 1 task found
    [05-09-16 2:58:59 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:59:09 pm] | 0 tasks to be cleaned
    [05-09-16 2:59:09 pm] | 1 task found
    [05-09-16 2:59:09 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:59:19 pm] | 0 tasks to be cleaned
    [05-09-16 2:59:19 pm] | 1 task found
    [05-09-16 2:59:19 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:59:29 pm] | 0 tasks to be cleaned
    [05-09-16 2:59:29 pm] | 1 task found
    [05-09-16 2:59:29 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    [05-09-16 2:59:39 pm] | 0 tasks to be cleaned
    [05-09-16 2:59:39 pm] | 1 task found
    [05-09-16 2:59:39 pm] | Task (1) Multi-Cast Task is already running PID 9405
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Timeout notAnswered=[0] notReady=[0] nrAns=0 nrRead=0 nrPart=1 avg=10000
    Dropping client #0 because of timeout
    Disconnecting #0 (192.168.1.106)
    bytes= re-xmits=0000000 ( 0.0%) slice=0112 - 0
    Transfer complete.
    
    cat: write error: Broken pipe
    Udp-sender 20120424
    Using mcast address 232.168.1.3
    UDP sender for (stdin) at 192.168.1.3 on eth0 
    Broadcasting control to 224.0.0.1
    [05-09-16 2:59:49 pm] | 0 tasks to be cleaned
    [05-09-16 2:59:49 pm] | 1 task found
    [05-09-16 2:59:49 pm] | Task (1) Multi-Cast Task is already running PID 9405
    [05-09-16 2:59:59 pm] | 0 tasks to be cleaned
    

    @Sebastian-Roth do you believe this is related to this issue that you helped me with before? https://forums.fogproject.org/topic/6295/capture-task-not-completing-after-finishing-and-then-loops/35

    All of the UDP tests I have done have worked fine. Is there anything else I can supply that would help?

    Thank you.



  • Well, I got some good news. I was able to get a successful multicast going tonight. I am not 100% sure of what fixed it. I did several things.

    Not in particular order:

    1. Updated FOG to trunk
    2. Disabled IGMP snooping from the switches
    3. Made a change to CentOS as seen here that has to do with routing (honestly don’t think this helped)
    4. Added 232.168.1.0 for FOG_MULTICAST_ADDRESS (it wouldn’t work without that)

    I plan to do more tests to really make sure it is working tomorrow and the following days. I will keep this updated if anything substantial changes.

    Thank you to everyone.



  • @Tom-Elliott Tried this with no success unfortunately. I just updated FOG to trunk to see if that would help, but that didn’t yield any positive results either.

    Would getting a pcap help at all with this? I wouldn’t know what to look for, but I could supply one I’m sure.


  • Moderator

    After doing the steps tom listed, it wouldn’t hurt to give the FOGMulticastManager a restart as well.


  • Senior Developer

    @arainero Then can you add your 232.168.1.4 address to the FOG Settings?

    FOG Configuration Page->FOG Settings->Multicast Settings->FOG_MULTICAST_ADDRESS.

    If you have to specify the port, also under the same area I think (FOG_MULTICAST_PORT_OVERRIDE) just update as well.

    Then cancel the tasking.

    Run these commands in MySQL (just to ensure all is well):

    truncate table `fog`.`multicastSessions`;
    truncate table `fog`.`multicastSessionsAssoc`;
    DELETE FROM `fog`.`tasks` where `taskTypeID`='8';
    

    Then recreate your task and test again.



  • @Sebastian-Roth

    The IP’s were different because they were different computers. The computers are all identical and are all connected to the same switch. Nothing is unique about them.

    We just tried the test on a dumb switch, the multicast failed at the same spot as usual. This is what the multcast log shows.

    [07-18-16 11:20:15 am] | CMD: cat /images/6_16_16/d1p1.img | /usr/local/sbin/udp-sender --interface eth0 --min-receivers 2 --max-wait 180 --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 --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 --full-duplex --ttl 32 --nokbd --nopointopoint;
    [07-18-16 11:20:15 am] | Task (1) Multi-Cast Task sending on base port: 50362
    [07-18-16 11:20:15 am] | Task (1) 2 client(s) found.
    [07-18-16 11:20:15 am] | Task (1) /images/6_16_16 image file found.
    [07-18-16 11:20:15 am] | Task (1) Multi-Cast Task has been cleaned.
    

    Using --mcast-data-address 232.168.1.4 worked when testing manually, like the others.


  • Developer

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



  • @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)

    alt text


  • Senior Developer

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


  • Developer

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



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

    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.
    alt text

    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?

    alt text


  • Moderator

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


  • Developer

    @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

  • Moderator

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



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


  • Moderator

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



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


  • @Wayne-Workman

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


  • Developer

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


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.