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

Question

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

2. Nothing to connect to shows up on the Mac in OS setup.
3. Nothing shows after choosing Go...Network in the Finder.
4. <I forget what else I tried.>
5. No response to pings of the broadcast address. (ping 169.254.255.255)
6. There are no entries in the MAC address table (as shown by arp -an) for the other Mac even right after #5.
7. 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.)

Answer 1

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.

Answer 2

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

Abstract

...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 169.254.255.255, 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...

Answer 3

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

Answer 4

I’ve never had to do anything except connect any ethernet cable or FireWire cable and use Bonjour (ssh [email protected]) 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.