doctor reports "SMB not reachable at fd..::445 (No route to host)" when the base station's Configure IPv6 is set to Automatically

[ddelmoli]

Summary

A single doctor WARN about IPv6 reachability traces back to the AirPort base station's own Configure IPv6 setting rather than to anything in TimeCapsuleSMB or on the local network. Setting it to "Link-local only" clears the warning. I am writing this up because two properties of the symptom point away from the cause.

Symptom

doctor reports PASS 63, WARN 1, FAIL 0. The WARN:

WARN | SMB not reachable at fdbb:xxxx:xxxx:xxxx:<eui64>:445 ([Errno 65] No route to host)

Every functional check passes: SMB reachability on IPv4, authenticated share listing, file create, read, overwrite, rename, copy and delete, directory listing and cleanup, Bonjour resolution, and NBNS resolution. Time Machine backups run without trouble. The IPv6 reachability probe is the only check that fails.

Rebooting the Time Capsule does not clear it. I power-cycled the device several times during installation and the same IPv6 address returned each time.

Environment

• TimeCapsuleSMB 2.2.9 (build 20215)
• Device: TimeCapsule8,119, NetBSD 6.0, evbarm, payload family netbsd6_samba4
• Client: macOS
• Network: eero mesh, device connected by ethernet

Root cause

The AirPort base station had Configure IPv6 set to "Automatically". In that mode the base station runs its own IPv6 router, generates a unique local address prefix, and stores that prefix in its saved configuration. It assigns itself an address from the prefix, and mdns-advertiser publishes every IPv6 address held by the interface as an AAAA record. The client then probes an address it has no route to.

Two properties of the symptom point away from this explanation:

1. It survives reboots. A SLAAC address learned from a Router Advertisement is soft state and does not outlive the interface. This address is generated by the base station and written to its saved configuration, so power-cycling leaves it in place.
2. Nothing on the local network advertises the prefix. On the client, ndp -p shows no entry for it and no advertising router, so a search for a device handing out a stale prefix comes up empty. The address originates on the Time Capsule itself.

Querying mDNS directly shows both published records:

$ dns-sd -timeout -Q <host>.local AAAA
... AAAA  IN  FDBB:XXXX:XXXX:XXXX:<eui64>     (base station's own ULA)
... AAAA  IN  FDA3:XXXX:XXXX:XXXX:<eui64>     (ULA from my router)

My client has no route to either prefix, because IPv6 is not functional on this LAN (double NAT, with no delegated prefix reaching the router). Any advertised IPv6 address would have produced the same WARN in my case.

Fix

1. Open AirPort Utility, select the Time Capsule, then Edit, Internet, Internet Options.
2. Set Configure IPv6 to "Link-local only".
3. Click Update. The base station restarts, which also restarts mdns-advertiser so that it re-enumerates the interface addresses.
4. Flush the client's mDNS cache. Without this, the old record continues to resolve locally:

   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   

5. Re-run doctor.

Afterward, dns-sd -Q <host>.local AAAA returns No Such Record, the A record and all SMB functionality are unchanged, and doctor reports WARN 0.

Step 3 is required even once the address is gone from the interface. mdns-advertiser enumerates interface addresses when it starts, so an already-running advertiser keeps publishing the set it captured at boot until something restarts it.

The setting is worth correcting on its own merits. A Time Capsule used as a NAS behind another router has no reason to run an IPv6 router, and in this configuration it was a second source of Router Advertisements on the LAN.

Possible enhancement

Could the IPv6 reachability check separate an address that is advertised but unroutable from the client from a genuine service failure? On a client with no IPv6 route to the target's prefix, the probe cannot succeed, and reporting that case as INFO would save people a search. A second option: have doctor report when an advertised AAAA falls outside every prefix the client holds, since that condition is the signal that points at this misconfiguration.

Happy to test a patch.

[jamesyc]

Fixed in 6033f4d