• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login

    Multicast does not work to multiple clients - only to single client

    Scheduled Pinned Locked Moved
    FOG Problems
    6
    12
    11.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • I
      ID10Tea
      last edited by

      I’m keeping an eye on this one. I have the same problem.

      1 Reply Last reply Reply Quote 0
      • A
        afmrick
        last edited by

        Just more information:

        I’m trying this again manually from the command line:
        From the server i am running:[CODE]udp-sender --file /opt/fog/log/multicast.log --ttl 32 --min-receivers 2[/CODE]
        and from two different clients I’m running:[CODE]udp-receiver --mcast-rdv-address <myFOGserver>[/CODE]
        …and here’swhat I get on the server:[CODE]# udp-sender --file /opt/fog/log/multicast.log --ttl 32 --min-receivers 2
        Udp-sender 2007-12-28
        Using mcast address 232.blah.blah.blah
        UDP sender for /opt/fog/log/multicast.log at <myFOGserver> on eth0
        Broadcasting control to 224.0.0.1
        New connection from <TEST-HOST-1> (#0) 00000009
        Ready. Press any key to start sending data.
        New connection from <TEST-HOST-2> (#1) 00000009
        Ready. Press any key to start sending data.
        Starting transfer: 00000009
        Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
        Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=10000
        Bad command 0200
        Bad command 0200
        Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=103166
        Disconnecting #0 (<TEST-HOST-1>)
        Disconnecting #1 (<TEST-HOST-2>)[/CODE]

        The “Bad command 0200”'s appear when I “Press any key to start receiving data!” on the clients. If I add the “–nokbd” flag to all three then I don’t get the “Bad command 0200” error but still get the “Timeout notAnswered” errors.

        To me, this suggests that the “OK Go” message is not getting communicated correctly. It still works fine to only 1 client.

        1 Reply Last reply Reply Quote 0
        • A
          afmrick
          last edited by

          We got it to work manually across or WAN by adding the following flag to [B]udp-sender[/B] command (above):
          [code]–mcast-data-address 239.blah.blah.blah[/code]
          The default [B]232[/B].blah.blah.blah is reserved/special apparently. Here’s a link that sort of breaks that down:
          [COLOR=#000000][FONT=arial][URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’][U][COLOR=#0000cc]http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml[/COLOR][/U][/URL][/FONT][/COLOR]

          To fix it in FOG, I add that command line parameter to every [B]udp-sender[/B] command in [B]/opt/fog/service/common/lib/MulticastTask.class.php[/B] and restarted all the FOG services. Everything works just the way it should have now. However, adding this parameter to every udp-sender command in the file is just a “make-it-go” hack that I’ll have to clean up next week. This should really be an option to set within FOG. …Still, Yahoo!!!

          Note: [B]blah.blah.blah[/B] is the last 3 octets of the FOG server’s IP address.

          1 Reply Last reply Reply Quote 0
          • C
            Corey Cochran
            last edited by

            Hi, I am having the same issues you have with only being able to multicast one client. I am not versed well in php. Can you send me a little more details about where in the file you inserted the address and maybe a screenshot.

            1 Reply Last reply Reply Quote 0
            • B
              Bill Klapwyk
              last edited by

              [quote=“afmrick, post: 4316, member: 417”]We got it to work manually across or WAN by adding the following flag to [B]udp-sender[/B] command (above):
              [code]–mcast-data-address 239.blah.blah.blah[/code]
              The default [B]232[/B].blah.blah.blah is reserved/special apparently. Here’s a link that sort of breaks that down:
              [COLOR=#000000][FONT=arial][URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’][U][COLOR=#0000cc]http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml[/COLOR][/U][/URL][/FONT][/COLOR]

              To fix it in FOG, I add that command line parameter to every [B]udp-sender[/B] command in [B]/opt/fog/service/common/lib/MulticastTask.class.php[/B] and restarted all the FOG services. Everything works just the way it should have now. However, adding this parameter to every udp-sender command in the file is just a “make-it-go” hack that I’ll have to clean up next week. This should really be an option to set within FOG. …Still, Yahoo!!!

              Note: [B]blah.blah.blah[/B] is the last 3 octets of the FOG server’s IP address.[/quote]
              Just started to read your thread and was going to suggest you look at CISCO devices with multi-cast issues.

              1 Reply Last reply Reply Quote 0
              • A
                afmrick
                last edited by

                [quote=“Corey Cochran, post: 4932, member: 1582”]Hi, I am having the same issues you have with only being able to multicast one client. I am not versed well in php. Can you send me a little more details about where in the file you inserted the address and maybe a screenshot.[/quote]

                Er, how to make it clearer? Let’s say your FOG server’s IP address is 192.168.1.1. Udp-sender will use [B]232[/B].168.1.1 as the data address by default. Something like [B]239[/B] might work better on your network. You can test it from the command line with something like this on your FOG server: [CODE]udp-sender --file /opt/fog/log/multicast.log --ttl 32 --mcast-data-address 239.168.1.1 --min-receivers 2[/CODE] and the following on each of your two clients: [CODE]udp-receiver --mcast-rdv-address 192.168.1.1[/CODE]

                IF that works, you could add the “–mcast-data-address 239.168.1.1” to all four udp-sender commands in [B]/opt/fog/service/common/lib/MulticastTask.class.php [/B]with whichever text editor makes you happy. The four modified lines will look something like this but, the only change was adding “–mcast-data-address 239.168.1.1”: [CODE]$cmd .= “gunzip -c “” . $strSys . “” | " . UPDSENDERPATH . " --min-receivers " . $this->getClientCount() . " --portbase " . $this->getPortBase() . " " . $interface . " --mcast-data-address 239.168.1.1 $wait --half-duplex --ttl 32 --nokbd;”;[/CODE]
                Eventually I want to add some code to define the 239.168.1.1 dynamically (in case the server IP ever changes) instead of statically assigning it but, it’s pretty low on my list right now.

                1 Reply Last reply Reply Quote 0
                • falkoF
                  falko Moderator
                  last edited by

                  [quote=“afmrick, post: 4316, member: 417”]We got it to work manually across or WAN by adding the following flag to [B]udp-sender[/B] command (above):
                  [code]–mcast-data-address 239.blah.blah.blah[/code]
                  The default [B]232[/B].blah.blah.blah is reserved/special apparently. Here’s a link that sort of breaks that down:
                  [COLOR=#000000][FONT=arial][URL=‘http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml’][U][COLOR=#0000cc]http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml[/COLOR][/U][/URL][/FONT][/COLOR]

                  To fix it in FOG, I add that command line parameter to every [B]udp-sender[/B] command in [B]/opt/fog/service/common/lib/MulticastTask.class.php[/B] and restarted all the FOG services. Everything works just the way it should have now. However, adding this parameter to every udp-sender command in the file is just a “make-it-go” hack that I’ll have to clean up next week. This should really be an option to set within FOG. …Still, Yahoo!!!

                  Note: [B]blah.blah.blah[/B] is the last 3 octets of the FOG server’s IP address.[/quote]

                  have you managed to clean this up/sort out the issue?

                  1 Reply Last reply Reply Quote 0
                  • A
                    afmrick
                    last edited by

                    I’d almost forgotten about that - we’re still using the 239 hack for now.
                    The main change I wanted to make was to dynamically find the last three octets of the FOG servers IP address instead of statically assigning it. I can imagine, if we ever had to change the FOG server’s IP, that this static assignment might cause some problems until we remember that we had done that.

                    1 Reply Last reply Reply Quote 0
                    • falkoF
                      falko Moderator
                      last edited by

                      think i may have to try your 239. hack i received a
                      gzip: stdout: Broken pipe today and multicast has been real slow. also multicast log has lots of timeout lines even though it still multicasts @ 550 mb

                      cheers for the how to

                      1 Reply Last reply Reply Quote 0
                      • L
                        Lethal Kebab
                        last edited by

                        I have just started receiving the above issue. My Multicast reaches about 50% at 4.01GiB/Min then hangs completely. I see a message in the multicast log saing:

                        Bad command 0300
                        Timeout notAnswered=[0,1] notReady=[0,1] nrAns=0 nrRead=0 nrPart=2 avg=106672

                        then

                        Dropping client #0 because of timeout
                        Disconnecting #0 (192.168.3.85)
                        Dropping client #1 because of timeout
                        Disconnecting #1 (192.168.3.170)

                        gzip: stdout: Broken pipe
                        Udp-sender 2007-12-28
                        UDP sender for (stdin) at 192.168.4.2 on eth0
                        Broadcasting control to 224.0.0.1

                        We recently upgraded all our switches to HP ProCurve 5406zl and I think this error has something to do with IGMP Snooping, not fog…

                        Multicast log shows:
                        –mcast-data-address 239.168.4.2

                        anyone else had any experience with this problem?

                        1 Reply Last reply Reply Quote 0
                        • L
                          Lethal Kebab
                          last edited by

                          Bump

                          1 Reply Last reply Reply Quote 0
                          • 1 / 1
                          • First post
                            Last post

                          201

                          Online

                          12.0k

                          Users

                          17.3k

                          Topics

                          155.2k

                          Posts
                          Copyright © 2012-2024 FOG Project