0

We are developing communication interface converter which is running Linux.

The unit may receive unicast or multicast IP and converts it to some other physical layer. On the other hand, the unit receive the data and sends out the unicast/multicast IP without changing the the content received for the first unit. The data is sent based on application configuration.

In addition, the first unit has some internal device which creates some multicast data which shall be sent toward the second unit.

My problem is that the multicast from this device is received on the 2nd unit only when one executes tcpdump

'tcpdump -i any host '

What's going on? What does the tcpdump performs?

2

TL;DR: run ip link set dev eth0 allmulticast on to work around your problem (adapt the card's name). Fixing it correctly could mean modifying your application to be multicast-aware and join (IPv4) multicast groups it's interested in.

tcpdump puts the interface in promiscuous mode unless told otherwise (-p), which means it will transmit to the system any ethernet frame seen, even if not sent specifically to the card ('s MAC address). You can verify that using tcpdump with the additional -p option will not make your setup work anymore.

Based on this, that means your interface was never told to listen to multicast traffic and will receive only unicast ethernet frames with only its own MAC address as destination address (as well as broadcast frames). Normally your application is supposed to use socket options to join IPv4 multicast groups like this example captured from strace:

setsockopt(5, SOL_IP, IP_ADD_MEMBERSHIP, {imr_multiaddr=inet_addr("239.255.1.5"), imr_interface=inet_addr("192.0.2.2")}, 12) = 0

... which among other effects will register an additional hash of the IP mapped into ethernet MAC format into the card's specific multicast MAC table. Multicast ethernet frames are simple to recognise by a card: they have the lower bit of the first byte of the destination MAC address set to 1, which happens to be the very first bit of destination MAC transmitted on the wire.

If you know in advance all the (IPv4) multicast groups in use and they are in limited number, you could compute yourself the resulting multicast ethernet MAC addresses then add them directly in the card's multicast table using something similar to this command (hash for 239.255.1.5):

ip maddress add dev eth0 01:00:5e:7f:01:05

If you can't do this, you can still configure your card to listen to all multicast traffic:

ip link set dev eth0 allmulticast on

If later a switch doing IGMP snooping is inserted, this might not be enough anymore without proper application change.

You can use socat to test with multicast.

| improve this answer | |
  • Thank you for your response. "Based on this, that means your interface was never told to listen to multicast traffic..." - as mentioned, based on the application configuration the unit may receive multacast messages by sending IGMP join. We have some records (which may vary in their location) of IPs from which we select which we woult like to transmit to othe side. This is working with any external multicast, but the internal device causes some issue. We will test your proposal on next working day. – user1977050 Nov 8 '19 at 5:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.