OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Kernel
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by realwillyt - 05.11.2017
Last edited by Jo-Philipp Wich - 14.02.2018

FS#1147 - VLAN problem with MT7530 switch

Device problem occurs on: Xiaomi Mi Router 3G (and I assume anything with a MT7530 switch like the DIR-860L)
Steps to reproduce: When configuring the switch the only way to sync a vlan ID to a port is to have it exactly match the order it occurs in in the config.

I.E If you set up a vlan with ID 3 it has to be the 3rd one in the list in luci.

This means if you were working with VLAN ID in the thousands you’d have to set up thousand of dummy VLAN entries in your config.

Apologies if this has already been reported, there are several posts on the forum, but I didn’t see an actual bug report.


Closed by  Jo-Philipp Wich
14.02.2018 15:48
Reason for closing:  Fixed
Jaap Buurman commented on 30.01.2018 12:11

I can confirm this issue with Lede 17.01.4. Has there been any news on this issue?

Jaap Buurman commented on 30.01.2018 14:21

I managed to track down the issue. When creating a new VLAN with a VLAN ID of for example 720, (L)UCI will write the following to the network config file:

 config switch_vlan                                  
      option device 'switch0'         
      option vlan '7'             
      option ports '6t'                           
      option vid '720'

If manually edited and changed to:

 config switch_vlan                                  
      option device 'switch0'         
      option vlan '720'             
      option ports '6t'                           
      option vid '720'

and then reloading the network settings via /etc/init.d/network reload, it will give you a working VLAN with ID 720 without having to use dummy VLANs.

I am not sure whether this is a (L)UCI issue and the vlan value should have been set to 720 instead, or whether this is an issue with the interpretation, where for some reason devices using the MT7530 switch are loading the vlan value where they should be using the vid value. My guess would be an interpretation issue, since other devices are not affected.

Could anyone using a different device please let me know what is being set to the network config file when creating a new VLAN with ID 720, tagged on the CPU and off on all ports? That might be helpful for figuring out whether this is a (L)UCI issue or MT7530 related. Thanks.

Jaap Buurman commented on 30.01.2018 15:08

In the following file:

There is this function called

 static int mt7530_reset_switch(struct switch_dev *dev)

Which contains the following interesting comment:

 /* set default vid of each vlan to the same number of vlan, so the vid
  * won't need be set explicitly.

Is this function perhaps bugged? It is using the index i for setting the vids instead of the actual vid values:

 for (i = 0; i < MT7530_NUM_VLANS; i++) {
 		priv->vlan_entries[i].vid = i;

Anyone with a better understanding of the code that could have a look?

Jaap Buurman commented on 31.01.2018 10:13

That above function seems to be fine after having another thought.


is a constant, so this function will always do the exact same thing, regardless of the values set in the config file. Back to the drawing board. Still, my previous observation that changing the "vlan" value in the config is a workaround should give us a hint where to look I think.

Jo-Philipp Wich commented on 01.02.2018 19:29

Do you observe the problem on master or on lede-17.01 ? The stable release lacks a number of changes required to properly handle vlan tags on mt7621.

Jaap Buurman commented on 02.02.2018 22:10

I am running 17.01.4 so that might explain why I am still running into this issue then. I will try out the master branch as soon as possible, but that may have to wait until I am home alone, in which case I won't be bothering anyone else with my network experiments ;)

Do you happen to know which particular commits addressed the properly handling of vlan tags on mt7621? Would like to have a look at the code changes in the mean time. Thanks!

Edit: Would it be this commit you are talking about?:;a=commit;h=fd6bf05548eee0fe8d147dcfe9a92fc4856d9bc7

Routing Route commented on 10.02.2018 16:55

Maybe see if it is due to wrong swconfig syntax like  FS#1341  - vlan configuration fails, trying the workaround.

Jo-Philipp Wich commented on 11.02.2018 19:44

After reviewing the driver some more I came up with a possible explaination of the behaviour and some likely solution. Please test my commit at;a=commitdiff;h=0ecf301acb3bc78423056b868d22f8b755b74e31

Routing Route commented on 12.02.2018 08:31

Is there a module with th patch in the daily build that I can copy to test on the UBNT ERX?

# swconfig list
Found: swtich0 - mt7530

But the table lists MT7621.

Jaap Buurman commented on 13.02.2018 13:22

Thank you very much for your effort. Unfortunately, the issue remains. My home network is using VLANs 1, 2, 4 and 6. My old configuration had a dummy VLAN at 3 and 5 to fix the issue.

I just compiled and flashed from your staging tree, however, when adding VLAN 8 this new VLAN is nonfunctional. Changing it to VLAN 7 (the next in line) instantly fixes this. Changing it back to VLAN 8 breaks it again. And so on, so forth.

If you have any other ideas, I would be more than willing to help in testing. Thanks again! :)

Jo-Philipp Wich commented on 14.02.2018 15:47

Fixed with the following commits:


Available keyboard shortcuts


Task Details

Task Editing