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

Eric Dumazet [off-list ref] wrote:

On Mon, Aug 31, 2026 at 4:07 PM Jiale Yao [off-list ref] wrote:

quoted

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/ (local)
Link: https://lore.kernel.org/netdev/6001bd73-ef68-4820-8371-a22775fb820a@hartkopp.net/ (local)
Fixes: d5ae67bacd96 ("ieee802154: rework interface registration")
Suggested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Jiale Yao <redacted>
---
 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