[PATCH] bonding: reject IEEE 802.15.4 devices in bond_enslave

[PATCH] bonding: reject IEEE 802.15.4 devices in bond_enslave

[Jiale Yao]

Bonding already refuses CAN devices because their protocol-specific state
is incompatible with the bonding model. IEEE 802.15.4 devices have the
same constraint: they keep protocol-specific state in
dev->ieee802154_ptr and do not use Ethernet link-layer semantics.

Extend the existing check to reject ARPHRD_IEEE802154 and
ARPHRD_IEEE802154_MONITOR devices before bonding changes their link-layer
settings.

Link: https://lore.kernel.org/netdev/aohMHTTH4VqqgZA7@fedora/
Link: https://lore.kernel.org/netdev/6001bd73-ef68-4820-8371-a22775fb820a@hartkopp.net/
Fixes: d5ae67bacd96 ("ieee802154: rework interface registration")
Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 drivers/net/bonding/bond_main.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 522eab060f9e..c716336c5172 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1894,9 +1894,11 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
 	struct sockaddr_storage ss;
 	int res = 0, i;
 
-	if (slave_dev->type == ARPHRD_CAN) {
+	if (slave_dev->type == ARPHRD_CAN ||
+	    slave_dev->type == ARPHRD_IEEE802154 ||
+	    slave_dev->type == ARPHRD_IEEE802154_MONITOR) {
 		BOND_NL_ERR(bond_dev, extack,
-			    "CAN devices cannot be enslaved");
+			    "CAN and IEEE 802.15.4 devices cannot be enslaved");
 		return -EPERM;
 	}
 
-- 
2.34.1

Re: [PATCH] bonding: reject IEEE 802.15.4 devices in bond_enslave

[Eric Dumazet]

On Mon, Aug 31, 2026 at 4:07 PM Jiale Yao <yaojiale02@163.com> wrote:
>
> Bonding already refuses CAN devices because their protocol-specific state
> is incompatible with the bonding model. IEEE 802.15.4 devices have the
> same constraint: they keep protocol-specific state in
> dev->ieee802154_ptr and do not use Ethernet link-layer semantics.
>
> Extend the existing check to reject ARPHRD_IEEE802154 and
> ARPHRD_IEEE802154_MONITOR devices before bonding changes their link-layer
> settings.
>
> Link: https://lore.kernel.org/netdev/aohMHTTH4VqqgZA7@fedora/
> Link: https://lore.kernel.org/netdev/6001bd73-ef68-4820-8371-a22775fb820a@hartkopp.net/
> Fixes: d5ae67bacd96 ("ieee802154: rework interface registration")
> Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
> ---
>  drivers/net/bonding/bond_main.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 522eab060f9e..c716336c5172 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1894,9 +1894,11 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
>         struct sockaddr_storage ss;
>         int res = 0, i;
>
> -       if (slave_dev->type == ARPHRD_CAN) {
> +       if (slave_dev->type == ARPHRD_CAN ||
> +           slave_dev->type == ARPHRD_IEEE802154 ||
> +           slave_dev->type == ARPHRD_IEEE802154_MONITOR) {
>                 BOND_NL_ERR(bond_dev, extack,
> -                           "CAN devices cannot be enslaved");
> +                           "CAN and IEEE 802.15.4 devices cannot be enslaved");
>                 return -EPERM;
>         }

What about ARPHRD_6LOWPAN ?

I think it is due time to use an allowlist in bonding (and team) to
stop applying bandaids.

Plan of action:

1) Add:

static inline bool netdev_type_is_lag_compatible(unsigned short type)
{
      return type == ARPHRD_ETHER || type == ARPHRD_INFINIBAND;
}

2) And use it in bond_enslave() and team_port_add()

Thanks.

pw-bot: cr

Re: [PATCH] bonding: reject IEEE 802.15.4 devices in bond_enslave

[Jay Vosburgh]

Eric Dumazet <edumazet@google.com> wrote:

>On Mon, Aug 31, 2026 at 4:07 PM Jiale Yao <yaojiale02@163.com> wrote:
>>
>> Bonding already refuses CAN devices because their protocol-specific state
>> is incompatible with the bonding model. IEEE 802.15.4 devices have the
>> same constraint: they keep protocol-specific state in
>> dev->ieee802154_ptr and do not use Ethernet link-layer semantics.
>>
>> Extend the existing check to reject ARPHRD_IEEE802154 and
>> ARPHRD_IEEE802154_MONITOR devices before bonding changes their link-layer
>> settings.
>>
>> Link: https://lore.kernel.org/netdev/aohMHTTH4VqqgZA7@fedora/
>> Link: https://lore.kernel.org/netdev/6001bd73-ef68-4820-8371-a22775fb820a@hartkopp.net/
>> Fixes: d5ae67bacd96 ("ieee802154: rework interface registration")
>> Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
>> Signed-off-by: Jiale Yao <yaojiale02@163.com>
>> ---
>>  drivers/net/bonding/bond_main.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>> index 522eab060f9e..c716336c5172 100644
>> --- a/drivers/net/bonding/bond_main.c
>> +++ b/drivers/net/bonding/bond_main.c
>> @@ -1894,9 +1894,11 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
>>         struct sockaddr_storage ss;
>>         int res = 0, i;
>>
>> -       if (slave_dev->type == ARPHRD_CAN) {
>> +       if (slave_dev->type == ARPHRD_CAN ||
>> +           slave_dev->type == ARPHRD_IEEE802154 ||
>> +           slave_dev->type == ARPHRD_IEEE802154_MONITOR) {
>>                 BOND_NL_ERR(bond_dev, extack,
>> -                           "CAN devices cannot be enslaved");
>> +                           "CAN and IEEE 802.15.4 devices cannot be enslaved");
>>                 return -EPERM;
>>         }
>
>What about ARPHRD_6LOWPAN ?
>
>I think it is due time to use an allowlist in bonding (and team) to
>stop applying bandaids.
>
>Plan of action:
>
>1) Add:
>
>static inline bool netdev_type_is_lag_compatible(unsigned short type)
>{
>      return type == ARPHRD_ETHER || type == ARPHRD_INFINIBAND;
>}
>
>2) And use it in bond_enslave() and team_port_add()

	Agreed, although the list might need to be more than just ETHER
and INFINIBAND.  I recall that folks in the past have bonded ethernet
with wifi; does wifi show up as ARPHRD_ETHER or ARPHRD_IEEE80211?  A
quick grep suggests that most of them are ETHER, but not all.

	Dummy interfaces are used a lot in the tests, but those should
be ETHER.

	-J

>Thanks.
>
>pw-bot: cr

---
	-Jay Vosburgh, jv@jvosburgh.net