This thread is the support topic for Thunderbolt Net + Fabric Routing (FRR resides here, for now)

Install the plugin, plug one Thunderbolt/USB4-class cable to a peer host, set a static IP on the tbn tab, and use it like a simple eth path. For bugs or feedback, post here with Unraid version, controller generation if you know it (TB3 / TB4 / TB5 / USB4 / USB4 v2), peer OS (Linux/macOS/Windows), cable notes, and what you expected vs what you saw. Screenshots of Settings → Network Settings → Thunderbolt help a lot.

Thunderbolt Net is for reliable single-link host-to-host networking wherever Linux exposes the Thunderbolt fabric and thunderbolt_net — not locked to one sticker speed.

Supported when the kernel sees a host controller and a thunderboltN interface, including:

• Thunderbolt 3

• Thunderbolt 4

• Thunderbolt 5

• USB4 (20G and 40G product tiers, when the platform implements host networking)

• USB4 Version 2.0 (e.g. 80 Gb/s class) when controllers and cable train that path
  

Same plugin UI for all of those. We report trained rate and lanes honestly. Port stickers (40 Gb/s, 80 Gb/s, etc.) are capability class — not a promise of full dual-lane TCP on every host-to-host pair. One cable, one peer, eth-like UX. Not dual-cable bonding for 2× bandwidth.

Plain USB 2/3 SuperSpeed-only ports (SS only, no Thunderbolt/USB4 host router) are out of scope — those never get thunderbolt_net.

---

INSTALLATION

Recommended (Community Applications)

Apps → Search Thunderbolt Net → Install

Alternatively, Manual setup (same plugin)

Plugins → Install Plugin, paste this URL:

https://raw.githubusercontent.com/ibigsnet/ThunderboltNet/stable/thunderboltnet.plg

After install: Settings → Network Settings → Thunderbolt (and the tbn0 / tbn1 tabs when interfaces appear). Hard-refresh the browser after update if the UI looks stale.

---

WHAT IT DOES

• Works across TB3 / TB4 / TB5 / USB4 / USB4 v2 hosts when Linux exposes them

• Shows fabric: security, modules, peers, trained RX/TX and lanes (whatever rate the path actually trained)

• Per-link settings like eth: enable, static IPv4/IPv6, MTU, optional bridge/VLAN notes

• Unraid services listening on TB IPs (network-extra include), per-peer preferences, harden-all

• Known peers memory (settings return when a peer reconnects)

• Activity hints on live links

• Honest link quality: trained first; single-lane on dual-capable hosts is common under Linux host-to-host

Default product path: one cable, one peer, static IP, MTU 1500 both ends for bulk (peer must match).

---

WHAT IT IS NOT

• Not limited to “Thunderbolt 4 only” or “40G only” — same stack for older and newer generations Linux supports

• Not dual-cable bonding to the same peer for 2× bandwidth (usually one netdev; bonding is experimental and often fails on thunderbolt_net)

• Not a guarantee of dual-lane or full sticker TCP (e.g. 40G/80G class ports can still train 20 Gb/s · 1-lane; ~10–15 Gbit/s TCP is normal on that path)

• Not a dock RJ45 “TB switch” — dock Ethernet is usually a USB/PCIe NIC; configure it like eth

• Never unbind the Thunderbolt NHI “to reset” networking — that can wedge the controller until reboot

If dual-cable experiments wedged the fabric: unplug all TB/USB4 host cables from both ends on both machines, wait, plug exactly one cable, then reconfigure.

---

COMPATIBILITY

Plugin allows Unraid 6.12.0+. Developed and tested on Unraid 7.x (including 7.3.x). Needs a Thunderbolt-family or USB4 host controller that Linux exposes (not USB2/3-only SuperSpeed ports). Peer can be Linux (including another Unraid), macOS Thunderbolt Bridge, or Windows where host networking is available. Reports from TB3 through TB5 / USB4 v2 welcome.

---

LINKS

Docs: https://github.com/ibigsnet/ThunderboltNet/blob/main/DOCS.md

Standards / generations: https://github.com/ibigsnet/ThunderboltNet/blob/main/docs/standards-and-speeds.md

GitHub: https://github.com/ibigsnet/ThunderboltNet

CA templates repo: https://github.com/ibigsnet/unraid-templates

Raw plugin URL: https://raw.githubusercontent.com/ibigsnet/ThunderboltNet/stable/thunderboltnet.plg

---

Edited Tuesday at 01:27 AM2 days by RifleJock
FRR inclusion

Thanks for this!!!!! Much appreciated!

Is it stable in your experience?

