Linux – openSUSE 11.3 multicast IGMP v2 works on one vlan, but not the other vlan

You can use "ip maddr add" to subscribe to additional groups. That should cause the kernel to respond to IGMP queries and receive traffic for them.

The problem is shown in the first packet capture, where you will notice that the IGMP group join packet is an IGMPv2 packet, but the responses from the IGMP querier are all v3.

This may seem fine, since macOS has supported IGMPv3 for a very long time now, but if you dig into the IGMP implementation in the Darwin open source kernel, down in igmp_input_v3_query(), you find this enlightening bit of code:

/*
 * Discard the v3 query if we're in Compatibility Mode.
 * The RFC is not obviously worded that hosts need to stay in
 * compatibility mode until the Old Version Querier Present
 * timer expires.
 */
if (igi->igi_version != IGMP_VERSION_3) {
    ...etc...

What this means is that macOS is obeying the IGMPv3 spec and putting any network interface where it has seen IGMPv2 packets into "compatibility mode," meaning that it will neither acknowledge IGMPv3 packets nor speak IGMPv3 on that network interface. In terms of the code above, it marks the interface as igi_version = 2, so we'll hit this test and ignore the v3 group membership query on the theory that it is unsafe to speak v3 on this network, lest the v2 devices be unable to understand what's going on.

I see three workable remedies:

1. Get those in charge of the network to reconfigure their switches to send back IGMPv2 queries to clients that asked for an IGMPv2 group join.

2. Turn off IGMPv3 support in the IGMP-aware network switches entirely, so that they will only send out IGMPv2 membership queries.

3. Monitor the network for IGMPv2 packets, find their source, and fix, upgrade, or remove them. If the network can't be made to speak v3 thru-and-thru, go with #1 or #2.

This is not something you can fix with an application code change. The IP_ADD_MEMBERSHIP option to setsockopt() doesn't include a version number, so the app is not in a position to demand IGMPv3. That decision is up to the stack.

While it is possible that there is an OS setting that would affect this, that could only be the case if the macOS IGMP implementation differs from what we see in the igmp.c linked above.

If you sniff the network for IGMP on a Windows box, you will see that it responds to IGMPv3 membership queries with v3 responses, despite the presence of v2 on the network. It is therefore in violation of the RFC; while some network admins who will say, "Well, it works, doesn't it?," the proper response must be that because you cannot force macOS to also disregard the RFC, the solution remains to fix the network.