Everything except VLANs seems to work in OpenWrt 22.03.0-rc4. I will revert back to 21.02.2.
I finally have some spare time to mess around. I'd like to reproduce your issue. Can you send your config and screenshots from the interfaces, firewall and the bridge VLAN filtering page?
Sure, no problem at all. Network IoT is not used at present, so just ignore it. DHCP services for clients of the different networks come from external Server (OPNsense), which operates as gateway and DNS server.
/etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd3f:f501:9a6f::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
option igmp_snooping '1'
config bridge-vlan
option device 'br-lan'
option vlan '1'
list ports 'lan1:u*'
list ports 'lan2'
config brigde-vlan
option device 'br-lan'
option vlan '2'
list ports 'lan1:t'
list ports 'lan4'
config bridge-vlan
option device 'br-lan'
option vlan '3'
list ports 'lan1:t'
list ports 'lan3'
config device
option type 'bridge'
option name 'br1'
list ports 'br-lan.1'
option igmp_snooping '1'
config device
option type 'bridge'
option name 'br2'
list ports 'br-lan.2'
option igmp_snooping '1'
config device
option type 'bridge'
option name 'br3'
list ports 'br-lan.3'
option igmp_snooping '1'
config interface 'lan'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.5.111'
option gateway '192.168.5.1'
option broadcast '192.168.5.255'
list dns '192.168.5.1'
option device 'br1'
option metric '50'
config interface 'iot'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.180.2'
option gateway '192.168.180.1'
option broadcast '192.168.180.255'
list dns '192.168.180.1'
option device 'br2'
option metric '100'
config interface 'guest'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.190.2'
option gateway '192.168.190.1'
option broadcast '192.168.190.255'
list dns '192.168.190.1'
option device 'br3'
option metric '150'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
config device
option type '8021q'
option ifname 'br-lan'
option vid '2'
option name 'br-lan.2'
config device
option name 'br-lan.1'
option type '8021q'
option ifname 'br-lan'
option vid '1'
config device
option name 'br-lan.3'
option type '8021q'
option ifname 'br-lan'
option vid '3'
Hmm, ok. If I remember correctly, there were some problems with adding the WiFi interfaces to a bridge with VLAN filtering enabled. So this is why you have created new bridges, br1 and br3, with VLAN filtering off, correct? Other than that, this setup is pretty simple, remind me what does not work on versions newer than 21.02?
Yes, you are right, br1 and br3 were created due to Wifi issues with vlans. And yes apart from that the router is only a plain access point. With kernel versions >5.4 I had no luck. As you advised me I filed that issue as a bug. But till today it is still open, yet it was flagged with "kernel".
I'm currently replicating your network setup, why do lan and guest networks both have the gateway specified? You're supposed to put only one default route to a router and that is if you want the router to route all IP(v4) addresses through the host (router) that has got the specified IP address on that network.
Same goes for DNS. Though not a necessity, you should specify a single DNS server. Don't specify a different DNS server on each network. The router sends queries to that DNS server for traffic only from the router itself since the router only works as an AP, meaning it only switches frames between hosts.
What I'm going to say next might differ by your use case, instead of changing the DNS server on the router, you can configure it on dnsmasq running on the router so you have dnsmasq locally caching queries as well. Just put the desired DNS server on the "DNS forwarding" section under "Network -> DHCP and DNS" on LuCI.
And please send Nevermind, if this device acts as an AP you must not have configured DHCP at all./etc/config/dhcp.
First of all, thank you very much for your ongoing efforts on my problem and your valuable advice. I agree with you that my approach is not very common, even a bit strange. The main goals were to keep the configuration of the APs as simple as possible and to make the clients of the VLAN feel like they were in a simple network structure.
I did this mainly because of the IoT VLAN configured on the other APs, because those devices always collect whatever data they can get there. Firewalling helps a bit, but in the end you have to let them communicate or you won't be comfortable. If a replacement is economically feasible, I will definitely go with a cloud-free solution.
Of course, I could transfer a bit of intelligence to the Asus router. However, I don't see the big advantage, since the Asus router is connected to the OPNsense server via cable without VPNs or other narrow-band connections in between.
Cheers. Putting multiple default routes makes no sense in any sort of networking structure. Netifd (the network interface daemon OpenWrt uses) is going to bring the interfaces up, one by one, by retrieving information from /etc/config/network. Only the default route on the last interface brought up will stick. So, the ones before won't even have an impact on the router. You can confirm this by running ip route.
Although this likely has nothing to do with the problem at hand, it still is a huge discrepancy that you should address. Because this may cause all sorts of issues on different OpenWrt versions (21.02 vs 22.03). You can just keep the one for the OPNsense server (192.168.5.1) as I suppose is the upstream router in your case. This way, the Asus router will have internet access.
I have no idea what you're pointing at on the second and third paragraphs.
I'm going to set up the guest network (192.168.190.0/24) and try to connect to it via Wi-Fi and see if I get DHCP to give me an IP address.
My PC will be connected to lan1, the interface on the PC will be eth0.1 (VLAN ID 1 tagged interface) and will set 192.168.190.1/24 on it. DHCP will listen on that interface. That should completely replicate your guest network.
One more thing you can do to simplify your networking setup is to set the protocol on the guest network on the Asus router to unmanaged, you don't need the router to have an IP address on the guest network as all it does is switch frames between the WLAN and DSA interfaces. And you already have an IP address on LAN to reach the router.
This is how my AP (TP-Link, WiFi bridge issue is nonexistent) with guest network works. There's a WLAN interface on br0 set to VLAN 50 untagged, but LuCI doesn't show that on the page.
I have used another OpenWrt router to be the host with DHCP.
Asus router configuration:
Test2 is the guest network.
Wi-Fi workaround is still necessarry.
VLAN 3 tagged on wan port.
Wireless interface for the arinc9 VLAN3 SSID is added to the bridge of the guest network.
Asus router required a reboot for the Wi-Fi to work properly, phone wouldn't connect to the network at all.
After that, Wi-Fi works fine.
Can you replicate my config, see if it works as well?
I have tried this on the wan port. Please try it on wan port if lan1 won't work.
Well...to keep short short, guest wlan is working with 22.03.0 rc4. Unfortunately I do not exactly know what why.
After your motivating lecture on the gateways, I thought about some settings. Even though only one gateway was used due to the metric, the use on the Asus was nonsense. Therefore I changed the setup of the Asus a little bit:
- There is now only one default gateway on the Asus
- I deleted the unnecessary WAN interface
- Assigned the WAN interface to the LAN bridge
Right after the configuration no wlan device could hold a stable connection to the guest wlan. But after a reboot it magically worked.
BTW: The uplink port 1 remained unchanged.
That's good to hear, so I understand there're no issues with 22.03 anymore? It really doesn't matter, in my eyes, why previous config worked on older versions; may be bad configuration, something else, who cares. Does it work on the latest image? Yes! That's that.
We should get the issue you created closed if everything works fine.
1 Like
Everything seems stable, great help for feature updates. I really enjoyed your patience and meticulousness with my problem. Thank you very much.
1 Like
I'm glad we finally solved the issue, cheers!
Have you ever configured Wi-Fi without the workaround but tested it after reboot? I wonder if it would start working after reboot as well.
I tried it on 22.03.0-rc5, the issue is still there even after reboot. I will report this bug.
Just a short question: Any chance that the router will support mesh in the future?
Currently the driver seems to prevent it:
iw list
Supported interface modes:
* IBSS
* managed
* AP
* P2P-client
* P2P-GO
* P2P-device
The router got bcm4366c0 chip for wireless which uses the brcmfmac driver. I don’t believe there would be support for what there isn’t right now, since Broadcom is regularly bashed for keeping their wireless drivers’ source code proprietary.
1 Like
So be it. Anyway it's a huge win to have the router supported! Thank you for your time and endurance for making it happen.
3 Likes
Congratulations on getting the device officially supported. Thanks for your work.
1 Like
@arinc9 Thanks for you continues work on this! I updated from a self compiled, a few months old image to RC6 and it works like a charm. You're amazing, thanks!
What I did see is that the RealTek switch is only accessible by the extsw interface. Wasn't at some point this switch also accessible using the individual ports? Since I only use ports 1 to 3 and wan it doesn't matter but I was just curious. I remember VLAN not working on it.
1 Like