T6485: Thunderbolt Networking support

[rafaelgaspar]

Change Summary

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

• https://vyos.dev/T6485

Related PR(s)

• linux-kernel: T6485: build modules for thunderbolt and thunderbolt-net vyos-build#657

Component(s) name

Proposed changes

How to test

Smoketest result

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[github-actions]

❌
PR title does not match the required format

[rafaelgaspar]

❌
Commit title 'Add initial interface for thunderbolt' does not match the required format!. Valid title example: T99999: make IPsec secure

I know @github-actions, it's a Draft PR for a reason, this is still a very early Work in Progress.

[github-actions]

✅ No issues found in unused-imports check.. Please refer the workflow run

[c-po]

I think those addresses are dynamic from host to host. It should be a completion helper script (best BASH to avoid process startup penalty)

[c-po]

Any progress on this?

[c-po]

Is there a Kernel simulation of thunderbold devices available? There is e.g. a hw simulator for WIFI available - that would make life easier when we have thunderbold smoketests

[rafaelgaspar]

Newer versions of systemd, like the one in the current nightly builds don't require anymore to edit systemd files or know the PCI-E address of the port anymore, that will make things easier, I should have some time to work on this this weekend and with this changes I might even be able to finish it since it simplifies a lot.

[rafaelgaspar]

@c-po I spent some time trying to get it work now with the new systemd, and it works fine out of the box, except re-attaching it to a bridge, should be similar to wlan but haven't implemented yet, and hotplug.

Looking at src/helpers/vyos_net_name function hotplug_event it seams like hot plug is not supported at all yet in vyos, is that right?

What would be necessary to enable hotplug?

I was able to restore connection after a disconnect and hotplug by manually running ip link set thunderbolt0 up setting it's master to the respective bridge and settings pvid on the bridge, but how to trigger this from udev?

[github-actions]

CI integration ❌ failed!

Details

CI logs

• CLI Smoketests (no interfaces) ❌ failed
• CLI Smoketests (interfaces only) 👍 passed
• Config tests 👍 passed
• RAID1 tests 👍 passed
• TPM tests 👍 passed

[dmbaturin]

We need to evaluate if there's really a use case for it. I'm not aware of any hardware that is likely to be used as a router that has Thunderbolt ports (servers and network boxes usually don't), and hotplug support is a complicated issue that we decided not to support for now — until (and unless) we have a general framework for it.

Could you tell us more about your use case for it? And is hotplug support required for your use case?

[rafaelgaspar]

I agree that on the enterprise side it's much easier to just use 40Gbps or even 100Gbps+ ethernet cards, but for custom made home routers(for now more on the enthusiast niche) it's a very simple and cheap solution to get 25Gbps(50Gbps with Thunderbolt 5) between the router and any computer with Thunderbolt including any Apple Silicon Macs, you don't need 300$+ for a 10Gbit Ethernet to USB-C adapter, just ~70$ for a good certified Thunderbolt cable.

I have been using this for an almost a year, and apart from having to restart the router when I reconnect my notebook, it works pretty well already on the current state.

The two issues I have with current version that I'm trying to solve is:

• On boot, if the other computer is not connected via TB, the init fail to bring the bridge up, because the device belongs to the bridge but doesn't exist.
• When connecting the TB computer, I need to go into the router and in configuration mode set the disable property commit and then delete it and commit, basically restarting the interface, this is the behavior I'm currently attempting via udev, so far without much success. Or most commonly just restarting it.

Another minor issue is the stability of the interface number, this can be achieved with the pci-address field that is partially implemented.

Hope this gives a little bit more context.

I believe it's just a matter of time until some brand name router home router start supporting it now with new generation Intel chips for embedded devices and NUCs supporting it.