Wishlist: Config-Mode UI for Interface Roles Feature

[lemoer]

(At the 2022-01 Gluon meeting it was decided to open this issue).

With #2372 gluon will officially start supporting the assignment of roles to network interfaces. This means that there is no longer a fixed mapping between network interface and the functionality assigned to that interface. Instead, each network interface is now assigned a user-modifiable list of roles. Since the list of roles is not only user-modifiable, but also allows for additional user-defined interfaces, Gluon's network configuration is much more flexible than before.

However, only the backend part is implemented in #2372. The user interface still needs to be discussed. Since there have been numerous discussions (in many issues) over a long period of time, this issue is intended to work towards a coordinated wish list (that can be implemented).

So far, I have collected links to related issues:

• Concept for port reconfiguration #284
• Seperate mesh-on-LAN links #1104
• package to set wan on all ports #1174
• RFC: use vlans on lan #1208
• Add support for 3 or more network interfaces #1564
• gluon-web: Modular WLAN and network interface configurations #1670
• RFC: Offical way supporting additional Mesh- and Client-Interfaces as "user"-defined-interface #1987
• [Feature request] single_as_lan as a config option #2295

Playing Around with #2372:

The interface to role assignment is defined in /etc/config/gluon:

root@router:~# cat /etc/config/gluon
[...]
config interface 'iface_wan'
	option name '/wan'
	list role 'uplink'

config interface 'iface_lan_vlan43'
	option name 'eth0.43'
	list role 'client'

There are two ways of specifying the name option an interface here:

• The / in at the beginning of /wan indicates that the actual interface name should be read from /lib/gluon/core/sysconfig/wan_ifname.
• eth0.43 directly refers to the interface name.

VLAN devices like eth0.43 will be working directly (without explicit configuration of a vlan interface), since netifd creates vlan interfaces implicitly on demand.

Currently the roles uplink, client and mesh exist.

After /etc/config/gluon has been modified, gluon-reconfigure has to be called to regenerate /etc/config/network. After that, the network has to be restarted using /etc/init.d/network restart.

[belzebub40k]

This is pretty cool and would hopefully solve the problems we have with our nodes running several gluon_wired mesh links over directional radio. I've played around with #2372 a bit and so far I'm only missing one thing which is dedicated gluon_wired interfaces per configured mesh interface. At first I thought this is not an issue but the downside of having all interfaces in the same gluon_wired/vxlan interface is that every node can see every other node even if there is no direct physical path between them. In the past we configured dedicated gluon_wired interfaces for each link to work around this. Right now this configuration is still possible but it does not look nice and may break again in the future as we have to duplicate the firewall zone wired_mesh and add the gluon_wired interfaces with the gluon_preserve flag directly in /etc/config/network.

The easiest way to improve this would be to sort the upgrade script 997-migrate-preserved before the 300-firewall-rules which will result in adding the custom gluon_wired interfaces to the wired_mesh zone during gluon-reconfigure. But to be honest this still isn't very nice. It would be really nice if there is an option to create individual gluon_wired interfaces via /etc/config/gluon.

[AiyionPrime]

Just stumbled across @kpanic23 s mockup from 2017

Maybe a button could also be included to create VLAN IDs on the ports to carry two or more of the network types.

Originally posted by @kpanic23 in #1174 (comment)

[lemoer]

@AiyionPrime The mockup from @kpanic23 would be a good first step.

But we could allow doing more. The backend code also allows adding arbitrary (?) vlans on top of the lan/wan ports and assigning roles to them.

[lemoer]

In general, I would assume, that we need kind of an "interface discovery", that returns a list of interfaces where roles can be assigned. This would be helpful in cases where people add additional interfaces to the node (e.g. usb network adapters, pci network cards, virtual network cards, ...).

[lemoer]

We should also check the differences between DSA and swconfig devices. I would assume the following:

• We can support vlan creation for both DSA and swconfig.
  • Creating vlans for swconfig devices requires using swconfig, because otherwise the switch would probably drop the new vlan.
• For swconfig devices, lan ports will show up as one interface, so that only one role can be assigned to all of them.
• For swconfig devices, lan ports will show up as one interface, so vlans can only be added to all lan ports at the same time.

But these are just assumptions. We should check them.

[lemoer]

I am not quite sure, but I think there are role combinations, that should be forbidden on the same interface. I would say:

• uplink & client on the same interface must be forbidden.
  • Since there is no VXLAN (or so) involved, this would bridge the uplink network into the client network.
• mesh & uplink on the same interface is ok.
  • VXLAN should separate them.
• mesh & client on the same interface might be problematic? Not sure.
  • This might lead to loops.
  • And I am not even sure, whether this would be useful at all?

[lemoer]

we need kind of an "interface discovery"

If I look at the wired interfaces on my TP-Link TL-WDR4900 (with swconfig), there are:

• eth0 - not connected to anything
• eth0.1 - connected to lan ports (untagged)
• eth0.2 - connected to wan ports (untagged)

I would say, it makes sense to only show eth0.1 and eth0.2 in the UI. However, without using further information from e.g. swconfig, eth0 is not distinguishable from eth0.1 and eth0.2. This way, it becomes hard to hide the entry of eth0.

[s-2]

Remembering a conversation with @CodeFetch, I would like to append

• port color
• port position

to the wishlist, which could pave the way for more unambiguous visual representations of device ports, similar to the LuCI switch configuration page.

Regarding position, there might be a trade-off between flexibility and simplicity (for "ordinary devices") here, but I think when using appropriate defaults, even a semantic port location structure like

device face (front, rear, side, ..) -> row index (from upper to lower) -> column index (from left to right)

would be feasible to add (i.e. face and row would remain zero for >90% of devices and not required in ucidef_add_...).

Especially the color in combination with port labelling seems to become more important to avoid confusion among users, with commercial "mesh" equipment hitting the shelves that is not even meant to replace ISP routers anymore (way too much support effort, also users rely on telephony from that box etc.), thus deviating from traditional port roles or even using auto-detection (enable DHCP when no DHCP server was detected on the port).

For example, devices from the COVR-X1862 kit have two ports labelled Internet (WAN) and Ethernet (LAN).
One of them is gray. Guess which one is yellow 🙂
Obviously, the one that the user is supposed to connect to the yellow port on their uplink router...

[AiyionPrime]

@s-2 That would be device information that is not yet available, neither in openwrt nor gluon, is it?

While I think it might be an interesting extension and might help the users to understand their device faster, I'd recommend not integrate that feature in the same PR as the one that solves this issue.

Your (or @CodeFetch's) suggestion appears to be an orthogonal feature to everything in the current wishlist and neither hinder or support any other feature in it for now.

[s-2]

device information that is not yet available, neither in openwrt nor gluon

Right, there is no such data structure in gluon nor openwrt at the moment, and I believe the latter might not express that much interest either (although there's also e.g. label-mac, which was basically introduced due to demand from the gluon community).
Maybe when designing UI components for port roles configuration, this is something that could be kept in the back of mind though, regarding compatibility towards future extensions.

Creating vlans for swconfig devices requires using swconfig, because otherwise the switch would probably drop the new vlan

I would say, it makes sense to only show eth0.1 and eth0.2 in the UI.

Another thought that I dropped earlier (lunch break suddenly was over) regarding eth0 and eth1 vs. the "dot interfaces" was the discussion about adding a device that has both LAN ports connected to a gigabit switch, which is again connected to both GMACs of the SoC. We eventually decided not to force one of the ports to be WAN here (mostly since the user would typically flash via the only PoE-enabled port and lock themselves out if that changed to WAN after flashing); if needed, the user could manually create a new interface (on the other GMAC), name it wan and assign the vlan tag to the desired switch ports.

Unfortunately, this resulted in a randomized mac address (re-generated with every reboot) being assigned to wan, as OpenWrt only explicitly fixes the lan and wan mac addresses for the corresponding eth0.1, eth0.2 etc. interfaces, but not for the "root" interface that others will be derived from, and the user typically wouldn't know they must manually assign a mac address here.
This is (/was) actually true for many OpenWrt devices using swconfig (until superseded by DSA), but for that particular device this was fixed by assigning the mac in preinit.

But as far as I understand the implementation of port roles in #2372, this is not an issue here (unless we would actually allow adding interfaces for swconfig devices), since the roles just map to either uplink (WAN MAC), client (LAN MAC) and mesh (MAC generated by gluon)?