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

[quinndiggity]

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:

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

Actual behaviour:

1. Expecting: non-empty value
2. Unable to create a Layer 2 bonding interface which can directly requisition an IP via DHCP
3. 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)
4. 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:

1. as part of a Static address interface
2. as part of a DHCP client interface
3. 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]

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

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.