VLAN configuration >= v2022.1.4

[4ndr3]

When upgrading Hamburg's firmware from gluon-v2021.1.2 to gluon-v2022.1.4, the point to point radio links (Richtfunknetz) fell apart because it heavily utilizes VLANs and apparently the VLAN configuration hast changed.

I was trying to rebuilt the VLANs according to https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration#create-a-mesh-vlan-on-one-port . However, I believe, it misses a step to assign the VLAN to a certain switch port. E.g. if I wanted that VLAN 8 from the example only on switch port 2. How would I go about that?
thx!

[blocktrron]

@4ndr3 The configuration for the switch ports only work in case your device supports DSA, in which case each switchport is exposed as a single interface to the Linux bridge utilities.

In case your device platform uses swconfig for means of configuring switching, the custom assignment of VLANs is not supported.

[dariks]

Hi,
We are also experiencing issues with VLANs on Gluon v2023.2.1.
The nodes are running in the Freifunk Nordhessen e.V. network.
Our point to point links worked fine before (Gluon v2022.1.1) but after upgrading the connecting node, the management of these point to point links wasn't available anymore.

The setup is as follows:
Ubiquiti EdgeRouter X on Gluon v2023.2.1 (DSA)
eth0: WAN, eth1-4: Mesh-on-LAN (VXLAN disabled site-wide!), eth4.5: Client-IP (VLAN 5 for managing the point to point links inside the Freifunk network)

The Firmware is available here: https://firmware-archiv.freifunk-nordhessen.de/1.4.0/images/
The site config that was used to build this firmware can be found here (in the Nordhessen directory!): https://gitlab.com/freifunk-nordhessen/ffnh-site/-/tree/65c191ed04db1bef1414e4979ba231f47b5b58e6

The issue we are seeing is that the communication is not working properly. You can't ping any IP addresses (IPv4 and IPv6), DHCP isn't working, pcap shows ARP-Requests and IPv6-RA's.
By configuring a VLAN on a notebook you can look at this exact issue (screenshot attached).

This can be reproduced with following commands:

# ensure LAN ports are on mesh-on-lan
uci del_list gluon.iface_lan.role='client'
uci add_list gluon.iface_lan.role='mesh'
# configure VLAN5 on eth4
uci set gluon.VLAN5ClientIP=interface
uci set gluon.VLAN5ClientIP.name='eth4.5'
uci add_list gluon.VLAN5ClientIP.role='client'
uci commit gluon
gluon-reconfigure

We are able to reproduce this issue on multiple EdgeRouter X's, i haven't found time to test more DSA targets, but we are mostly using the ERX anyway..
Interestingly, configuring Client-IP network on the physical interface itself (e.g. eth3 or eth4) does indeed work as expected, only the VLAN configuration is flawed.
This configuration was working with Gluon v2022.1.1/v2022.1.3.
We downgraded the affected node and restored it's config from backup, when this issue arrised, but here it is:
https://map.freifunk-nordhessen.de/#!/de/map/18e8295c1ff8

Thanks in advance! :)
Greets
Daniel

[blocktrron]

@dariks please post e dump of the network configuration of the node after invoking gluon-reconfigure. You can do this by entering the setup-mode of the device.

[dariks]

Thanks for looking at this.
here is the /etc/config/network file from config-mode after gluon-reconfigure in normal mode:

config globals 'globals'
	option ula_prefix 'auto'

config interface 'loopback'
	option netmask '255.0.0.0'
	option ifname 'lo'
	option ipaddr '127.0.0.1'
	option proto 'static'

config interface 'wan'
	option igmp_snooping '1'
	option proto 'dhcp'
	option auto '1'
	option peerdns '0'
	option multicast_querier '0'
	option type 'bridge'
	list ifname 'eth0'
	option macaddr '92:c6:cc:60:43:b0'

config interface 'wan6'
	option proto 'dhcpv6'
	option ip6table '1'
	option sourcefilter '0'
	option peerdns '0'
	option reqprefix 'no'
	option ifname 'br-wan'

config rule6 'wan6_lookup'
	option mark '0x01/0x01'
	option lookup '1'

config route6 'wan6_unreachable'
	option type 'unreachable'
	option table '1'
	option target '::/0'
	option metric '65535'
	option gateway '::'
	option interface 'loopback'

config device
	option name 'eth1'
	option isolate '1'

config device
	option name 'eth2'
	option isolate '1'

config device
	option name 'eth3'
	option isolate '1'

config device
	option name 'eth4'
	option isolate '1'