I'd be using an ASUS NUC PRO 15 with Unraid to a MacBook Pro client, can I consider the Thunderbolt network support embedded in the latest kernel shipped with the latest Unraid as "production" ready?

BTW Slightly OT but since you play with TB devices, are Thunderbolt storage devices like OWC Thunderbay enclosures and network cards like 10G SFP+ or 10G RJ45 (usually based on AQC chips) stable under Unraid and usable for prolonged/production use?

Thanks again!!!!

Thanks! - really glad it's useful!

On 8/12/2026 at 7:02 AM, kinoapparatom said:

Is it stable in your experience?

Stability / “production ready?”

In my experience the thunderbolt_net path is stable enough for real work when the link trains cleanly, you use a simple static IP plan, and you don’t fight multi-cable domain weirdness. I’ve already used it with my NBD Export plugin (not on CA yet) for a 4TB NVMe whole-disk Host/Pull over Thunderbolt networking — not “copy a folder over SMB” — so I’m dogfooding it hard.

I'm also working on a plugin as well for doing FabricRouting and extending the support for that as well through thunderbolt networking. (also not yet up on CA)

On 8/12/2026 at 7:02 AM, kinoapparatom said:

I'd be using an ASUS NUC PRO 15 with Unraid to a MacBook Pro client, can I consider the Thunderbolt network support embedded in the latest kernel shipped with the latest Unraid as "production" ready?

What “production-ready” means here is a bit split:
• Kernel: Unraid already ships the Thunderbolt / thunderbolt_net stack (not an out-of-tree driver you install from CA).
• Product: Unraid doesn’t fully surface that path in the stock UI the way some other distros experiment with. This plugin is management UX on top of that kernel path — still early, but aimed at feeling natural on Unraid.
• Your pair: NUC Pro 15 <--> MacBook Pro is reasonable if both ends expose host networking on a real TB/USB4 cable (not a dock Ethernet path) and you set static IPs both ends. I haven’t lived on that exact pair day-to-day; Linux <-> Linux is where I’ve pushed hardest. If you’re already running Unraid on the NUC, diagnostic dumps from the plugin help a lot when something’s quirky. See: peer-scenarios)

Limits that matter if you’re thinking production-ish:
• Safe Mode / no-plugins won’t load the UI — have Ethernet/manual fallback (see safe-mode recovery notes).
• Prefer one known-good TB4/USB4 cable; unplug other host TB cables when debugging. Lots of cables market themselves as TB-class and aren’t.
• Keep default route = No on the TB side so WAN/mgmt stays on eth/Wi-Fi.

NUC Pro 15 → MacBook Pro
I’d expect the dual TB4/USB4 ports to behave like other USB4 hosts that expose the controller to Linux. Direct host-to-host (not through a dock as the “network”), static IPs both ends, start simple.

OT — storage / 10G AQC
Different stacks from host-to-host thunderbolt_net. OWC ThunderBay etc. are DAS (Direct Attached Storage) stability questions; AQC 10G is normal Ethernet and often fine long-term. This plugin doesn’t manage those.

And of course, my end goals do align to bringing stability everywhere, when/where possible. But mainly, to leverage faster inter connectivity between devices, why settle for 10gig LAN when I can have 20gb/s or 40gb/s. And at the expense of just a TB standard cable for hardware already owned?

If unraid lacks detection of thunderbolt_net driver usage, my plugin flags it:

Edited August 14Aug 14 by RifleJock

Unraid 7.3.2 · TB4 (Alder Lake-P) · macOS peer (Apple Silicon, Mac17,6)

First off — thanks for this. Getting host-to-host working manually was fiddly, and having the tbn tab handle the interface plus the services include list is a big improvement.

Working well: peer detection and naming, trained rate reporting (20 Gb/s full-duplex, 2-lane), and the "Include listening interface" option — Samba rebinds to the TB IP on Apply without me touching rc.samba. Measured 25.3 Gbit/s Mac→Cube and 29.4 Gbit/s Cube→Mac with iperf3, zero retransmits, MTU 1500 both ends. Direct cable. Through a Dell SD25TB4 dock it caps hard at 9.85 Gbit/s, consistent with your note about docks not being TB switches.

Issue: config not reapplied after reboot or link drop.

Steps: set static IPv4 on tbn0, Apply — works, interface UP with address, services bound. Reboot the server with the Mac still cabled. After boot, 1-1 and 1-1.0 are both present in /sys/bus/thunderbolt/devices/, and thunderbolt0 exists — but it's DOWN with no address, and Samba binds only to the LAN IP. A manual Apply on the tbn0 tab fixes it every time.

Same thing happens on any link drop — changing the peer's IP config, or unplugging and reconnecting.

