Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#1147 - VLAN problem with MT7530 switch #6293

Closed
openwrt-bot opened this issue Nov 5, 2017 · 13 comments
Closed

FS#1147 - VLAN problem with MT7530 switch #6293

openwrt-bot opened this issue Nov 5, 2017 · 13 comments
Labels

Comments

@openwrt-bot
Copy link

realwillyt:

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.

@openwrt-bot
Copy link
Author

@openwrt-bot
Copy link
Author

Mushoz:

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

@openwrt-bot
Copy link
Author

Mushoz:

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.

@openwrt-bot
Copy link
Author

Mushoz:

In the following file: https://github.com/lede-project/source/blob/master/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mt7530.c

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?

@openwrt-bot
Copy link
Author

Mushoz:

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

MT7530_NUM_VLANS

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.

@openwrt-bot
Copy link
Author

jow-:

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.

@openwrt-bot
Copy link
Author

Mushoz:

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?: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=fd6bf05548eee0fe8d147dcfe9a92fc4856d9bc7

@openwrt-bot
Copy link
Author

rrt:

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

@openwrt-bot
Copy link
Author

jow-:

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 https://git.openwrt.org/?p=openwrt/staging/jow.git;a=commitdiff;h=0ecf301acb3bc78423056b868d22f8b755b74e31

@openwrt-bot
Copy link
Author

rrt:

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 https://wiki.openwrt.org/toh/ubiquiti/ubiquiti_edgerouter_x_er-x_ka table lists MT7621.

@openwrt-bot
Copy link
Author

Mushoz:

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! :)

@openwrt-bot
Copy link
Author

jow-:

Fixed with the following commits:

@chandr1000
Copy link

Hello, I came here just to reporting that Xiaomi 4A Gigabit router (MT7530 switch) has also encountered the same issues on DSA (latest openwrt version 21.02 and 22.03)

It can't connect to WAN on vlan 3xx with PPPoE discovery timeout

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants