when i connect to port 1,3,4 i get DHCP and works fine but port 2 DHCP doesnt work and fails to connect any suggestion why this is happening?
my end goal have 5 vlans each with its respective port and the 5th one will trucked on port4
root@OpenWrt:~# cat /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 'fde0:b00f:141a::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1.1'
config interface 'lan'
option device 'eth1.1'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config interface 'wan'
option device 'eth0.2'
option proto 'dhcp'
config interface 'wan6'
option device 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0t 2 4 5'
option vid '1'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '1 6t'
option vid '2'
config device
option name 'eth1.29'
option type '8021q'
option ifname 'eth1'
option vid '29'
option multicast '1'
config device
option name 'eth1.30'
option type '8021q'
option ifname 'eth1'
option vid '30'
config device
option type '8021q'
option ifname 'eth1'
option vid '33'
option name 'eth1.33'
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '0t 3'
option vid '3'
config interface 'lan3'
option proto 'static'
option device 'eth1.3'
option ipaddr '10.36.33.1'
option netmask '255.255.255.0'
I did that and it worked. Thank you. i did try the same before but for some reason it didn't work then. between now and then i have restarted and updated the packages not sure if that was a reason too.
reasoning for me to do this: i want to two vlans which will have two different network.
now when i look at the network file i see the interface has an option as bridge but expection was it would not have a bridge since i directly connected it to switch vlan like the wan was configured:
can you explain why the option type 'bridge' is set? Chatgpt tells me
In OpenWrt, when you define an interface with a VLAN device (ethX.Y), it automatically creates a bridge interface for that VLAN. This bridge is necessary to connect multiple physical or virtual interfaces together at Layer 2 (the data link layer) of the OSI model.
but if thats true then why in the Devices screenshot there is no bridge device?
@fOO223Fr - would you be able to clarify a bit about your process? Specifically...
The last line (option type 'bridge') doesn't belong here (as has been established and I think fixed already), but it sounds like it ended up there after you used LuCI to adjust the configuration, but without any direct modification of the config file (i.e. you didn't mention using a text editor or UCI commands). Can you confirm that this is the case? If so...
Because that syntax has been deprecated and is no longer valid, I'm really interested to know exactly what is causing that line to appear. I'd like to try to find the culprit. If you have some time to replicate the process you used earlier via LuCI (documenting every step along the way), we can look again to see if the line re-appears. If so, I'll try to replicate on one of my devices, and then maybe narrow down what is causing this.
If, OTOH, you did actually make the change directly (text editor/CLI), please let us know (and don't be ashamed).... just trying to make sure we don't have an obscure bug somewhere.
i tried to replicate the process but couldn't i will keep an eye on it and if it appears again in interface again i will come back with the reproducible steps
It appears that from a device on the iot network you ping/traceroute the router itself, not devices on other VLANs. This is normal behavior because the default policy for the input chain of the iot zone is set to ACCEPT and thus it allows access to all router interfaces.
Is the device connected to port 4 configured to accept tagged frames with VLAN ID 33?
Option start defines the first address in the DHCP pool. 0 is the network IP address, so it is not a valid value. The first IP address in the pool will be 1 and it overlap with the router's IP address set for the psn interface.
This causes problems in the latest releases and should be avoided.
Does the device connected to port 4 need to be configured to accept tagged frames? because interfaces are different (psn and iot) anyone connecting to iot which is through wifi and anyone connecting with wire on port4 is part of psn
the expectation is when any packet arrives at port4 via wire then it gets tagged 33 and when any packet arrives at port4 via wireless then it gets tagged 34
@fOO223Fr - I want to tell you that you are vindicated! I wrote up my findings about how this line is seemingly randomly appearing in config files when it shouldn't.
If you connect to psn or iot wirelessly, you will get an IP on the respective network.
This does not apply to wired devices. Currently port 4 only works with tagged frames - vid 33 (psn) and vid 34 (iot). The connected device must be configured to work with tagged frames and it will receive an IP depending on the tag set (33 or 34).
Usually, this approach is not used with end devices, but when the traffic of several VLANs needs to be carried over a single cable.
If you want the device connected to port 4 to get an IP on the psn network, just set the port to untagged for vid 33.
Thank you again. Yes yesterday night this is what i ended up doing with help of a local friend who is good with networking. We also concluded that the DSA architecture (used it in my broken wrt1900ac) is much easy to understand than "Switch" tab. Not sure where to track any progress on that topic for this device.
Things are good now except i realized the archer c7 v2 is too old to do pppoe with NAT and maxes out at 200Mbit/s:
haha i see that. wonderful piece and congratulations on being able to reproduce a bug which you didn't even face to begin with! You must have some super power to read into problems and being able to reproduce..
Thanks. As you can guess, I've seen the results of that bug enough times as to be baffled about how so many people had that deprecated/invalid line in their configs! I had a few ideas about what could cause it, so just a few minutes into my testing and I found the 'problematic' sequence.