config interface 'mesh_other'
	option igmp_snooping '0'
	list ifname 'eth1'
	list ifname 'eth2'
	list ifname 'eth3'
	list ifname 'eth4'
	option index '4'
	option vxlan '0'
	option proto 'gluon_wired'
	option type 'bridge'
	option macaddr '92:c6:cc:60:43:b4'

config interface 'client'
	option igmp_snooping '1'
	option type 'bridge'
	option auto '1'
	option ra_holdoff '30'
	option multicast_querier '1'
	option ipv6 '1'
	option macaddr '74:83:c2:f9:08:52'
	option proto 'dhcpv6'
	list ifname 'eth3'
	list ifname 'eth4.5'
	list ifname 'local-port'
	list ifname 'bat0'
	option keep_ra_dnslifetime '1'
	option sourcefilter '0'
	option peerdns '1'
	option robustness '9'
	option reqprefix 'no'
	option query_interval '2000'
	option query_response_interval '500'

config device 'local_node_dev'
	option type 'veth'
	option name 'local-node'
	option peer_name 'local-port'
	option macaddr 'c2:d2:c8:a4:b2:a4'
	option peer_macaddr '74:83:c2:f9:08:52'

config interface 'local_node'
	option ifname 'local-node'
	option ipaddr '10.8.0.1/16'
	option ip6addr '2a03:2260:3013:800::1/128'
	option ip6deprecated '1'
	option proto 'static'

config interface 'gluon_bat0'
	option gw_mode 'client'
	option proto 'gluon_bat0'

config interface 'bat0'
	option multicast_router '2'
	option ifname 'bat0'
	option auto '1'
	option macaddr '74:83:c2:f9:08:52'
	option learning '1'
	option proto 'none'

config route6 'local_node_route6'
	option target '2a03:2260:3013:800::/64'
	option gateway '::'
	option interface 'client'

config interface 'mesh_vpn'
	option ifname 'mesh-vpn'
	option transitive '1'
	option mtu '1364'
	option macaddr '92:c6:cc:60:43:b7'
	option fixed_mtu '1'
	option proto 'gluon_mesh'

[blocktrron]

can you try removing eth4 altogether from the mesh-bridge so only the tagges client network is on the port?

Also i do not understand why eth3 is in the client bridge. Can you share your gluon configuration in addition?

[dariks]

Removing eth4 from mesh_other did the trick for the VLAN, it is working now. But as the configuration suggests, we do not have an mesh-on-lan port anymore. I have verified this with an pcap.

eth3 is in the client bridge because i have tested running the Client-IP network to it without VLAN. Weirdly it is still member of the mesh_other bridge.

Here is the /etc/config/gluon config file:

config core 'core'
	option domain 'ff_nh_lkks'

config interface 'iface_wan'
	option name '/wan'
	list role 'uplink'

config interface 'iface_lan'
	option name '/lan'
	list role 'mesh'

config wireless 'wireless'
	option outdoor '0'
	option preserve_channels '0'

config mesh_vpn 'mesh_vpn'
	option enabled '1'
	option limit_ingress '6000'
	option limit_enabled '0'
	option limit_egress '800'

config interface 'iface_client_eth3'
	option name 'eth3'
	list role 'client'

config interface 'VLAN5ClientIP'
	option name 'eth4.5'
	list role 'client'

[blocktrron]

@dariks please remove the role from iface_lan and try if this allows you to access the client net on eth3 untagged and on eth4 vlan5 tagged. I assume thats why they are added to both bridges.

[dariks]

now the situation is as follows:
eth0: WAN
eth1: no link
eth2: no link
eth3: Client-IP
eth4: nothing untagged
eth4.5: Client-IP

should i now configure the interfaces one by one to mesh? (eth1, eth2, eth4)

[blocktrron]

Yes, don't use the builtin /lan designator in this case. Maybe we should reconsider to ensure interface assignments are XOR.

Also note (while the symptoms are comparable), your circumstances are different from the one @4ndr3 is facing.

[dariks]

@blocktrron
Okay, i tried that by doing:

# set eth1 to mesh
uci set gluon.iface_mesh_eth1=interface
uci set gluon.iface_mesh_eth1.name='eth1'
uci add_list gluon.iface_mesh_eth1.role='mesh'

# set eth2 to mesh
uci set gluon.iface_mesh_eth2=interface
uci set gluon.iface_mesh_eth2.name='eth2'
uci add_list gluon.iface_mesh_eth2.role='mesh'

# set eth4 to mesh
uci set gluon.iface_mesh_eth4=interface
uci set gluon.iface_mesh_eth4.name='eth4'
uci add_list gluon.iface_mesh_eth4.role='mesh'

but now i am facing the exact same issue again: broken connectivity.
should we move into a new issue? there wasn't enough context for me to recognize if this issue is relating to us or not.

