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
Comments
realwillyt: The two forum threads related to this issue: https://forum.lede-project.org/t/mt7621-dir-860l-does-not-support-vlans/1714 https://forum.lede-project.org/t/problem-with-vlan-tagging-on-dir-860l-mt7530/1261/12 |
Mushoz: I can confirm this issue with Lede 17.01.4. Has there been any news on this issue? |
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 If manually edited and changed to: config switch_vlan 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. |
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 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++) { Anyone with a better understanding of the code that could have a look? |
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. |
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. |
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 |
rrt: Maybe see if it is due to wrong swconfig syntax like FS#1341 - vlan configuration fails, trying the workaround. |
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 |
rrt: Is there a module with th patch in the daily build that I can copy to test on the UBNT ERX? swconfig listFound: swtich0 - mt7530 But the https://wiki.openwrt.org/toh/ubiquiti/ubiquiti_edgerouter_x_er-x_ka table lists MT7621. |
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! :) |
jow-: Fixed with the following commits:
|
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 |
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.
The text was updated successfully, but these errors were encountered: