luci-mod-network: add support for netifd bonding device
#7086
Conversation
…ridge This is to prepare for tho bonding implementation, two configuration nodes cannot share the same name. Probably a more unique and precise naming would be better. Signed-off-by: hitech95 <[email protected]>
| o = this.replaceOption(s, 'devadvanced', form.Value, 'monitor_interval', _('Monitor Interval')); | ||
| o.description = _('Specifies the link monitoring frequency in milliseconds'); | ||
| o.placeholder = '100'; | ||
| // FIXME - we have to put a limit/range here somehow? |
There was a problem hiding this comment.
Example
o.datatype = 'range(0,500)';There was a problem hiding this comment.
I know that I can use the range method to specify the range as I already did on other controls, but the limit might depends on what you have selected as the preferred monitor system.
As the same value is used to configure MII or ARP monitoring.
See for arp_interval and miimon options in:
https://www.kernel.org/doc/Documentation/networking/bonding.txt
There was a problem hiding this comment.
What's sensible and what's absurd here? If they depend on others, then o.datatype is inflexible. Using o.validate allows access to other parameters already set via e.g.
var value = this ? this.section.formvalue('devadvanced', 'xyz'): 1000;Then.... decide based on those other values, or what's set.
netifd support for bonding devices has been added in commit 5ba9744, the other way to have bonding available in luci was via the luci-proto-bonding a and its proto-bonding dependency. This method forces to have an IP address on a bond interface due to a netifd limitation. This can causes some issues if you want to bridge an ethernet port and a bond. This patch aim to have the proto device to be configurable not as an interface protocol but as a device. Signed-off-by: hitech95 <[email protected]>
|
@systemcrash I've modified the limit above, the netifd takes an integer so I've used that limit in there as I wasn't able to find the real upper limit in the kernel documentation. I've also added dependencies for another parameter. and the "primary" interface selection for the active backup policy. |
|
@hitech95 Is this ready as-is? @svanheule is this something you could test in a switch environment to verify bonding functionality? |
|
@jow- any opinions? |
I'm afraid I'm currently not set up for this and I won't have time soon either to do so. |
Tested mainly on LACP on 2 uplinks. |
|
@hitech95 If you want to get this in sooner, I recommend drumming up a bit of support in the forums and see whether anyone else can verify this and throw it into their installation. Some of the switch threads would be a good start! |
|
@svanheule wonder if your situation has changed any? |
|
@systemcrash It hasn't and is unlikely to change the coming months. Most efficient way is probably to set something up yourself :) |
|
@hitech95 What device do you test on? Might be faster to find some guinea pigs in the forums who have the same device to be able to test. |
|
@systemcrash I'm gonna ask some guys if they can test it out too in the forum. |
|
I threw it out to a forum thread (slightly earlier than your post) for Realtek (GS1900), and the word is that the driver is currently broken (but not necessarily an older version?). But others may be inclined? |
|
I'm trying to get help from some friends to crete a virtual lab to test things out. I'll update you when some more test are completed.
The main stopper here is the lack of vendor devices with OEM firmwares to test against. |
|
Any progress on this? |
|
not yet :( |
|
@hitech95 found any other testers in the forums? |
|
|
||
| o = this.replaceOption(s, 'devadvanced', form.Value, 'ad_actor_system', _('MAC address for LACPDUs')); | ||
| o.description = _('This specifies the mac-address for the actor in protocol packet exchanges (LACPDUs). The value cannot be NULL or multicast.'); | ||
| o.datatype = 'macaddr'; |
There was a problem hiding this comment.
Perhaps a couple of error checks here to prevent NULL and multicast.
Can we add any predefined values here? e.g. 01:80:C2:XX:XX:XX? Or should this be the underlying MAC of the device(s) - which one could also probe for and provide?
There was a problem hiding this comment.
Added to my TO-DO list
|
Need to ascertain if bonding is supported on Realtek yet, then I can test here also. |
This pull request addresses a gap in Luci's functionality by introducing support for device type bonding configuration.
While Netifd already incorporates this capability, Luci currently lacks the means to manage it effectively through its web interface.