luci-proto-bonding: ethernet bonding interface (device) dhcp client functionality hindered (re-opened)

quinndiggity commented 6 months ago

Per- https://github.com/openwrt/packages/issues/23677#issuecomment-2002278900 - re-opening this to track the issue/fix on the openwrt/luci end of things.

Steps to reproduce:

go to: Network → Interfaces → Add new interface... or bond0 (a Link Aggregation (Channel Bonding) interface) → Advanced Settings
add one or more Slave Interfaces
Set Bonding Policy to IEEE 802.3ad Dynamic link aggregation (802.3ad, 4)
go to: General Settings tab
clear IPv4 address and IPv4 netmask
Save

Actual behaviour:

Expecting: non-empty value
Unable to create a Layer 2 bonding interface which can directly requisition an IP via DHCP
The link aggregation device must be configured with a dummy non-colliding address (such as a loopback address) which serves no purpose/has potential to cause tangential issues which would otherwise be unnecessary (with regards to the Linux bonding driver itself)
A parent bridge device containing the subsequently generated bond-bond0 device, as expected, can be configured as part of a DHCP client interface, rendering the mandated dummy static IP assigned to the bond interface entirely redundant

Expected behavior:

A bonding Device (not an Interface, per the LuCI abstraction) can be created directly, without the requirement of a dummy static IP, and have its address managed with any combination of:

as part of a Static address interface
as part of a DHCP client interface
as part of a parent bridge device, which itself is managed with a DHCP client interface

Additional Information:

using DHCP for a bonded interface (per the Linux kernel terminology) is supported (but requires active slaves, of course; something has to be able to broadcast the DHCP request)
most tools in the Linux ecosystem have supported DHCP for bonded devices since at least 2004
for example, netplan does not require either static or DHCP addresses to be configured, but also accepts and works perfectly fine with either approaches

NAME="OpenWrt"
VERSION="SNAPSHOT"
ID="openwrt"
ID_LIKE="lede openwrt"
PRETTY_NAME="OpenWrt SNAPSHOT"
VERSION_ID="snapshot"
HOME_URL="https://openwrt.org/"
BUG_URL="https://bugs.openwrt.org/"
SUPPORT_URL="https://forum.openwrt.org/"
BUILD_ID="r25529-1d3d6ef826"
OPENWRT_BOARD="mediatek/filogic"
OPENWRT_ARCH="aarch64_cortex-a53"
OPENWRT_TAINTS=""
OPENWRT_DEVICE_MANUFACTURER="OpenWrt"
OPENWRT_DEVICE_MANUFACTURER_URL="https://openwrt.org/"
OPENWRT_DEVICE_PRODUCT="Generic"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="OpenWrt SNAPSHOT r25529-1d3d6ef826"

quinndiggity commented 6 months ago

On the openwrt/luci / luci-proto-bonding end of things, this limitation is enforced here

On the openwrt/packages / proto-bonding end of things, this limitation is enforced here

Issue to track openwrt/luci is here
Issue to track openwrt/packages is here

jow- commented 6 months ago

I don’t think the luci-proto-bonding package will receive fixes to support non-static config, it should rather become deprecated in favor to bonding device config support which is present in netifd since https://github.com/openwrt/netifd/commit/5ba9744aac6d42da1e56357aca951b52f86cfacb

That also conceptually works better since bonding devices are a layer 2 config, not a layer 3 (proto) one.

openwrt / luci