(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
  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:


... 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 (That's the automatically self-assigned IP.). (Update: Won't know; too late and it had a typo.)

  • 2
    You mention WiFi and ethernet. What if you turn off WiFi so you are only dealing with the (faster) wired connection. When I do this (usually migrating to another Mac) I always turn off WiFi to force the Mac to not even try to use both or jut the WiFi, which I have seen before. Sep 4 '20 at 0:18
  • That is a viable workaround. But I really wanted to keep one of the computers connected to the Internet. Indeed, I was exploring migration options at the time I asked the question. Oct 7 '20 at 20:04
  • Please don‘t write „solved“ into the question, accept the answer which helped you instead. And the information in both the question and the answers might be helpful in the future, so there is no reason to delete it either.
    – nohillside
    Oct 9 '20 at 4:43

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 netmask 0xffff0000 broadcast
inet netmask 0xffffff00 broadcast


$ ifconfig | grep broad
inet netmask 0xffff0000 broadcast

which is as expected.

But this isn't:

$ ping
PING ( 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
--- 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,, gets me ping responses from all the live interfaces with that broadcast IP address, as expected.


I may have figured out the answer as I was fleshing out the question.

It's probably not working because one of the Macs has a routable address/is multi-homed, in which case applicability and automatic configuration is left under-defined in the RFC.

The RFC implies an answer to the question (emphasis added to most relevant bits) in § 2.6.2, etc. :


...IPv4 Link-Local addresses are ... only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).

2.6.2. Forwarding Rules

... if the destination address is in the 169.254/16 prefix (excluding the address, which is the broadcast address for the Link-Local prefix), then the sender MUST ARP for the destination address and then send its packet directly to the destination on the same physical link. This MUST be done whether the interface is configured with a Link-Local or a routable IPv4 address.

In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. This approach will not work for routers or multi-homed hosts. Refer to section 3 for more discussion of multi-homed hosts.

Section 3 then goes into great detail as to why.

(On the other hand, Appendix A says:

... Mac OS systems do not send packets addressed to a Link-Local address to the default gateway if one is present; these addresses are always resolved on the local segment. ...

I find that this is not currently true.)

And after reading in Section 3.3, "Since HOST2's address is not in 169.254/16" I'm confused again, as in the provided scenario, I think it will/should be the case that HOST2's address is in 169.254/16... perhaps that's an error in the RFC. Probably I'm just confused...

  • Works if you use the mDNS hostname, scutil should show you that that still routes correctly using a policy chain. Sep 4 '20 at 1:49
  • Thanks. (One of them was already in OS reinstall/setup mode, so I didn't think to try that as I'd have had to find a way to figure out its hostname which would have required aborting the operation. All of which I didn't mention per the spirit of SE.) Oct 7 '20 at 20:04

Quoting from this Wikipedia article:

Blockquote An Ethernet crossover cable is a crossover cable for Ethernet used to connect computing devices together directly. It is most often used to connect two devices of the same type, e.g. two computers (via their network interface controllers) or two switches to each other. By contrast, patch cables or straight through cables are used to connect devices of different types, such as a computer to a network switch or Ethernet hub.

You need a crossover cable for that

  • LOL!!! No. IIRC, all Macs (with Ethernet) have had auto-MDX - MDIX ports for decades. (As I recall from years ago.) Oct 7 '20 at 18:50
  • OMG and read said article before quoting out of context from it, e.g. * <<<Many devices today support auto MDI-X capability, wherein a patch cable can be used in place of a crossover cable, or vice versa, and the receive and transmit signals are reconfigured automatically within the devices to yield a working connection.>>> and *more so: Oct 7 '20 at 18:53
  • <<<Gigabit and faster Ethernet links over twisted pair cable use all four cable pairs for simultaneous transmission in both directions. For this reason, there are no dedicated transmit and receive pairs, and consequently, crossover cables are never required for 1000BASE-T communication.[8] The physical medium attachment sublayer (PMA) provides identification of each pair and usually continues to work even over cables where the pairs are unusually swapped or crossed.>>> Oct 7 '20 at 18:53
  • Also, thank you and sorry - I shouldn't have been harsh. Oct 7 '20 at 21:53
  • Good call on crossover. Not all hardware supports direct connect so if you use a crossover cable, any adapter will work. Most Macs don’t need it, of course and straight ethernet works to a switch, to a router or to another Mac.
    – bmike
    Oct 7 '20 at 22:00

I’ve never had to do anything except connect any ethernet cable or FireWire cable and use Bonjour (ssh user@mac-one.local) to use MDNS .local suffix to connect to machine names. Everything works out of the box.

Perhaps you’re looking a bit too deeply an not just doing what you want without worrying about a hub or switch or direct connection isn’t ready.

  • If you allow WiFi, AirDrop also connects securely in point to point mode. (Which is also very capable to discover local Macs on the same physical network segment if you don’t know the other’s name and they allow anyone to discover a Mac.)
    – bmike
    Oct 7 '20 at 21:59
  • mDNS itself just helps with host name resolution. ("resolves hostnames to IP addresses" - Wikipedia.). If there's no IP connectivity, it's a bridge to nowhere. But yeah, I could have been... make that definitely was ... lost in the weeds - looking too deeply - see my note about confusion!? Oct 7 '20 at 22:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .