Lan, br-lan and eth0 across different devices

I am trying to understand the relationship between the interfaces lan, eth0 and br-lan. I have three different Ubiquity antennas with a single LAN port and they behave differently when provisioned with the same config.
As I understand it, br-lan is the bridge device that bridges all ports configured as lan (not wan) together. As I only have devices that use a single LAN-Port that bridge only contains one entry.
Now I see different behaviors across the antennas. Some devices list eth0 as the device in br-lan and some list lan.
That is where my confusion starts.

I have an antenna, that has a 'lan' section in /etc/config/network and shows a lan interface as lan@eth0. I have an antenna, that has a 'lan' section in /etc/config/network and does not show any kind of active 'lan' interface.
And I have an antenna that shows an active 'lan' interface, without even having such a section in the config.

I am trying to manage these antennas with OpenWISP, in which I can write templates and apply those to antennas. A common usecase is wanting to provide multiple Wifi-SSIDs that are bridged to different VLANs. For each of these SSIDs I bridge the wireless interface and a VLAN interface (e.g. br-lan.1234 or lan.1234). The thing is, on some antennas br-lan.1234 works and on some lan.1234 works.

The models I use are 6 Light, NanoHD and 6 LR.

The 6 Light works when using br-lan as the interface where the VLAN is configured to.
The NanoHD only accepts eth0 as VLAN interface, as it does not have an active lan interface (although it is present in /etc/config/network).

Why is the handling of the lan interface different across devices?

lan is the interface to the device eth0? br-lan is the bridge over all lan interfaces?

Let's start with a more or less typical configuration snippet:

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr ''
        option netmask ''
        option ip6assign '60'

When we look at the lan interface, we see that it has an address and a device associated with it. The interface (lan) is the connection with the CPU and sets the key parameters for how the system should interact with the interface (routing, local services, etc.).

The lan network interface uses a device called br-lan - this is a bridge. A bridge is the software equivalant of an unmanaged switch. It is required anytime you want to connect multiple physical interfaces with a (logical) network interface. This would include situations like ethernet + wifi, multiple wifi radios, or multiple ethernet ports. If you are only going to use a single physical network interface (let's say only 2.4G radio or only a single ethernet port), you don't actually need a bridge. There is a little nuance with the "multiple ethernet ports" I mentioned in that it depends on if the system is using swconfig or DSA under the hood. In many situations with swconfig, you could have multiple physical ethernet ports that were addressed via a single virtual ethernet port (i.e. the connection between the CPU and the internal switch chip).

Finally, when we look at the device br-lan we see eth0 in the list. The eth0 here is the physical ethernet port that is included in the bridge, or it could be the ethernet connection between the CPU and the switch chip. If we had eth0.2 (as an example), this would still be treated as the physical ethernet port, but it would a VLAN with 802.1q tagging for VID 2. (again, swconfig, when applicable, means that this might not be tagged on the actual physical ports, depending on the swconfig parfameters). In the case of most single-ethernet-port devices, the eth0.2 would directly translate to a tagged condition.

Does this help?


Thank you for the explanation, that helps a lot.
So depending on whether the single port device uses swconfig or dsa, the config looks different?

Is this the reason why tagging the VLAN on the eth0 interface does not seem to work on some devices but tagging on the br-lan bridge-interface does work?

Where do I find an overview of which devices/platforms are already using DSA?

I assume then that there is no easy way to share the same /etc/config/network between different devices that use swconfig and dsa.

DSA and swconfig are very different. However, both of these only matter when you're dealing with a device that has a built-in switch. When it comes to single ethernet port devices, probably the majority of them do not (although some do -- for example, the TL-WR902ACv1 does not, but the v3 does, IIRC).

On a device without a built-in switch, you'll use standard dotted notation (ethX.y).

Side note: I believe that you can also use bridge-VLAN syntax (which is integral to DSA) on a non-switch device, but I have not personally tried it, so I can't say if this is true or not.

Possibly. I'd have to see the config and have the context of which device we're talking about.

There isn't really a good single source for this. My recommendation is to look at the release notes from 21.02.0 and 22.03.0 for the list of targets that have transitioned from swconfig to DSA in each release. This is target based, so you have to dig a bit deeper to know what devices have actually migrated.

No. In fact, even on the same exact device when it goes through the transition to DSA, a complete reset-to-defaults is required and you must configure from scratch. The backups in this case should only be used as a human reference to know how things were previously configured, but the syntax in the new DSA vs old swconfig config files are entirely different.

That said, even when you're not talking about a swconfig vs DSA difference, it is usually not advised to use the same /etc/config/network file between two devices, even if the hardware is identical -- sometimes there are hardware specific bits (i.e. MAC addresses) that must not be on multiple devices at the same time. Further, if the hardware is not identical, the mappings of the ethernet ports is typically not consistent, and therefore you may end up with problems. You can, obviously, use the same conceptual syntax frameworks, but don't just blindly copy the files (or portions of the files) over without considering these factors.

After looking at my setup again, I can't seem to reproduce the problem anymore.
All my antennas support DSA from what I can gather and using the bridge interface for wifi connectivity seems to work just fine.

I also now seem to have a working openwisp setup for configuring the antennas.
Thank you very much for your detailed explanations. They helped me understand openwrt much better!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.