MacOS – Macs can’t see each other over an Ethernet cable. MacOS failing to set up 169.254 routing. Why? How to fix? Violates RFC 3927? Hint: multi-homed

command lineethernetmacosNetwork

(Too-wordy title: Macs connected with an Ethernet cable can't see each other – MacOS failing to set up 169.254 routing, AKA link-local address configuration. Why? How do I fix? Is it violating RFC 3927? Hint: One Mac has a normal, working Ethernet (over Wi-Fi) connection, which may make it a multi-homed host.)

I'm trying to communicate between two Macs over an Ethernet cable. This should "just work", I thought, but it does not appear that MacOS is automatically setting things up as it is supposed to.

Only after detecting there's a physical connection do the autoconf IP addresses get assigned (as shown by ifconfig en0 before vs after connection) so it's clear they CAN see each other at the physical level.

One of the Macs is (was) at the OS setup stage where it is looking for other computers on the network from which to migrate information. Sharing is enabled.

But they can't see each other at the OS level. E.g.

  1. Nothing to connect to shows up on the Mac in OS setup.
  2. Nothing shows after choosing Go…Network in the Finder.
  3. <I forget what else I tried.>
  4. No response to pings of the broadcast address. (ping 169.254.255.255)
  5. There are no entries in the MAC address table (as shown by arp -an) for the other Mac even right after #5.
  6. The appropriate routing table entries (as shown by netstat -rn don't exist)

It's failing to set up 169.254 routing, AKA link-local addressing so the Macs can communicate properly. In other words, it's failing to fully set up the en0 (TP Ethernet) interfaces so that link-local addressing works automatically.

Wondering what was going on, I looked to the documentation. I thought since it apparently followed RFC 3927 on Dynamic Configuration of IPv4 Link-Local Addresses, would "just work", but not so.

In particular, it is automatically assigning IPs to the devices, but it is NOT routing packets / setting up the routing table accordingly.

From the RFC:

Abstract

… This document describes how a host may
automatically configure an interface with an IPv4 address within the
169.254/16 prefix that is valid for communication with other devices
connected to the same physical (or logical) link.

Is MacOS violating RFC 3927? Why shouldn't two Macs connected over an Ethernet cable, each with automatically assigned 169.254/16 link-local addresses see each other?

This might be a fix; I haven't figured it out yet: sudo route -n add -net 192.168/16 169.254/16 169.254.14.233. (That's the automatically self-assigned IP.). (Update: Won't know; too late and it had a typo.)

Best Answer

So I'm looking at the same connection a month later, but with both Macs in normally booted mode.

So now, the 169.254 routing is set up just by plugging the cable.

The other machine is visible in the IP and ARP routing tables.

The problem has gone away.

(I can reach the other machine with mDNS now as per @John Keates; ping [the other machine-name, now that I know it].local works. But I can't go back in time to see if it would have worked.)

Also, I realized I screwed up that route command (just corrected), so that could be causing some remaining weird things I don't understand. (I need to reboot this system!?):

Oh, and I just found out my Ca blood levels have been off, so some confusion it likely caused may have been a major cause of the (alleged) MacOS problem! Cringe. With work, I see it's become worth it to keep this question visible anyway.

Today, I see:

$ ifconfig | grep broad
inet 169.254.14.233 netmask 0xffff0000 broadcast 169.254.255.255
inet 192.168.141.99 netmask 0xffffff00 broadcast 192.168.141.255

and

$ ifconfig | grep broad
inet 169.254.174.186 netmask 0xffff0000 broadcast 169.254.255.255

which is as expected.

But this isn't:

$ ping 169.254.255.255
PING 169.254.255.255 (169.254.255.255): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
  C-c C-c
--- 169.254.255.255 ping statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss

My understanding is that I should see ping responses both machines for which that is their broadcast address.

Pinging the other broadcast IP, 192.168.141.255, gets me ping responses from all the live interfaces with that broadcast IP address, as expected.

Related Question