netdev - Re: net: thunderbolt: missing ndo_set_mac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251121060825.GR2912318@black.igk.intel.com>
Date: Fri, 21 Nov 2025 07:08:25 +0100
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Ian MacDonald <ian@...statz.com>
Cc: Mika Westerberg <westeri@...nel.org>,
	Yehezkel Bernat <YehezkelShB@...il.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, 1121032@...s.debian.org
Subject: Re: net: thunderbolt: missing ndo_set_mac_address breaks 802.3ad
 bonding

Hi Ian,

On Thu, Nov 20, 2025 at 03:59:15PM -0500, Ian MacDonald wrote:
> Hi,
> 
> 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.
> 
> Hardware: AMD Strix Halo (Framework connect to Sixunited AXB35 USB4 ports)
> Kernel:  6.12.57 (also reproduced on 6.16.12 and 6.18~rc6)

Okay "breaks" is probably too strong word here. It was never even supported
:)

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

Can you describe what are the actual commands you run so I can try to
setup on my side and see how this could be implemented?

> 3. Observe that bonding fails to set the slave MAC addresses and logs:
> 
>    [   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
> 
> 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.
> 
> >From reading drivers/net/thunderbolt/main.c:
> 
> - thunderbolt_net 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 define:
>     .ndo_open
>     .ndo_stop
>     .ndo_start_xmit
>     .ndo_get_stats64
>   but do 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.
> 
> A bit of research suggests it should be possible to implement
> ndo_set_mac_address using
> eth_mac_addr(), and, if appropriate, mark the device with
> IFF_LIVE_ADDR_CHANGE so MAC changes while the interface is up are
> allowed.   I have a feeling there is a lot more to it;

Probably, I need to check this but first I need some way how to reproduce
this :)

> 
> There is a corresponding downstream Debian bug with additional
> hardware details https://bugs.debian.org/1121032
> 
> Thanks,
> Ian