Revision history [back]

My situation is this:

• I've got a Mac Mini (2018 Intel) running Sequoia 15.4.1, connected via its built-in Ethernet port to a switch. Nothing else on the LAN.
• There are several programs running on the Mac that communicate via layer 2 Ethernet packets (IEEE 1722/1772.1 to be specific)
• These programs can communicate with each other, but only when Wi-Fi is enabled on the Mac.
• Similarly, I can use WireShark to monitor the layer 2 / 1722 traffic being generated by these programs, but only when Wi-Fi is enabled on the Mac.
• If I disable Wi-Fi, neither WireShark nor any of the layer-2 communicating programs ever receive any of the packets.

Does anyone have any insight into what is going on here? I would like to find a way for the layer 2 communication to work as expected regardless of whether Wi-Fi is enabled or not, since AFAIK the behavior of traffic on the wired interface shouldn't depend on the state of the (unrelated) Wi-Fi interface.

My situation is this:

• I've got a Mac Mini (2018 Intel) running Sequoia 15.4.1, connected via its built-in Ethernet port to a switch. Nothing else on the LAN.
• There are several programs running on the Mac that communicate via layer 2 Ethernet packets (IEEE 1722/1772.1 1722.1 to be specific)
• These programs can communicate with each other, but only when Wi-Fi is enabled on the Mac.
• Similarly, I can use WireShark to monitor the layer 2 / 1722 1722.1 traffic being generated by these programs, but only when Wi-Fi is enabled on the Mac.
• If I disable Wi-Fi, neither WireShark nor any of the layer-2 communicating programs ever receive any of the packets.
• If I add other computers to the LAN, the Mac programs receive their layer 2 / 1722.1 packets in all cases (i.e. whether or not Wi-Fi on the Mac is enabled). That is, the packet-routing issue is limited to 1722 traffic that is both sent and received (or not received) within the Mac itself.

Does anyone have any insight into what is going on here? I would like to find a way for the layer 2 communication to work as expected regardless of whether Wi-Fi is enabled or not, since AFAIK the behavior of traffic on the wired interface shouldn't depend on the state of the (unrelated) Wi-Fi interface.

My situation is this:

• I've got a Mac Mini (2018 Intel) running Sequoia 15.4.1, connected via its built-in Ethernet port to a switch. Nothing else on the LAN.
• There are several programs running on the Mac that communicate via layer 2 Ethernet packets (IEEE 1722.1 to be specific)
• These programs can communicate with each other, but only when Wi-Fi is enabled on the Mac.
• Similarly, I can use WireShark to monitor the layer 2 / 1722.1 traffic being generated by these programs, programs on the wired interface, but only when Wi-Fi is enabled on the Mac.
• If I disable Wi-Fi, neither WireShark nor any of the layer-2 communicating programs ever receive any of the packets.
• If I add other computers to the LAN, the Mac programs receive their layer 2 / 1722.1 packets in all cases (i.e. whether or not Wi-Fi on the Mac is enabled). That is, the packet-routing issue is limited to 1722 traffic that is both sent and received (or not received) within the Mac itself.

Does anyone have any insight into what is going on here? I would like to find a way for the layer 2 communication to work as expected regardless of whether Wi-Fi is enabled or not, since AFAIK the behavior of traffic on the wired interface shouldn't depend on the state of the (unrelated) Wi-Fi interface.

My situation is this:

• I've got a Mac Mini (2018 Intel) running Sequoia 15.4.1, connected via its built-in Ethernet port to a switch. Nothing else on the LAN.
• There are several programs running on the Mac that communicate via layer 2 Ethernet packets (IEEE 1722.1 to be specific)
• These programs can communicate with each other, but only when Wi-Fi is enabled on the Mac.
• Similarly, I can use WireShark to monitor the layer 2 / 1722.1 traffic being generated by these programs on the wired interface, but only when Wi-Fi is enabled on the Mac.
• If I disable Wi-Fi, the Mac's Wi-Fi interface, neither WireShark nor any of the layer-2 communicating programs ever receive any of the locally-generated 1722.1 packets.
• If I add other computers to the LAN, the Mac programs receive their layer 2 / 1722.1 packets in all cases (i.e. whether or not Wi-Fi on the Mac is enabled). That is, the packet-routing issue is limited to 1722 traffic that is both sent and received (or not received) within the Mac itself.

Does anyone have any insight into what is going on here? I would like to find a way for the layer 2 communication to work as expected regardless of whether Wi-Fi is enabled or not, since AFAIK the behavior of traffic on the wired interface shouldn't depend on the state of the (unrelated) Wi-Fi interface.

My situation is this:

• I've got a Mac Mini (2018 Intel) running Sequoia 15.4.1, connected via its built-in Ethernet port to a switch. Nothing else on the LAN.
• There are several programs running on the Mac that communicate via layer 2 Ethernet packets (IEEE 1722.1 to be specific)
• These programs can communicate with each other, but only when Wi-Fi is enabled on the Mac.
• Similarly, I can use WireShark to monitor the layer 2 / 1722.1 traffic being generated by these programs on the wired interface, but only when Wi-Fi is enabled on the Mac.
• If I disable the Mac's Wi-Fi interface, neither WireShark nor any of the layer-2 communicating programs ever receive any of the locally-generated 1722.1 packets.
• If I add other computers to the LAN, the Mac programs receive their layer 2 / 1722.1 packets in all cases (i.e. whether or not Wi-Fi on the Mac is enabled). That is, the packet-routing issue is limited to 1722 traffic that is both sent and received (or not received) within the Mac itself.

Does anyone have any insight into what is going on here? I would like to find a way for the layer 2 communication to work as expected regardless of whether Wi-Fi is enabled or not, since AFAIK the behavior of traffic on the wired interface shouldn't depend on the state of the (unrelated) Wi-Fi interface.