/etc/config/network

config globals 'globals'
	option ula_prefix 'auto'

config interface 'loopback'
	option netmask '255.0.0.0'
	option ifname 'lo'
	option ipaddr '127.0.0.1'
	option proto 'static'

config interface 'wan'
	option igmp_snooping '1'
	option proto 'dhcp'
	option auto '1'
	option peerdns '0'
	option multicast_querier '0'
	option type 'bridge'
	list ifname 'eth0'
	option macaddr '92:c6:cc:60:43:b0'

config interface 'wan6'
	option proto 'dhcpv6'
	option ip6table '1'
	option sourcefilter '0'
	option peerdns '0'
	option reqprefix 'no'
	option ifname 'br-wan'

config rule6 'wan6_lookup'
	option mark '0x01/0x01'
	option lookup '1'

config route6 'wan6_unreachable'
	option type 'unreachable'
	option table '1'
	option target '::/0'
	option metric '65535'
	option gateway '::'
	option interface 'loopback'

config device
	option name 'eth1'
	option isolate '1'

config device
	option name 'eth2'
	option isolate '1'

config device
	option name 'eth4'
	option isolate '1'

config interface 'mesh_other'
	option igmp_snooping '0'
	list ifname 'eth1'
	list ifname 'eth2'
	list ifname 'eth4'
	option index '4'
	option vxlan '0'
	option proto 'gluon_wired'
	option type 'bridge'
	option macaddr '92:c6:cc:60:43:b4'

config interface 'client'
	option igmp_snooping '1'
	option type 'bridge'
	option auto '1'
	option ra_holdoff '30'
	option multicast_querier '1'
	option ipv6 '1'
	option macaddr '74:83:c2:f9:08:52'
	option proto 'dhcpv6'
	list ifname 'eth3'
	list ifname 'eth4.5'
	list ifname 'local-port'
	list ifname 'bat0'
	option keep_ra_dnslifetime '1'
	option sourcefilter '0'
	option peerdns '1'
	option robustness '9'
	option reqprefix 'no'
	option query_interval '2000'
	option query_response_interval '500'

config device 'local_node_dev'
	option type 'veth'
	option name 'local-node'
	option peer_name 'local-port'
	option macaddr 'c2:d2:c8:a4:b2:a4'
	option peer_macaddr '74:83:c2:f9:08:52'

config interface 'local_node'
	option ifname 'local-node'
	option ipaddr '10.8.0.1/16'
	option ip6addr '2a03:2260:3013:800::1/128'
	option ip6deprecated '1'
	option proto 'static'

config interface 'gluon_bat0'
	option gw_mode 'client'
	option proto 'gluon_bat0'

config interface 'bat0'
	option multicast_router '2'
	option ifname 'bat0'
	option auto '1'
	option macaddr '74:83:c2:f9:08:52'
	option learning '1'
	option proto 'none'

config route6 'local_node_route6'
	option target '2a03:2260:3013:800::/64'
	option gateway '::'
	option interface 'client'

config interface 'mesh_vpn'
	option ifname 'mesh-vpn'
	option transitive '1'
	option mtu '1364'
	option macaddr '92:c6:cc:60:43:b7'
	option fixed_mtu '1'
	option proto 'gluon_mesh'

/etc/config/gluon

config core 'core'
	option domain 'ff_nh_lkks'

config interface 'iface_wan'
	option name '/wan'
	list role 'uplink'

config interface 'iface_lan'
	option name '/lan'

config wireless 'wireless'
	option outdoor '0'
	option preserve_channels '0'

config mesh_vpn 'mesh_vpn'
	option enabled '1'
	option limit_ingress '6000'
	option limit_enabled '0'
	option limit_egress '800'

config interface 'iface_client_eth3'
	option name 'eth3'
	list role 'client'

config interface 'VLAN5ClientIP'
	option name 'eth4.5'
	list role 'client'

config interface 'iface_mesh_eth1'
	option name 'eth1'
	list role 'mesh'

config interface 'iface_mesh_eth2'
	option name 'eth2'
	list role 'mesh'

config interface 'iface_mesh_eth4'
	option name 'eth4'
	list role 'mesh'

[Djfe]

how does /etc/config/network look after running gluon-reconfigure after those changes?
Do you still experience this issue? have you retried it on Gluon v2023.2.4?

[AiyionPrime]

@dariks In case you're still interested in resolving your issue, I'd like to take you up on your offer and have you open a new issue. That way we don't bother the OP further.

Please link this Issue, if you decide to answer @Djfe's question.

As the original question has been answered and @4ndr3 did not come back for more, I'd close this for now.