mDNS Network Browse over Mach Plan ready

Why the Workspace File Viewer's Network list is empty on NextBSD, and the Mach-IPC fix that lights it up. Drop the AF_UNIX socket transport; finish the dns_sd client protocol over the com.apple.mDNSResponder Mach service — the Apple way.

1. Symptom

On the live NextBSD machine (root@thinkpad-t460s, display :0, user admin), GWorkspace's File Viewer shows the sidebar tree Local User / Domains / Volumes / Network. The Network section is expanded but empty. The Sharing preference pane lists every service (SSH, SFTP, AFP, SMB, VNC) as Off.

For comparison, admin@debian on the same LAN shows a populated Network section. Same File Viewer, same sidebar tree (Local User / Domains / Volumes / Network) — only the Network node differs:

The asymmetry is the key clue: NextBSD advertises (Debian sees it) but cannot browse. Advertisement is the multicast engine talking to the wire; browse requires a client API call into the daemon — and that path is broken.

2. How discovery is supposed to flow

Both UI consumers are platform-agnostic and converge on a single transport that lives below Gershwin, inside GNUstep-base's NSNetService → libdns_sd linkage:

Confirmed in source: the File Viewer's NetworkServiceManager is declared <NSNetServiceBrowserDelegate, NSNetServiceDelegate> and gates on NSClassFromString(@"NSNetServiceBrowser"); its /Network node is a synthetic NetworkFSNode whose children come straight from [[NetworkServiceManager sharedManager] allServices] — no SMB browse, no autofs, no pre-mounted filesystem. The standalone NetworkBrowser.app uses the same NSNetServiceBrowser API independently. Same backend, same transport. Fix the transport once and both light up.

3. Root cause

Two compounding defects, both verified by reading the port at nextbsd-redux/nextbsd src/mDNSResponder/ and probing the running daemon.

3a. No Mach dns_sd transport exists on either side

• Daemon: mach_bridge.c is a bare skeleton. mDNSResponderMachBridgeInit() does a single bootstrap_check_in(bootstrap_port, "com.apple.mDNSResponder", &svc), logs MDNS-BOOT-OK, and discards the receive right. No mach_msg receive loop, no MIG demux. Its own header admits iter‑3 (“Apple-shape dns_sd.defs MIG IDL”) was never done. No .defs file exists anywhere in the tree.
• Client lib: libdns_sd is built from mDNSShared/dnssd_clientstub.c — the cross-platform AF_UNIX variant. dnssd_ipc.h takes the AF_LOCAL branch (USE_TCP_LOOPBACK undefined, no Mach define), so ConnectToServer does socket()/connect() to /var/run/mDNSResponder and deliver_request uses sendmsg. Zero Mach symbols in the shipped .so (no bootstrap_look_up, no mach_msg).
• Event loop: the daemon's MainLoop / mDNSPosixRunEventLoopOnce is kqueue/select over FDs only. The claimed Mach port is never added to any event source.

3b. The one transport that does exist (AF_UNIX) is dead at runtime

• udsserver_init binds /var/run/mDNSResponder — but the daemon then drops to nobody, and /var/run is root-owned, so the socket never appears (and the running daemon holds only UDP/route sockets, no UNIX stream listener).
• The launchd plist com.apple.mDNSResponder.plist declares MachServices but has no Sockets key, so launchd never vends a properly-owned socket either.
• Net effect: every client DNSServiceBrowse fails with kDNSServiceErr_ServiceNotRunning → the Network list stays empty. Multicast advertisement is independent of this path, which is why peers still see ThinkPad-T460s.

4. Which repos to touch

The fix is overwhelmingly concentrated in one repo. Mapping each source tree to its GitHub home:

5. Daemon-side fix (nextbsd-redux/nextbsd)

