[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