[FS#3224] A VLAN goes out when a new VLAN is added
OpenWrt Bugs
openwrt-bugs at lists.openwrt.org
Sat Jul 11 10:12:56 EDT 2020
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Glenn C. Lasher Jr. (kc2idf)
Attached to Project - OpenWrt/LEDE Project
Summary - A VLAN goes out when a new VLAN is added
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - openwrt-19.07
Due in Version - Undecided
Due Date - Undecided
Details - Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce
Hostname OpenWrt
Model Linksys WRT1900ACS
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363
Kernel Version 4.14.180
At the outset, there are two VLANs pre-existing: 1 (LAN) and 2 (WAN)
In LuCi, create the following VLANs: 10, 20, 21, 2200, 2204, 2208, 3000.
At that point, I created a new VLAN on the Network/Switch page in LuCi. The new VLAN had an initial default VID of 10, which I changed to 11. I set the tagging to my need (Tagged on CPU and LAN port 3, off on all other ports) without touching the other nine VLANs.
As soon as I hit Save & apply, VLAN 10 stopped working entirely.
Examining the configuration files, I find these two stanzas:
config switch_vlan
option device 'switch0'
option vlan '3'
option ports '5t 1t'
option vid '10'
. . .
config switch_vlan
option device 'switch0'
option vlan '10'
option ports '5t 1t'
option vid '11'
This leads me to the hypothesis that the "vlan" option of 10 is colliding with the "vid" option of 10 on another VLAN, though it seems like these should be separate, unrelated concepts.
My workaround was to redo my VLAN scheme so that former VLANs 10, 11, 20 and 21 are now 1000, 1100, 2000 and 2100 respectively, which was enough to prevent this collision, and it all works, but it seems like it should not have had the collision in the first place.
More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3224
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
More information about the openwrt-bugs
mailing list