Introduce support for managing config device and config bridge-vlan sections
#4307
Conversation
jow-
force-pushed
the
uci-network-device-support
branch
from
918dbf8
to
8e6df32
Compare
|
@jow- I should be running the latest netifd git (checked out yesterday, latest commit 645ceed0) but I'm not seeing the LAN bridge (MT7621, DSA). Or is this to be expected with DSA setups?
|
|
@Borromini - yes this is expected and prevented atm since it leads to undefined results in netifd. Once we have http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030397.html and a migrated default config, the switch0 / br-lan bridge (or however name we settle on) will appear. |
|
Any progress with this? It seems that discussion on http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030397.html has been stopped for a while. |
|
I hope this will be implemented soon. I'm still using an older build with swconfig for my WRT3200ACM to avoid DSA as I couldn't find a solid guide on howto convert my current swconfig into a DSA one. |
|
+1 |
|
I've tested this code and it looks impressive. Unfortunately it's still not production-ready. LuCI properly handles DSA wired networks but will mess up wireless configuration and what's worse, trying to fix wireless you will mess wired config so double check what changes are to be commited! There seem to be four issues:
Having said that, for the time being you'd be probably better off converting network configuration using plain old
After this setup, the only bridge should be Now you can either try to reload network and commit changes if everything works: or backup configuration, commit changes and reboot router. Next step is to fix wireless network setup:
Once again: don't change You can then reload WiFi networks: and commit changes if everything is working properly. |
The scope of this PR has intentionally been to cover the wired part only, wireless interface are explicitly filtered out even in various places. The idea was that you either build bridges containing both switch0.1 and the wireless ifaces, much like it is being done with swconfig today, or that we implement support for
If you convert an interface from bridge to non-bridge, LuCI will simply remove all but the first ifaces from it, this is why the
Likely because the target network is not empty (as in has one iface configured already). So LuCI will turn it into a bridge and add the subsequent ifaces to it.
As written above, this is by design. In OpenWrt's configuration model, we never configure wifi iface names in /etc/config/network since the names are unpredicatable and in some cases there's not even a 1:1 relation of wifi-ifaces to interfaces. For example, one AP/VLAN wifi-iface can result in 1+N different wifi netdevs (e.g. Due to that, wifi-ifaces need to be "attached" to networks through
As explained above, it is highly discouraged to directly add wifi-netdevs as bridge members on OpenWrt, and LuCI does very little to support it. So to recap; right now a configuration should look like this (non-relevant parts omitted): This should result in a bridge setup like Once the RFC patch series mentioned above is merged (and LuCI support has been implemented), This should result in a bridge setup like While your proposed manual config conversion works which manually adds wifi ifaces as ports to bridge-vlans it will fail for AP/VLAN interfaces which result in more than one netdev per wifi-iface. |
|
Hi Look at the config that I've posted. It's precisely your example except for the wireless BTW Could you elaborate on My point was that it's not possible - at this stage - to convert and edit configuration from UI and it's behavior can even soft-brick the device.
Sorry, I don't buy this. Purely for reference let's take your example If Which leads us to this:
Sorry, it's not. I admit, it's attached but non-bridge network is forcibly changed to bridge. That's the second issue:
At that point user can either commit the changes (which breaks See my point? Having one of these issues is annoying but with extra steps you can convert (or further edit) the configuration. With both of them it's impossible.
Where did I set wifi interface name in Now for the
I don't understand this part. Previously there was a single bridge per network. Right now, with vlan filtering it's sufficient to have a single bridge per device regardless of how many networks you have. Is this subject to change?
Please tell us more about wireless Please consider the first two issues again. If wireless part of configuration cannot be edited yet, that's understandable. But it's completely different story if you can neither enter nor edit entirely valid network configuration and it gets broken every time you touch it from UI. |
I didn't say that it won't work, I tried to explain that adding wifi ifnames to the network config is discouraged, precisely due to the 1:n problem of wifi opmodes that result in more than one netdev per wifi-iface. Granted, in a naive WPA-PSK AP setup this case does not apply, but it will with AP/VLAN interfaces.
No it is not committed, atm it is a pending proposal. The value format is A If
Correct, since neither LuCI nor netifd support all the necessary config semantics yet. Primarily, the support for attaching a Since OpenWrt is going to revise its default DSA network configuration, and since no config migration is going to happen on the OpenWrt side either, I did not take the ability of a full config rebuild via ui into consideration and instead require a more or less clean state on top of revised default config. Since the revised OpenWrt default network config will also declare bridge devices explicitly (through
In my first example you need to keep the br-lan bridge to bind switch0.1 to wifi, there is no need to remove the bridge config at all. That other example where I was commenting on your general assertion that
If you untick the Having both an
As explained above, it seems you're thinking about a different use-case here (
I was trying to point out that attaching
Sure I see it, as I said it is a limitation of netifd atm, such a configuration would be semantically invalid with current netifd Git HEAD.
Here:
Not with e.g.
Right now there is no working method without using an additional bridge as an interim solution, until patches [1]-[3] land in netifd.
It is not supported by LuCI yet because it is not supported by netifd yet.
It is not subject to change, the end goal is to have one bridge with VLAN filtering (my second example, which is not fully implemented yet). The current implementation level in netifd does not fully support that yet though, so at the moment the only choices are:
Once netifd changes are fully implemented, LuCI support will be amended to support this configuration.
It is not yet supported yet but once it lands in netifd, I'll do more changes on top of this one to support it. One will both be able to implicitly manage it by adding wifi-netdevs to the bridge filter configuration in the ui or to explicitly set it in the wireless wifi-iface configuration dialog. |
As I said, I don't like it either but that turned out to be the only option that works.
Thanks for explaining. That's a bummer. I'm looking forward to it but it looks like until it's commited we're forced to adding wireless device names to
I still don't get this. It's possible and works correctly in git master i.e. adds wireless devices to bridge
So there's going to be yet another forced migration? Nice. The problem with Luci is that it currently handles neither migration nor modyfing already migrated config. Simply changing network assigned to wireless device break things.
Of course it's up to you but IMO something has to be done. LuCI enforces rules that's been correct for a long time but now they're out of sync with netifd. Maybe it should distinguish (regardless of implicit or explicit notation) between old-style bridge per network and new style single bridge per device since both are currently valid even on DSA-enabled devices? If that's not worth the effort simply removing some of the rules would be probably better than enforcing changes that break network connectivity.
Luci won't allow but netifd will (purposely or not). That's my point. Even LuCI with bridge VLAN filtering is out of sync with netifd already commited to master.
Believe me that - purposely or not - If it's invalid then netifd does poor job of validating network config but it's good after all - that way it's possible to configure WiFi networks even it's abusing abusing network subsystem a bit.
Purely semantical: that's a reference to interface name. It's set in wireless config.
My bad. For clients it's a single AP (yes, I know the scheme, I've used it before :)
No. There's working method (intentionally or not) without additional bridge. The only downside is the need to reference wireless device name in VLAN ports sections. When these patches are merged, VLANs are going to be specified in wireless section and refering to wireless devices in Thank you again for explaining everything and excuse my curiosity. There's still no doc. The only piece of information is somewhat unfinished mailing list discussion and network daemon source code. I'm going to keep network device names referenced in |
Apart from an extraneous bridge, not at the moment.
I don't get it either because such a config is definitely not working for me, the following uci yields an result where the wifi interfaces are not added to switch0 which is expected since netifd does not handle that yet: Result: Turning "lan" back into an additional bridge itself will work:
This is what I do not understand, I was able to reconfigure the system into the br-lan + switch0 config without any soft-brick or connection loss, I recorded the ui steps here: http://mein.io/rebuild-config-2020-09-29_11.04.25.mp4 Of course this results in the interim solution of using two bridges and I also did some extraneous steps (like disabling bridge on br-lan instead of simply replacing eth0 with switch0.1 and implicitely re-enabling the br-lan bridge by resetting the network association in the wifi config). In any case there was no soft brick. But maybe actual DSA capable hardware behaves differently, which would hint at a bug in OpenWrt though if the same steps result in a brick there.
Unless I totally misunderstood your supposedly working config there aren't any out of sync rules right now.
As written above, it did not work for me, neither on actual hardware when I developed these changes a few weeks ago nor just now when re-testing on Qemu x86/64.
Maybe it would make sense to provide the complete /etc/config/network and /etc/config/wireless that is working. I get a hunch that we're talking about different things. Or maybe it is due to your
Sure, this method is working in some cases but it is discouraged and will not be supported by LuCI. As written earlier, it is not compatible to all operation modes and requires setting fixed wifi netdev names. |
|
Jo, thank you once more for testing. This looks very confusing but unfortunately I lack the time needed to double check everything tried in the past and this would serve no practical purpose. As far as I remember, using old approach (bridge per network without What I'm sure is that configuration with reference to wlan device name in Since you've already explained that attaching wireless devices to Forgive me if you find any part of this or previous comments rude or offensive, of course that was not my intention. For the record: the firmware tested was compiled from openwrt/openwrt@2a90d30 but that shouldn't be of much difference to snapshots binaries. The hardware was Netgear R6220 (ramips; two devices supposed to be the same revision). Handles both tagged and untagged traffic (even mixed on some ports) and most of the networks have attached one or two WiFi APs.
The reference to wlan device is missing here. I don't recall if that made any difference though. Never mind.
I'm almost certain (too late now to test this again) that it didn't work on my hardware. You seem to be testing this on a virtual environment. There's a couple of factors that could make the difference, including Linux drivers and even hardware implementation. |
|
What's the status of this? It appears to be a release blocker for the next OpenWrt releaes. |
|
Also some type of documentation for the netifd support of dsa would be very good. Can't find anything on the wiki |
Wireless bridge-vlan support is missing yet. |
|
@jow- Thanks for all your contributions, is the Wireless bridge-vlan support tracked somewhere else? |
|
If wlan interfaces don't work on a VLAN-aware bridge, you can create a separate VLAN-unaware bridge to connect them. |
Can it still be merged in its current state? Having a working GUI for ethernet switch, even without wifi support, would be still much better than having no GUI for this at all. As a workaround the wifi can be placed on a different bridge |
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
The introduction of network device configuration support also implemented all common, protocol-independent interface options directly in the interface config view, so drop the redundant option definitions. Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
jow-
force-pushed
the
uci-network-device-support
branch
from
8e6df32
to
bbf1a53
Compare
This has been fixed with 3b4c161
LuCI will still filter wireless devices but due to the commit linked above, you can now attach them indirectly to specific bridge-vlans through the existing "option network" setting in the wireless configuration. Considering the following example network configuration: ... you can now set a wifi-iface "option network" to "vlan200" and it'll cause the related I would've loved to offer an ability to manage wireless bridge membership directly from the bridge VLAN configuration matrix but the logic turned out to be too complex and brittle so I decided against it. So far upstream insists on keeping At a later state I'll take a stab at implementing a new |
|
when will this PR be backported to 21.02 branch? it's nice if it could be shipped in first 21.02 release. |
|
Yes, once it received some more testing. |
ghost
mentioned this pull request
|
I managed to get my LAN with tagging working on the WRT3200ACM, so that's great. Thanks a ton. |
|
it seems that it broke luci interfaces section as well, here is my lan bridge interface, it shouldn't be like this |
|
@ivanich - it is supposed to look this way if a |
|
@jow- the interesting part is that I did full config reset and the defaults looks similar as in the screenshot above. That's all I have after config reset |
|
@ivanich - interesting. Can you provide the complete |
|
@jow- here you go, after a full reset Im owning multiple devices, DSA and non DSA - all of them has issue after this PR was merged, worth to say that creating interfaces via Network->Interfaces->Devices doesn't work either, it simply shows interface in the WebUI but it never gets actually created in the system |
|
I had the same happen to me both the bridge issue and an issue in that the br-lan was conflicting with the new bridge in that it was using the same vlan (which it wasn't), also, after setting up the bridge with vlan filtering, I had to go to the device tab and add each interface manually ( by means of "add interface configuration") for them to work properly with the new switch, it was scary 😅 |
Ref: #4307 (comment) Fixes: faad746 ("luci-mod-network: add support for network.device sections") Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
@ivanich - that issue should be fixed now. |
|
@jow- confirmed, thanks. |
|
I realised luci cannot be used to configure "self": https://unix.stackexchange.com/questions/484644/what-are-self-and-master-options-for-in-bridge-vlan-add Is this intentional? Specifically, I am trying to isolate like here: https://vincent.bernat.ch/en/blog/2017-linux-bridge-isolation#using-vlan-aware-bridge |
|
@heri16 - the |
|
Hey, I have been following this PR for a while now, and was wondering if someone could explain to me what exactly this allows us to do inside Luci that isn´t already possible? I receive my internet on my WAN port tagged with VLAN 6 and IPTV tagged with VLAN 4. Furthermore, I have two different subnets (on their own untagged VLANs) and they are correctly separated. This was all configured in 21.02 snapshot inside the Luci interface, no command line needed whatsoever. This is how my /etc/config/network looks like: Given that this was already possible from the GUI, what exactly does this PR allow us to do that isn´t already possible? I am trying to get a better understanding of DSA in the coming 21.02 release and how this PR influences the way we configure this, and was hoping to get a better understanding of it all. Thank you very much in advance! |
For your setup (spawning a bunch of VLAN interfaces on top of a standalone |
|
Hey @jow- , when I save my wireless configuration Luci tries to add the wlan to the lan interface. Maybe it's because I have a custom ifname in my wifi config?
|
Introduce support for managing `config device` and `config bridge-vlan` sections
Ref: openwrt#4307 (comment) Fixes: faad746 ("luci-mod-network: add support for network.device sections") Signed-off-by: Jo-Philipp Wich <jo@mein.io> (cherry picked from commit edf640a)
|
@jow- |
|
On my setup, when I enable igmp snooping it breaks ipv6 |
Is multicast querier enabled? Or is it an Android device? |
|
Sorry for the delay, I just got home to make sure of what I'm saying. So, When I enable The IGMP snooping option in the bridge devices at first get an IPv6 address, but then lose it, after that they never get it again.
|
| @@ -649,5 +818,167 @@ return baseclass.extend({ | |||
| o.default = o.disabled; | |||
| o.depends(Object.assign({ multicast: '1' }, simpledep)); | |||
| } | |||
|
|
|||
| o = this.addOption(s, 'bridgevlan', form.Flag, 'vlan_filtering', _('Enable VLAN filterering')); | |||
There was a problem hiding this comment.
filtering not filterering
|
Having issues with bridges > 8 ports in the UI. The MX65 I am porting has 12 ports. Have to click save, click dismiss, then refresh to see the unsaved changes. Other times need to refresh to see previously saved settings. The save & dismiss buttons don't allow clicking when a horizontal scroll bar is present. When not previously configured, should there be a default VLAN 1 entry with PVID egress untagged for each interface as is default? Should the "Bridge VLAN filtering" tab be removed where the bridge is defined under
|
Ref: #4307 (comment) Fixes: faad746 ("luci-mod-network: add support for network.device sections") Signed-off-by: Jo-Philipp Wich <jo@mein.io> (cherry picked from commit edf640a)
This PR adds initial support for managing
config devicesections which allows for fine grained control over low level device details in uci. It requires the latest netifd Git HEAD to function.Additionally, it implements support for bridge VLAN filtering as defined in http://lists.openwrt.org/pipermail/openwrt-devel/2020-July/030151.html