1

We have a remote site where the Macs are not responding to IGMP membership queries, but the Windows boxes do respond. Consequently, after about 10 minutes, the IGMP-aware network switch cuts off the multicast stream to the Macs.

Here is a screen shot of Wireshark showing the problem:

Wireshark IGMP packet capture

The first packet is the app requesting that the network begin allowing the IGMP packets from 239.255.20.1 through to the Mac. Then you see, about every 125 seconds thereafter, the network switch configured as the IGMP querier (10.1.254.254) ask if we're still interested in that stream. Notice the conspicuous lack of response.

Here is what happens here on the local network, for comparison:

good IGMP packet capture

Here, about every 95 seconds the IGMP querier (172.20.0.2) asks if we still want that stream, and the Mac in question (172.20.0.144) says, "Yes, keep sending it."

The firewall is turned off on the problem Macs in the GUI, and I've verified it at the command line:

$ /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
Firewall is disabled. (State = 0)
$ /usr/libexec/ApplicationFirewall/socketfilterfw --getblockall
Block all DISABLED! 
$ /usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode
Stealth mode disabled 
$ /usr/libexec/ApplicationFirewall/socketfilterfw --getappblocked /Applications/mumblemutter.app/...
The application is not part of the firewall 

The app doesn't matter, since the stack handles IGMP queries after the group has been joined.

The problem Macs are running 10.11.5, but I cannot believe the problem would be fixed by upgrading to the absolute latest, since that would mean that a BSD-based OS is fixing serious bugs in its network stack in 2016. Possible, but extremely low probability.

migrated from apple.stackexchange.com Dec 9 '16 at 13:49

This question came from our site for power users of Apple hardware and software.

  • Did you check for pf firewall on OS X side explicitly - we have some users that are going ahead with apps like Murus and LittleSnitch that are rolling custom firewall configurations that you won't see at the system level from Apple's default firewall. Add to that Cisco, Kaspersky, trusteer and all the other "tools" that try to manage connectivity, security, network stacks, etc... – bmike Dec 9 '16 at 13:48
  • @bmike: Thanks, I should have thought of that, but we don't have admin passwords on the remote Macs, so we can only do this while someone is sitting in front of it and can answer sudo's demand for us. I don't expect that this will end up being the problem, though, since the igmp.c snippet I pointed to is so clear on this point. – Warren Young Dec 10 '16 at 0:15
2

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 Mac OS X 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 Mac OS X (or macOS, if you like) 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 v3 the 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 at the remote site 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 Mac OS X 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 OS X to also disregard the RFC, the solution remains to fix the network.

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.