Can you reset NVRAM on CFE recovery and see if it still works?
After resetting NVRAM over CFE recovery it still does work fine (w/o VLAN).
I did reset OpenWrt too and created a wireless network with the same SSID for 2.4 and 5GHz with WPA2-PSK set for both. My mobile connects to the 5GHz and I disable 5GHz and it connects to the 2.4GHz. I enable 5GHz again and the mobile changes back to 5GHz.
1 Like
"None of my devices will connect to both Wi-Fi bands with WPA2-PSK. I get wrong password even though it's correct."
This is exactly the behavior that I also experienced.
Can confirm, same VLAN setup as @scatman75 and wireless lan security set to anything else than 'open network' won't work, authentication error.
Question: How did you configure it with SWCONFIG? In my setup - the standard way I assume - the wireless interfaces were part of the bridge but not VLAN tagged. But now they are part of the VLAN setup:
root@OpenWrt:~# bridge vlan
port vlan-id
lan4 2 PVID Egress Untagged
lan3 1 PVID Egress Untagged
lan2 1 PVID Egress Untagged
lan1 1 PVID Egress Untagged
2
wlan0 2 PVID Egress Untagged
wlan1 2 PVID Egress Untagged
br-lan 1
2
wlan0-1 1 PVID Egress Untagged
wlan1-1 1 PVID Egress Untagged
I googled "VLAN and wifi" and came across Can 802.1Q VLAN packets be passed through Wi-Fi transparently?. It's a very old question and maybe not true anymore but there it was stated that wireless and VLANs don't go together.
Using swconfig, we didn't use bridge VLAN filtering feature of the Linux kernel. Swconfig would already create VLAN configured interfaces which we'd just bridge it with a wireless interface, as I explained on this wiki page:
Back with swconfig, we couldn't directly assign wireless interfaces to VLANs. So we had to bridge wireless with an already VLAN configured ethX.X interface.
Now that I read this quote again, there's inaccurate information. It's not DSA or leaving swconfig that gave us the ability of using the bridge VLAN filtering function. It was rather introduced to OpenWrt (the ability of creating interfaces) around 2021. VLAN filter support on bridge has been in Linux kernel for years.
I understand that this person wanted to send tagged frames over the air. This is not what we're doing anyway so this is unrelated.
This could be a bug on either the bridge VLAN filter feature or the wireless driver. I'll dig around.
I did it differently with swconfig, see part of /etc/config/network. Here VLAN3 was my guest network.
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 7t'
option description 'VLAN1'
config switch_vlan
option device 'switch0'
option ports '3t 7t'
option vlan '2'
option description 'VLAN2'
config switch_vlan
option device 'switch0'
option ports '3t 7t'
option vlan '3'
option description 'VLAN3'
config switch_vlan
option device 'switch0'
option ports '4 7t'
option vlan '10'
option description 'WAN'
config interface 'VLAN3'
option proto 'static'
option ipaddr '192.168.150.2'
option netmask '255.255.255.0'
option gateway '192.168.150.1'
option broadcast '192.168.150.255'
list dns '192.168.150.1'
option device 'br-VLAN3'
config device
option name 'br-VLAN3'
option type 'bridge'
list ports 'eth1.3'
2 Likes
swconfig have its own implementation of VLAN filtering which were used for the switch ports. DSA doesn't. DSA only sets up switch ports as interfaces. For VLAN filtering, we now use the bridge VLAN filtering feature of the Linux kernel. We can avoid using the "bridge VLAN filtering" feature on wireless interfaces with this workaround:
Create another bridge. Add the subinterface (that uses the VLAN we want to include wireless interfaces in) of the main bridge (with all the switchport interfaces in it). Then add the wireless interfaces to this newly created bridge. This way, we avoid using the "bridge VLAN filtering" feature on wireless interfaces.
@scatman75 @patient0 The workaround I explained above works fine.
Screenshots:
br1 bridge has got br0.1 & two wireless interfaces
With this, I basically included two wireless interfaces on VLAN 1, without using Bridge VLAN filtering feature, therefore avoiding the issue.
@arinc9
Thank you very much again. You saved my day 
I created new bridges br1 with br-lan.1 and br3 with br-lan.3. The uplink port 1 in br-lan.1(vlan1) is set as untagged with pvid 1 and in br-lan.3(vlan 3) it is set as tagged. The other ports don't matter here, as the router is only uses as an AP.
The interface lan is associated with br1 and the interface guest is with br3. The wireless wlan0 is bind to the interface lan and wireless wlan0-1 is bind to the interface guest.
For further info please find the content of /etc/config/network below:
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2:u*'
config bridge-vlan
option device 'br-lan'
option vlan '3'
list ports 'lan1:t'
list ports 'lan3:u*'
config device
option type 'bridge'
option name 'br1'
list ports 'br-lan.1'
config device
option type 'bridge'
option name 'br3'
list ports 'br-lan.3'
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.2.111'
option gateway '192.168.2.1'
option broadcast '192.168.2.255'
list dns '192.168.2.1'
option device 'br1'
config interface 'guest'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.150.2'
option gateway '192.168.150.1'
option broadcast '192.168.150.255'
list dns '192.168.150.1'
option device 'br3'
Hopefully this workaround won't last forever as it can be a real pain in the ass at the beginning.
@patient0 @scatman75 I got the DSA driver for RTL8365MB working!!! It's on this branch. I will finalise everything and upload a prebuilt image later.
Enable Use the testing kernel version under Global build settings on menuconfig to use the 5.15-rc3 kernel.
Morning @arinc9 that is great news!
I got it to compile but didn't succeed when enabling the Wireguard Luci app (maybe at latest-OpenWrt problem, I haven't checked yet).
My dmesg output for the successfully compiling basic configuration:
root@OpenWrt:~# dmesg | fgrep realtek
[ 2.819950] realtek-smi ethernet-switch: deasserted RESET
[ 2.826214] realtek-smi ethernet-switch: found an RTL8365MB-VC switch (ver=0x0040)
[ 2.833848] realtek-smi ethernet-switch: unable to register switch ret = -517
[ 3.209949] realtek-smi ethernet-switch: deasserted RESET
[ 3.216204] realtek-smi ethernet-switch: found an RTL8365MB-VC switch (ver=0x0040)
[ 3.347690] realtek-smi ethernet-switch: failed to get parent irq: -22
[ 3.354311] realtek-smi ethernet-switch: no interrupt support
[ 3.387860] realtek-smi ethernet-switch lan5 (uninitialized): PHY [SMI-0:00] driver [RTL8365MB-VC Gigabit Ethernet] (irq=POLL)
[ 3.402564] realtek-smi ethernet-switch lan6 (uninitialized): PHY [SMI-0:01] driver [RTL8365MB-VC Gigabit Ethernet] (irq=POLL)
[ 3.417159] realtek-smi ethernet-switch lan7 (uninitialized): PHY [SMI-0:02] driver [RTL8365MB-VC Gigabit Ethernet] (irq=POLL)
[ 3.431821] realtek-smi ethernet-switch lan8 (uninitialized): PHY [SMI-0:03] driver [RTL8365MB-VC Gigabit Ethernet] (irq=POLL)
[ 3.448857] realtek-smi ethernet-switch: configuring for fixed/rgmii-id link mode
[ 3.461204] realtek-smi ethernet-switch: Link is Up - 1Gbps/Full - flow control rx/tx
[ 22.329078] realtek-smi ethernet-switch lan5: configuring for phy/ link mode
[ 22.375114] realtek-smi ethernet-switch lan6: configuring for phy/ link mode
[ 22.415944] realtek-smi ethernet-switch lan7: configuring for phy/ link mode
[ 22.462640] realtek-smi ethernet-switch lan8: configuring for phy/ link mode
[ 84.843815] realtek-smi ethernet-switch lan6: Link is Up - 1Gbps/Full - flow control rx/tx
Thanks a lot!
1 Like
The structure of the source code for certain programs were changed on the newer Linux kernels. The packages on OpenWrt (under the package/ or feeds/ directory) would have to be updated to compile properly. I wanted to do the least of work to just have the kernel and the DSA driver running on the bcm53xx target. So, a number of packages are broken, WireGuard in this case.
I'm going to try the DSA driver on 5.10 again. If it won't work, we'll have to wait until OpenWrt officially switches to the next longterm supported kernel (probably going to be 5.15) so they properly support everything to work with the newer kernel. Then, we backport the driver on this kernel instead.
@patient0 Here's some more good news. The driver works on 5.10.
Here's how we're going to finish this. We wait for OpenWrt people to move on to DSA on bcm53xx target. Then, I'm going to mail a patch which adds support for Asus RT-AC88U.
After this, we wait for the rtl8365mb DSA driver to be included in the net-next. Then I'm going to submit a patch to Linux devicetree people to specify the realtek switch on the device tree of Asus RT-AC88U.
After that's done and that patch is backported to OpenWrt, I'm going to send the second patch backporting the DSA driver to 5.10 and enable the driver on bcm53xx target.
Nice! Is this running 5.10 (my prebuilt image) or 5.15?
Running your prebuild image.
OK, looks like the realtek driver has problems with VLAN filtering on 5.10. Can you set egress untagged & pvid for lan 5 on VLAN 1 and plug a computer on lan5? See if you can reach LuCI.
P.S. If you really need VLAN filtering support on all switch ports, I put a prebuilt image with 5.15-rc3 kernel on the same Github release, you can use that instead.
I tested the setting, but no success, please see below
Result: No link, no connection to LuCI.
In comparison I tested port 4 (Broadcom). Everything worked fine.
At present I do not need VLAN filtering on all ports, as I use the router only as a WLAN AP. But thank you very much for your offer.
1 Like
@ arinc9
One problem I've had - since updating to your latest image (kernel 5.10) - is that the guest WiFi no longer works. The clients cannot establish a connection. After the connection attempt, the connection is terminated because the client does not receive a valid IP address.
Rolling back to version 21.02 immediately fixed the problem while keeping the same configuration.
Can you send me your backup config? Let me try to replicate it.