This article describes why Shure device discovery in Wireless Workbench (WWB) may fail on macOS systems when the network interface is using a self-assigned (169.254.x.x) IP address, and how to resolve the issue on NETGEAR fully managed (ProAV) switches.
This article explains the multicast behavior on macOS, the impact on IGMP-based discovery, and the configuration steps required to restore discovery when link-local addressing cannot be avoided.
This article applies to all NETGEAR fully managed (ProAV) switches, including the M4250 series, M4300 series, and M4350 series.
Note: Before you apply this workaround:
- Ensure that a macOS system is running the Shure Wireless Workbench.
- Ensure that Shure devices that are connected to the same Layer 2 network.
- Ensure that one or more NETGEAR fully managed (ProAV) switches are present in your network.
- Ensure that administrative access is secured to the device UI or CLI.
- Ensure that the MacOS network interface is using a link-local (169.254.x.x) address.
- Ensure that IGMP snooping is enabled. This is the default behavior.
We recommend to use static IP addressing or DHCP. This issue only occurs when MacOS is operating with a self-assigned link-local address.
Background
In some ProAV deployments, Shure device discovery might fail when using MacOS with a link-local IP address.
In these cases:
- Shure devices are visible immediately from Windows systems
- The same devices are not discovered on MacOS
- Forcing multicast on the switch port temporarily resolves the issue
This behavior is not specific to Shure hardware and is not caused by a switch defect. It is the result of how MacOS handles multicast control traffic when operating in a link-local networking mode.
Why this issue occurs
When MacOS assigns a self-assigned (169.254.x.x) address to a network interface, the operating system places the interface into a link-local mode. In this mode, MacOS assumes:
- There is no routed network.
- All communication must remain strictly within the local broadcast domain.
- Multicast traffic must not traverse any Layer 3 boundary.
As part of this behavior, MacOS modifies how IGMP packets are generated in the following ways:
- macOS sets the IGMP TTL value to 255
- IGMP packets are expected to use a TTL of 1
- A TTL of 255 does not conform to standard IGMP behavior
Because of this, the switch correctly treats the packet as invalid and drops it, preventing multicast-based discovery from functioning.
With Windows, this behavior does not occur. Even when using a link-local address, Windows continues to send IGMP packets with a TTL of 1, allowing discovery to work normally.
Recommended solution:
Configure the network to use DHCP or static IP addressing instead of link-local APIPA addresses.
When MacOS operates with a valid IP configuration:
- IGMP packets use the correct TTL
- Multicast discovery functions normally
- No switch-side workaround is required
Alternative solution (when link-local addressing cannot be avoided)
Add a static multicast forwarding entry on the switch so that Shure discovery packets are flooded regardless of IGMP registration.
The Shure discovery multicast address is:
- IP: 239.255.254.253
- MAC: 01:00:5e:7f:fe:fd
You must this entry on each switch that has Shure devices attached to them and forwards discovery traffic to the MacOS system.
Use one of the following configuration methods:
Using the device UI:
- If you are using the Engage Controller:
- Click Devices.
- Click the three dots next to the switch.
- Select Launch Switch UI.
- If you are using the switch stand-alone, navigate in the browser to the switch IP, select Main UI Login, and login.
- Select Security > Traffic Control > MAC Filter.
- Click Create Filter and add MAC address 01:00:5e:7f:fe:fd.
- Select the appropriate ports.
- Verify the entry displays in Multicast > MFDB > MFDB Table.
Using the CLI:
1. Log into the switch using a terminal application (PuTTY, TeraTerm, etc.)
2. Enter enable and configuration mode:
(Netgear Switch)> enable
(Netgear Switch)# configure
3. Apply the following commands:
(config)# macfilter 01:00:5E:7F:FE:FD 1
(config)# interface 1/0/10-1/0/16
(interface)# macfilter addsrc 01:00:5E:7F:FE:FD 1
(interface)# macfilter adddest 01:00:5E:7F:FE:FD 1
Note: In this example, we use interface 10 to 16. You can adjust accordingly to your requirements
4. Exit configuration mode and save the configuration.
(interface)# end
# save
Conclusion
Shure discovery issues on MacOS when using link-local addressing that are caused by intentional MacOS behavior that modifies IGMP packet TTL values. While valid from an OS design perspective, this behavior does not align with standard IGMP expectations on managed switches.
If you use DHCP or static IP addressing, you can avoid the issue entirely. When you cannot avoid using link-local addressing, you can add a static multicast forwarding entry to provide a reliable workaround.