One possibly relevant detail: the interface MAC is regenerated on each link establishment (I've seen 02:e3:0a:90:38:61, 02:e2:02:28:f5:9d, 02:f3:08:39:98:71, 02:fd:da:8b:66:41 across sessions). If known-peer matching keys on the local MAC, that might explain why the saved config isn't reapplied.

Also saw the address field revert to the plugin default (10.255.0.x) after a reboot rather than keeping what I'd entered, though I may have caught it mid-apply.

Happy to pull diagnostics if useful.

Update to my earlier post — root cause found, plus a workaround

Dug into the plugin source and found the mechanism behind the address instability I described. It's not just "settings don't persist" — there are three separable defects.

1. dhcpcd is never stopped when switching back to Static

This is the one causing the address churn. include/tbn-lib.php ~line 2557 starts dhcpcd -n {$ife} when USE_DHCP=yes. The static branch calls tbn_iface_flush_l3() and adds the address, but never kills a dhcpcd already running on that interface. Once DHCP has been enabled even briefly, the client persists, finds no server, and keeps re-adding a rotating 169.254.x.x alongside the static IP.

I had 10.255.0.x/24 and a 169.254 address stacked on the same interface, with the UI correctly showing Static the whole time — which is why it took so long to spot. dhcpcd -k thunderbolt0 clears it until next time. Suggested fix: dhcpcd -k {$ife}at the top of the static branch.

2. No boot-time reapply

event/started calls tbn-dashboard-ports apply and tbn_of_apply() only — nothing applies per-interface addressing. After a reboot with the peer still cabled, 1-1 and 1-1.0 are in sysfs and thunderbolt0 exists, but it's unconfigured and services bind to the LAN address only.

3. No hotplug hook

No udev rules in the package. Since the netdev is destroyed and recreated on every link drop — with a fresh MAC each time — config needs reapplying on ACTION=="add", not just at boot.

Workaround for 2 and 3, in case it's useful to others: udev rule on SUBSYSTEM=="net", KERNEL=="thunderbolt*" calling a flash-resident script that sets the address and restarts smbd/nfsd, with the rule reinstalled from go since /etc/udev/rules.d is tmpfs. One gotcha — the script must be invoked as /bin/bash /path/script.sh; FAT32 won't hold the execute bit, so RUN+= on the bare path fails silently.

Also worth flagging: tbn_bring_up_ifaces() doesn't apply L3 config, so it's not a shortcut for this. I used plain ip commands instead.

Follow-up: workaround now confirmed stable across reboots, plus MTU data

Reporting back after getting this fully persistent, in case it's useful for the fix or for anyone else hitting it.

What works

A udev rule on SUBSYSTEM=="net", KERNEL=="thunderbolt*" calling a script that sets the address and restarts smbd/nfsd. Survives cold boots, cable reseats and peer sleep — interface comes up addressed with services bound, no manual Apply.

Three implementation details that caught me out, all worth knowing if you build something similar into the plugin:

1. The rule alone isn't enough at boot. The netdev appears before go has installed the rule, so the add event is never seen. You need udevadm trigger --subsystem-match=net --action=add after loading the rules to replay it against interfaces that already exist. Without that line it worked on hotplug but never on a cold boot.

2. FAT32 can't hold the execute bit. RUN+="/boot/config/.../script.sh" fails silently. Either invoke it as RUN+="/bin/bash /boot/..." or copy the script to /usr/local/bin first. I ended up doing the latter, which also removes the dependency on /bootbeing mounted when udev fires.

3. tbn_bring_up_ifaces() doesn't apply L3 config. I tried calling it from my script hoping to reuse your logic — the function exists and runs cleanly, but the interface stays unaddressed. Ended up with plain ip commands instead.

MTU 9000 — no measurable throughput gain on this path

Set on both ends (Unraid tbn0 and macOS Thunderbolt Bridge, including all three bridge0 member interfaces, which macOS does not raise automatically when you set the bridge MTU).

	MTU 1500	MTU 9000
Mac → Unraid	25.3 Gbit/s	25.0 Gbit/s
Unraid → Mac	29.4 Gbit/s	28.3 Gbit/s

Zero retransmits throughout. So your docs are right that jumbo is a CPU rather than a bandwidth win here — the single stream already saturates the path at 1500. Keeping it at 9000 for the reduced packet rate, but nobody should expect a throughput jump.

One testing note: macOS ping -D -s 8972 fails with "Message too long" even when jumbo is working correctly — it's an ICMP buffer limit, not a path MTU problem. -s 8000 succeeds. Cost me a while chasing a non-issue.

Let me know when you get a chance to update and test again. Some drastic improvements have been made.