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)

• https://github.com/vyos/vyos-build/pull/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[bot]]

❌ 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[bot]]

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

[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?

[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.

[c-po]

This PR came up again in todays maintainer meeting.

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck

Could we simply rename the thunderbold interfaces to eth* interfaces so all the other code pieces can be re-used?

[rafaelgaspar]

Not really sure how I would do that without name clashing.

The renaming can be done via systemd networking, but it requires the PCI address of the controller, that is normally the same on on-board controllers, but will not be same for extra controllers.

It does behave quite similar to ethernet so it does make some sense.

Hot plug would still be a good to have feature for it to be completely useful, in theory it could be used a lot by Macbooks and you don't expect to have to restart your router when coming home and connecting your notebook. But maybe that's not the main user base for vyos, and possibly not worth the effort just for this.

I guess the use case is still not quite where I described in the last comment, although more and more devices are going into that direction, like for example the Minisforum NAS N5 Pro announced at CES this year.

I personally am using it with Minisforum MS-01.

IMHO, it's not a ticket that should be prioritized on your side, I might still work on my free time every now and then to try to improve my personal use case.

Have you heard of more people using/requesting the feature?

[github-actions[bot]]

CI integration 👍 passed!

Details

CI logs

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

[c-po]

Have you heard of more people using/requesting the feature?

You are the first bringing this idea up.

[rafaelgaspar]

You are the first bringing this idea up.

I see, there is quite a few people in the homelab comunity experimenting with thunderbolt net, I guess I was one of the few crazy ones that decided to use vyos for my home router, ehehhehe, I really like how it's based on modern debian and the way configuration works.

Thanks for the help regardless, I'll try to keep improving this branch by myself, and maybe some day it will be user friendly enough for a release, for now maybe tag the PR differently and you shouldn't put work on it, I'll keep doing my experiments on it.

Or if you prefer I can close the PR and keep working only on my personal branch.

[dmbaturin]

@rafaelgaspar I discussed it with @c-po and the decision is that we do not want to make Thunderbolt interfaces special. At the datalink layer, they are Ethernet interfaces and should behave as such. All improvements for support for them needs to work within the current framework of interfaces ethernet, like it does for USB Ethernet devices.

Thanks for your effort, and if there's anything you see we can add to that code to better support Thunderbolt, please open new PRs!