1. Add a MIG IDL — a new dns_sd.defs (or revive Apple's DNSServiceDiscovery.defs) defining the request routines (browse / register / resolve / queryrecord / enumerate) plus the DNSServiceDiscoveryReply callback subsystem. Generate server (*Server.c) and user (*User.c) stubs with mig.
2. Implement a real Mach server in mach_bridge.c — after bootstrap_check_in, keep the receive right and dispatch incoming messages through the generated MIG demux, translating each routine into the existing uds_daemon.c request handlers (handle_browse_request, the request_state machinery) so mDNSCore is driven exactly as the socket path drove it. Replies go back to the client's reply port via the generated DNSServiceDiscoveryReply user stub.
3. Wire the Mach port into the event loop — the central missing piece. Bridge the receive right to a kqueue EVFILT_MACHPORT source (consistent with #168), rather than a separate mach_msg server thread, so it folds into mDNSPosixRunEventLoopOnce.
4. Retire / demote AF_UNIX — drop udsserver_init (or keep behind a build flag, disabled by default). If kept, it must be created by launchd with correct ownership, not bound by the post-drop nobody daemon.

6. Client-side fix (libdns_sd, same repo)

1. Add a Mach transport to dnssd_clientstub.c (or a Mach-backed alternate stub). ConnectToServer must bootstrap_look_up("com.apple.mDNSResponder") for the send right instead of socket()/connect(); deliver_request must mach_msg(MACH_SEND) via the generated MIG user stub instead of sendmsg.
2. Reply delivery — allocate a per-DNSServiceRef reply receive port. DNSServiceRefSockFD / DNSServiceProcessResult assume a socket FD today; they need a Mach analog (a port that integrates with client run loops, as Apple's classic lib did). This is the piece GNUstep's NSNetService run-loop integration depends on — verify it there.
3. Guard the transport with a build define (analogous to the existing USE_TCP_LOOPBACK switch), e.g. USE_MACH_DNSSD, selecting Mach vs AF_LOCAL at compile time.

7. Build & packaging (same repo)

• MIG codegen rules in both Makefile and libdns_sd/Makefile: run mig on the .defs; compile the Server stub into the daemon and the User stub into the lib. Mirror how other NextBSD components consume .defs.
• Link the lib against Mach/bootstrap: libdns_sd/Makefile currently links nothing Mach. Add -llaunch (bootstrap) + -lsystem_kernel (mach_msg) and the liblaunch / freebsd-shims includes the daemon Makefile already carries.
• Plist: for the pure-Mach path, MachServices already vends the service — confirm lazy MachServices spawn actually delivers the receive right to the daemon (sibling plists for configd/syslogd/notifyd carry notes that lazy MachServices spawn isn't fully wired; verify that gap doesn't also block mDNSResponder). Drop the dead Sockets assumption entirely.

8. Follow-on: Sharing pane (gershwin-desktop/gershwin-components)

Independent of the browse fix, but part of “hostname, enabled services, etc.” The Sharing pane's mDNS announcement rides the same NSNetService → libdns_sd path, so it starts working the moment the transport is fixed — no Sharing code change for announce. The non-mDNS pieces (hostname + service control) need launchd-native rework.

8a. The hostname symptom

The blank field is not a helper bug: run as the same admin user that owns the pane, sharing-helper get-hostname returns ThinkPad-T460s with exit code 0. So the value is available but never reaches the text field — a UI-layer defect in SharingController (the NSTask output capture / field assignment around the get-hostname call), independent of the platform rework below. The “Service Discovery: Available (NSNetService)” line is also misleading: the class resolves, but the underlying transport is the broken one from §3, so nothing is actually announced or browsed.

8b. Hostname + service control: what needs launchd-native rework

8c. Conditional on NextBSD — do not break FreeBSD / Linux / OpenBSD / NetBSD

The platform split in sharing-helper.c is the existing PLATFORM_* ladder. The trap: NextBSD compiles as __FreeBSD__, so it silently falls into PLATFORM_FREEBSD — the sysrc/service/rc.conf branch. Two rules follow:

• Never edit the existing PLATFORM_FREEBSD branch to use launchd — that would break real FreeBSD. The change must be additive: a new PLATFORM_NEXTBSD branch. On every other OS the new code is excluded by the preprocessor, so their behavior is byte-for-byte unchanged.
• A plain #ifdef __FreeBSD__ cannot tell NextBSD from FreeBSD. Use a discriminator real FreeBSD never matches, checked first in the ladder — a build-injected define set only by the NextBSD build of gershwin-components (the feat/nextbsd branch / NextBSD port):

/* checked BEFORE __FreeBSD__ — NextBSD also defines __FreeBSD__ */
#if defined(PLATFORM_NEXTBSD) || defined(NEXTBSD)   /* -DNEXTBSD from the NextBSD build only */
#  define PLATFORM_NEXTBSD 1
#elif defined(__linux__)
#  define PLATFORM_LINUX 1
#elif defined(__FreeBSD__)
#  define PLATFORM_FREEBSD 1      /* unchanged — real FreeBSD lands here */
#elif defined(__OpenBSD__)
#  define PLATFORM_OPENBSD 1
#elif defined(__NetBSD__)
#  define PLATFORM_NETBSD 1
#endif

Belt-and-suspenders (recommended): also pick the service-control backend at runtime — prefer launchctl when it is present, else fall back to service/sysrc (FreeBSD/NetBSD) or systemd (Linux). That way even a mis-built binary degrades gracefully and regular OSes are never affected regardless of defines. (A __has_include(<servers/bootstrap.h>) Mach-header probe is an alternative compile-time auto-detect, but the build define is more explicit.)

9. Phased rollout (PR-gated)

10. Verification

# On the NextBSD box, after the fix:
# 1. Mach service is claimed AND served (not just claimed)
launchctl print system/com.apple.mDNSResponder | grep -i mach

# 2. A browse from libdns_sd returns results (CLI, if dns-sd is built)
dns-sd -B _services._dns-sd._udp local.

# 3. The File Viewer Network node populates (screenshot display :0 as admin)
DISPLAY=:0 import -window root /tmp/after.png    # compare to the empty "before"

# 4. Cross-check from a peer: NextBSD's own advertised services now resolve
avahi-browse -art   # (from the Debian reference box)

Success = the File Viewer Network list on NextBSD shows the same peers the Debian box sees, and toggling a service in the Sharing pane makes it appear on other hosts.

11. References

• Companion: FreeBSD mDNSResponder — porting plan (daemon/advertisement bring-up; this page supersedes its “zero Mach surface” client-transport assumption).
• Doctrine: Native EVFILT_MACHPORT migration (#168) — the kqueue/Mach integration this fix rides on.
• Fixing .local (mDNS) resolution — unrelated Debian NSS workaround; not part of this fix.
• Apple source: apple-oss-distributions/mDNSResponder (classic DNSServiceDiscovery.defs + mDNSMacOSX/daemon.c Mach path as reference; not vendored here).
• RFC 6762 (mDNS), RFC 6763 (DNS-SD).

Filed 2026-06-21. Root-caused from a 3-agent investigation (daemon/lib Mach gap, Gershwin UI consumer map, existing-plan review) plus live probing of root@thinkpad-t460s. Primary work: nextbsd-redux/nextbsd (src/mDNSResponder/). UI: no change. Follow-on: gershwin-desktop/gershwin-components Sharing pane.