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

[quinndiggity]

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"

[jow-]

This limitation is inherited from the bonding proto handler:

https://github.com/openwrt/packages/blob/openwrt-22.03/net/bonding/files/lib/netifd/proto/bonding.sh#L197

[quinndiggity]

@jow- inherited from, but also enforced here (luci-proto-bonding); both the openwrt/luci and openwrt/packages side of this are enforcing this limitation - #23676 was already opened to reflect that (sorry for not linking them already; doing that now, with this comment), so if you wouldn't mind transferring back to the openwrt/luci repo's issue tracker, it avoids the redundancy, and reflects the issue in the luci-proto-bonding + proto-bonding packages

[quinndiggity]

Will recreate, just to ensure this isn't lost to track the issue on openwrt/luci; end effect is attributable to both openwrt/packages as well as openwrt/luci