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

[quinndiggity]

Maintainer: @he-ma

Steps to reproduce (using luci-proto-bonding - src):

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

• No local IP address defined
• https://github.com/openwrt/packages/blob/master/net/bonding/files/lib/netifd/proto/bonding.sh#L199

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"

[brada4]

ip4 is not needed for lacp, it is remnant from times netcards could not sense cable present (pre-gigabit) and had to resort to arp requests to gateway going missing as link indication. You can comment out section you identified, now decades after it was useful.

[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

[brada4]

Remove duplicate posts, thanks.