Off topic: if people would just skip Luci and using uci directly it would be simple as I don't know but dead simple in my opinion.
Ps. I speak of editing the uci config files and not uci scripts for sure.
That’s what you claim, but with uci things are hw independent, e.g.
uci get network.wan.device
uci set …
Directly messing with the config files is not recommended.
Unless I need to do something that requires the CLI; for my part I do everything on Luci.
The OP has an issue they refuse to describe and they found a solution they refuse to share. 
That is the easiest, least complicated method that can be done directly via luci.
Documentation about this should be updated to show this via Luci:
(https://openwrt.org/docs/guide-user/network/wifi/wifiextenders/bridgedap#optionaladd_wan_port_to_the_lan_bridge)
1 Like
A bit presumptuous, don’t you think? I’m validating and going back through old configs to make sure I have the RC.
I also didn’t ask for specific help. I asked for docs others had used + confirmed as accurate and that I could work from.
In fact this observation is pretty good:
1 Like
Try this. It’s more current.
Ty. Not stuff I came across during my digging but I will dig in and compare to other sources.
_berndUsing WAN/LAN port did not work consistently – worse than not working at all – for reasons I don’t yet understand. Using pure WAN port is where I settled. On previous incarnations of the config the opposite was true. So now you understand why I didn’t ask for specific help but a vetted document which might shed light on the inconsistency.
But, like I said, I never asked for help. I asked for a vetted doc.
Whenever you're ready to explain the undesired and undocumented behavior, I'm sure we'll be curious to understand.
(Seems that referencing the actual configuration in a forum of users with practical exprience would be faster than trying to extrapolate your problem from a review of "vetted docs".)
Also, not sure of others expounded - the information regarding changes you understood from the video depends on device make/model and version of OpenWrt in use (switching was migrated at different times for different targets).
1 Like
@mk24 - So For MT6000 to use the WAN port as trunk, should eth1 port or wan be added to the lan-bridge when using vlans?
I've read some places a bridge crossing 2 switches is not recommended so what to do since the GL.Inet GL-MT6000 has 2 internal switches? (keep in mind I'm newish to OpenWRT DSA setup so just trying to understand the right way to do this)
Switch
A MediaTek 1Gbit switch and two Realtek 2.5Gbit chips are used. Network traffic for LAN1-5 passes through a single port to the CPU at eth0. The WAN port is directly connected to the CPU at eth1.
+----------------+
| MT7986AV CPU |
| eth0 eth1 |
+----------------+
| |
6 |
+----------------------------+ +--------+
| MT7531AE | |RTL8221B|
| switch & 5x GBit PHY | +--------+
+----------------------------+ |
0 1 2 3 5 |
| | | | | |
| | | | +--------+ |
| | | | |RTL8221B| |
| | | | +--------+ |
| | | | | |
lan2 lan3 lan4 lan5 lan1 eth1
I'm using eth1 but here is my abbreviated network config for just one of the VLANs on my downstream dumbAP
config device #orignal WAN acting as upstream trunk
option name 'eth1'
config device #lan bridge
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
list ports 'lan5'
config bridge-vlan #VLAN=1
option device 'br-lan'
option vlan '1'
list ports 'eth1:t'
list ports 'lan1:u*'
list ports 'lan2:u*'
list ports 'lan3:u*'
list ports 'lan4:u*'
list ports 'lan5:u*'
config bridge-vlan #VLAN=20
option device 'br-lan'
option vlan '20'
list ports 'eth1:t'
#etc...
#etc...
config interface 'lan'
option device 'br-lan.1'
option proto 'none'
config interface 'mgmt'
option device 'br-lan.1'
option proto 'static'
list ipaddr '192.168.1.3/24'
option gateway '192.168.1.1'
list dns '192.168.1.1'
#etc...
Your mgmt is completely wrong. The same VLAN can only be attached to one Interface. If you're going to switch mgmt through Ethernet you need to make an additional bridge-vlan for it with a dedicated number (not 1 or 20). Remove the gateway and dns lines, it works that way by default.
Since lan is proto none (unmanaged) it cannot participate in any IP based networking, and will purely switch through the switch at layer 2. It is also possible to bridge a wifi AP into lan, it will be a "dumb" AP where all IP based operations are handled in another router.
Other than that, it should work. You didn't post the wan section of /etc/config/network but there the Device needs to be br-lan.20
I don't have wan device configured on this aux router. I thought eth1 was the way to do it when using as ”just another port” for the trunk
That's why I'm confused about how to reference that physical port in setup
Yes, mgmt is not right, It's a temporary setup. I've been playing with numerous configs to work things out. You can ignore mgmt - I just threw that on so I could get an ip for the box to acces via SSH.
If it is only trunking Ethernet packets through, you need at least two ports in the bridge-vlan 20. Otherwise packets enter on the eth1 port and have nowhere to go.
A diagram or a clear description of your whole proposed network would help me.
Also when setting up an Ethernet-only VLAN (i.e. for this VLAN, the OpenWrt router acts only as a managed switch) you still need to have a stub Interface for it:
config interface 'vlan20'
option proto none
option device 'br-lan.20'
This is necessary for the system to set up the VLAN in the switch.
I have a similar configuration as yours with eth1 (wan) inside br-lan and no wan interface, but I believe I untaged eth1 for pvid.
By no means I'm a expert, so I'm curious too as this topic goes if this stanza is correct and safe, I choosen untagged because I don't want it to exist further upstream the pvid always comes from upstream 
, which there is 169.
What I did was removing the last port from br-lan to reserve this for mgmt then it is away from the virtual switch in br-lan, that is how I think it seem to work.
I defined lan5 in br-mgmt and made its own local interface of it.
For the native/management vlan (no this is not the mgmt interface, but to access from upstream wan) I use static lan from subnet from the upstream with dhcp ignored and since it has default gateway checked it automaticly should be threaten as default route/wan for me, but I guess you can also use proto unmanaged and use the static ip reservation on the upstream router, honestly L2 is for the native switch management not so important for me but maybe that is a mistake but I had no issue so far, all other trunked vlans are unmanaged in where it was more importanter to hold pure L2 for multicast etc.
OK, pasting lots of config files here makes these threads unreadable.
Here's a github repo with my desired design and initial configs on the DumbAP
I haven't uploaded the MainRouter setup just yet, I'll get to that later.
Plan:
- Guest can't touch anything (unless it goes through main router as if it was web traffic.
- IOT can only get internet access (with restrictions TBD)
- Private is internal lan
Ideally this could be a basic template for most, as I think this is a pretty common setup