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?

  • Are you literally using -i any - or is "any" just a placeholder that you replace with the actual NIC when running tcpdump? This is important, as when you use an actual NIC, it will be set to promiscuous mode, as A.B. explains. But if it is "any", then it won't be set to promiscuous mode and we need to look for something else. Commented Jan 27, 2021 at 23:29

1 Answer 1


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(""), imr_interface=inet_addr("")}, 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

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.

  • 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. Commented Nov 8, 2019 at 5:59
  • Very helpful answer! As OP is using -i any however, his NIC(s) won't be put into promiscuous mode (see man tcpdump). Also, in his comment, he clarifies that he does do IGMP joins, so the problem seems to lie somewhere else. I'm in the same situation right now (with the exception that I'm using tcpdump on a specific interface, so my interface does get put into prom. mode), and my app is doing the necessary IGMP joins, too. It works on other machines. So there must be some other explanation for this... In my case, Fwiw, I'm using tcpreplay-edit on another machine to the send multicast data, Commented Jan 26, 2021 at 23:44
  • @EvgeniyBerezovsky OP states using tcpdump -i any helps, but indeed when I test with any (rather than a single interface) no interface is put in promiscuous mode, so I'm now wondering. I'd need more feedback from OP.
    – A.B
    Commented Jan 27, 2021 at 9:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .