UDP multicast configuration for eth0 instead of loopback, no access to external network?

[Carlos Galvez]

Hi,

We are trying to setup LCM communication between 2 devices in a LAN that does not have access to the Internet or any other external network.

In http://lcm.googlecode.com/svn/www/reference/lcm/multicast.html it is explained that for the loopback interface, we should do:

sudo ifconfig lo multicast
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev lo

What should we do in case that the data does not come from the loopback interface, but from the eth0 interface? If we just change the previous commands

replacing "lo" for "eth0" it doesn't work...

Thanks!

[Jonathan Bendes]

Can you supply the output of 'sudo route -v'? After running your command? Also the actual zcm command/code you're trying to run?

Best,
Jonathan

--
You received this message because you are subscribed to the Google Groups "Lightweight Communications and Marshalling" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lcm-users+...@googlegroups.com.
To post to this group, send email to lcm-...@googlegroups.com.
Visit this group at https://groups.google.com/group/lcm-users.
For more options, visit https://groups.google.com/d/optout.

[Carlos Galvez]

Hi,

When executing sudo route -v, we get:

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

link-local      *               255.255.0.0     U     1      0        0 eth0

224.0.0.0       *               240.0.0.0       U     0      0        0 lo

The computer that sends the data has IP 169.254.145.79. The computer that fails to receive LCM data has IP 169.254.145.242. We have checked with tcmdump and wireshark that the RX is correctly getting the UDP packets; it's just that LCM is not processing them.

The data is being sent to 169.254.145.242:8010 (instead of the multicast IP).

Despite not sending to the multicast address, sometimes LCM has managed receive and decode the data, without changing anything. It usually works when the RX is powered on before the TX. The TX has an integrated switch which is powered on at the same time as the TX.

However now we are trying the exact same code on another computer (exam same hardware and LCM installation) and it never works.

The following code is being tested:

class Handler 

{

    public:

        ~Handler() {}

        void handleMessage(const lcm::ReceiveBuffer* rbuf,

                const std::string& chan, 

                const VisualizationBus* msg)

        {

            std::cout << "Received and decoded data!" << std::endl;

        }

};

int main()

{

    lcm::LCM *lcm_ = new lcm::LCM("udpm://239.255.76.67:8010?ttl=1");

    

    if (!lcm_->good())

    {

        std::cerr << "Failed to initialize LCM" << std::endl;

        return -1;

    }

    Handler h;

    lcm_->subscribe("VisualizationBus", &Handler::handleMessage, &h);

    if(lcm_->handleTimeout(1000) > 0)

    {

        std::out << "OK" << std::endl;

    }

    else

    {

        std::cerr << "Did not receive LCM data" << std::endl;

    }

    return 0;

}

    

In red I noted the main change with respect to the example code. Hope this provides a clearer understanding of the situation!

Thanks a lot.

[Jonathan Bendes]

I might be misunderstanding your code, but is the intention to have the lcm url be udpm://239.255.75.66:8010? Or was that a typo? You would need to open the same URL on the broadcasting end to receive on that url. Did you modify the internals of LCM to achieve this? It seems that you're using the "udpm" prefix, which LCM would interpret as multicast traffic unless you've modified LCM. What OS are you running on?

Jonathan

[Carlos Galvez]

No it's not a typo. I agree that it is very weird that the code sometimes works using the multicast IP address instead of the RX IP. The key thing to make it work was to change the port to the correct one. 

We concluded this from previous tests using UDP sockets (completely unrelated to LCM). In these cases we only specified the UDP port in the code, regardless of the IP. So we figured it would be similar in this case. However we have pretty basic knowledge in networking so we don't really know why it works or why it doesn't.

In any case, yes, ideally we would like to configure LCM to listen on 169.254.145.242:8080. However according to the API we can only use "udpm://..." to receive data. Is it possible to use another prefix to receive unicast data instead? By the way we are using release 1.3.0 of LCM.

The receiver computer is running Ubuntu 14.04 64-bit.

Thanks!