Ask Your Question
0

How to view layer 2 packets on a Mac's wired interface when Wi-Fi is disabled?

asked 2025-05-09 14:54:53 +0000

jfriesne gravatar image

updated 2025-05-09 17:07:17 +0000

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.

UPDATE: WIth a bit more testing, I discovered that I can also obtain the desired behavior by connecting a second wired Ethernet NIC between my Mac Mini and the switch. So it appears the entry condition for the fault is having just a single network-path between the Mac Mini and the switch, rather than being something Wi-Fi specific.

edit retag flag offensive close merge delete

Comments

So which interface is the Wi-Fi interface (en0?) and which is the Ethernet interface (en1?)?

Guy Harris gravatar imageGuy Harris ( 2025-05-09 16:47:19 +0000 )edit

On my Mac, en0 is the built-in wired NIC and en1 is WiFi.

jfriesne gravatar imagejfriesne ( 2025-05-09 17:08:54 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2025-05-09 20:06:52 +0000

Guy Harris gravatar image

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.

Ethernet adapters rarely, if ever, receive their own traffic. OS networking stacks catch attempts to send traffic to yourself and wrap it around internally; the traffic is not sent out on the Ethernet

At least in macOS and, I think, other *BSD OSes - and on Linux - that traffic will be rerouted over the loopback adapter.

So, if, for example, you use the ping command to ping your own IP address, and try to capture on the network interface with that IP address, you will not see that traffic - you will have to capture on the loopback interface (lo0 on *BSDs such as macOS, lo on Linux).

I don't know what mechanism your programs are using to send and receive IEEE 1722.1 packets. It may be that the mechanism in question is doing something odd if you try to send those packets to your own MAC address on en0.

edit flag offensive delete link more

Comments

AFAICT the programs are sending/receiving the packets using /dev/bpf

jfriesne gravatar imagejfriesne ( 2025-05-09 20:31:46 +0000 )edit

AFAICT the programs are sending/receiving the packets using /dev/bpf

Then they have chosen a particular interface on which to send them, and that's a low-level code path that may not do the wrapping around.

I.e., if you open a BPF device and bind it to "en0" or "en1" and send a package to the interface's own MAC address, the interface will probably not see it, especially if it's an Ethernet interface.

They might want to look at PF_NDRV sockets, instead - see https://newosxbook.com/bonus/vol1ch16..., https://lists.apple.com/archives/macn..., and https://stackoverflow.com/questions/1.... Maybe that will handle sending packets on a particular interface o the same interface, but there are no guarantees.

Guy Harris gravatar imageGuy Harris ( 2025-05-11 19:51:21 +0000 )edit

Hmm, I tried the PF_NDRV example; I could use it to receive packets from computer A on computer B, but it didn't seem to receive packets from computer A on computer A. I think it has the same issue.

jfriesne gravatar imagejfriesne ( 2025-05-12 22:23:02 +0000 )edit

Hmm, I tried the PF_NDRV example; I could use it to receive packets from computer A on computer B, but it didn't seem to receive packets from computer A on computer A. I think it has the same issue.

Then the program sending the packets may have to send them on lo0 if sending them to packets on the same host; unfortunately, the loopback interface doesn't support Ethernet-style packets, so that might be impossible. Perhaps looping back isn't necessary on Wi-Fi.

Guy Harris gravatar imageGuy Harris ( 2025-05-13 00:22:34 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

Stats

Asked: 2025-05-09 14:54:53 +0000

Seen: 79 times

Last updated: May 09