[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1121032: thunderbolt_net: missing ndo_set_mac_address prevents bonding mode 802.3ad



Control: tags -1 + moreinfo upstream

Hi Ian,

On Wed, Nov 19, 2025 at 03:46:46PM -0500, Ian MacDonald wrote:
> Package: src:linux
> Version: 6.12.57-1
> Severity: normal
> X-Debbugs-Cc: ian@netstatz.com
> 
> Using two Thunderbolt network interfaces as slaves in a bonding device in
> mode 802.3ad (LACP) fails because the bonding driver cannot set the MAC
> address on the thunderbolt_net interfaces.
> 
> The same setup works in mode active-backup.
> 
> kernel dmesg: 
> 
> [   25.922317] bond0: (slave thunderbolt0): The slave device
> specified does not support setting the MAC address
> [   25.922328] bond0: (slave thunderbolt0): Error -95 calling
> set_mac_address
> [   25.980235] bond0: (slave thunderbolt1): The slave device specified
> does not support setting the MAC address
> [   25.980242] bond0: (slave thunderbolt1): Error -95 calling
> set_mac_address
> 
> Steps to reproduce:
> 1. Create a bond with mode 802.3ad and add thunderbolt0 and thunderbolt1
>    as slaves.
> 2. Bring up the bond and slaves.
> 3. Observe that bonding fails to set the slave MAC addresses and logs the
>    errors above.
> 
> Expected result:
> - bond0 and both Thunderbolt interfaces share bond0's MAC address.
> - 802.3ad operates normally and the link comes up.
> 
> Actual result:
> - dev_set_mac_address(thunderboltX, bond0_mac) fails with -EOPNOTSUPP.
> - bonding reports that the slave does not support setting the MAC address
>   and cannot use the interfaces in 802.3ad mode.
> 
> Analysis:
> - In drivers/net/thunderbolt/main.c the driver generates a locally
>   administered MAC from the Thunderbolt UUID and sets it with
>   eth_hw_addr_set().
> - The net_device_ops for thunderbolt_net currently defines:
>     .ndo_open
>     .ndo_stop
>     .ndo_start_xmit
>     .ndo_get_stats64
>   but does not implement .ndo_set_mac_address.
> - As a result, dev_set_mac_address() returns -EOPNOTSUPP, and bonding
>   treats the device as not supporting MAC address changes and logs the
>   error above.
> 
> From reading the driver, Thunderbolt networking appears to be purely
> software/encapsulated Ethernet frames without a hardware MAC filter to
> reprogram. It should therefore be possible to implement
> ndo_set_mac_address using eth_mac_addr(), and optionally mark the device
> with IFF_LIVE_ADDR_CHANGE so that MAC changes while the interface is up
> are allowed.
> 
> Upstream (drivers/net/thunderbolt in Linus’ tree) also lacks
> ndo_set_mac_address, so this would likely need to be fixed there as
> well and then pulled into Debian.
> 
> If you’d like, I can test patches on this hardware.

I'm defintively not fulent in the thunderbold specifics, but if the
support is possible then you might want to bring that directly to
upstream. You can contact the relevant people via:

$ ./scripts/get_maintainer.pl drivers/net/thunderbolt
Mika Westerberg <westeri@kernel.org> (maintainer:THUNDERBOLT NETWORK DRIVER)
Yehezkel Bernat <YehezkelShB@gmail.com> (maintainer:THUNDERBOLT NETWORK DRIVER)
Andrew Lunn <andrew+netdev@lunn.ch> (maintainer:NETWORKING DRIVERS)
"David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING DRIVERS)
Eric Dumazet <edumazet@google.com> (maintainer:NETWORKING DRIVERS)
Jakub Kicinski <kuba@kernel.org> (maintainer:NETWORKING DRIVERS)
Paolo Abeni <pabeni@redhat.com> (maintainer:NETWORKING DRIVERS)
netdev@vger.kernel.org (open list:THUNDERBOLT NETWORK DRIVER)
linux-kernel@vger.kernel.org (open list)

When you do fill the issue and request upstream, can you please keep
this downstream bug in the loop so we are aware?

Regards,
Salvatore


Reply to: