macOS 26.2 stops self-assigning IPv4 on Thunderbolt RDMA interfaces
Parent: Mac local LLMs: Clusters, RDMA, exo and ds4 · Published reference · snapshot 2026-10-05
↓ Facts as markdownall context files
The claim is that from macOS 26.2 the Thunderbolt RDMA member interfaces stay without an IPv4 address until something assigns one, so JACCL has no IPv4-mapped GID to pair with and fails at RTR.
These notes link each claim to its source. A source may be a research report hosted on this site rather than the primary document. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Facts
- The claim is that from macOS 26.2 the Thunderbolt RDMA member interfaces stay without an IPv4 address until something assigns one, so JACCL has no IPv4-mapped GID to pair with and fails at RTR. [source]
- The exo console error for this case is `ValueError: [jaccl] Changing queue pair to RTR failed with errno 22`, printed on each runner start; the dashboard shows `preparing` then `failed` in sequence for a tensor-sharded, MLX RDMA instance on 2 or more Macs. [source]
- The same log shows `Fast synch flag: 1` just before the error, so the failure happens during JACCL group creation, not in a fence wait. [source]
- The reporter's `sw_vers`-style output was macOS 26.2, build 25C56. A second user wrote that their two Studios went from macOS 15.7 to 26.2 and that the OS had created a bridge device so the individual Thunderbolt interfaces were not available; running exo's `tmp/` network script, which sets up a location without the bridge, made RDMA work. [source]
- A third user ran the script, rebooted and re-pulled the source and then everything worked; that user drafted a troubleshooting text listing three options: enable DHCP on each interface, assign and route addresses manually, or run the script. [source]
- A reporter suggested that exo should check whether the interfaces are in a bridge and either warn or disable the MLX RDMA button; a maintainer agreed that UI and documentation changes could help. [source]
- Two different causes give the same errno 22: no IPv4 on a member interface (the 26.2 case) and interfaces enslaved to a bridge, which the 15.7-to-26.2 user hit. The sources do not separate them by symptom. [source]
- Exo issue 1390 still showed state Open when fetched on 2026-10-04, so the exo project had not closed the gap in the app. [source]
- Whether macOS 26.2 changed behaviour or the interfaces never self-assigned: the maintainer says "after macOS 26.2 they do not self-assign by default"; one reporter says the OS created a bridge when upgrading from 15.7. No Apple release note or document is cited by anyone. [source]
- Whether the change is a link-local (IPv4LL) policy change in 26.2, a service-order or bridge-creation change, or both. [source]
- Whether later 26.x builds (the cluster in exo issue 1847 ran 26.3 on DHCP link-local ports) restored self-assignment. [source]
- The exo errno 22 failure is printed as `ValueError: [jaccl] Changing queue pair to RTR failed with errno 22` and the dashboard shows preparing then failed. [source]
- The first reporter ran macOS 26.2 build 25C56. [source]
- A user upgraded from macOS 15.7 to 26.2 found an OS-created bridge device and fixed RDMA by using exo's `tmp/` script to build a location without the bridge. [source]
- A user's troubleshooting draft offers three options: DHCP per interface, manual address plus route per interface, or the exo script. [source]
- A reporter proposed an exo check for bridged interfaces that warns or disables the MLX RDMA option. [source]
- Exo issue 1390 was still Open on 2026-10-04. [source]
- No cited source ties the no-self-assign behaviour to an Apple document or release note; it rests on a maintainer statement. [source]
Children
- No children recorded.