Did you happen to run the tests? I'm curious for the results If VLANs are non-functional on the final 17.01 release, would you mind testing the latest master branch as well if time permits? Thanks again :)!
Did you happen to have time for your tests?
Bring up my post.
Sorry for the delay. I was really busy the past few days. So I tested the DIR-860L with the latest firmware and sadly it doesn't seem like it is working. Sorry for the sad news
That's a pity to hear. I'll try to see if I can find some time to do a proper bug report on their bug tracker. Hopefully this issue can be fixed. Thank you very much for the test
Update: There is a workaround posted here: Problem with VLAN tagging on DIR-860L (MT7530)
Furthermore, the issue seems to be fixed in the master branch. I will order the dir-860l and see if I can get it to work
It would be nice if somebody could validate my results posted in the other thread.
I already have my dir-860l, but my internet that is using VLANs will be available the 24th. Is there any test I can do with 2 PCs and a router to test VLAN functionality?
You could create a new Network with a different VLAN with a VLAN ID far away from your current VLANs (100+) with DHCP and everything and test if it is properly working on one of your PCs.
- Create a new VLAN with VLAN ID 100
- Tag it at CPU and assign a unused Port with "untagged" to it -> Save&Apply
- Create a new interface at the Interfaces Tab, assign a name to it and assign the new Switch VLAN: eth0.100 to it. -> Save&Apply
- Click on "Setup DHCP" at the bottom of the page.
- Choose a IPv4 address like 10.1.2.1 and netmask 255.255.255.0 -> Save&Apply
Now you should have a new Network with DHCP at this port. If you plug in a PC at this port and get an IP, it should work.
After that you can delete the Interface you created and set your VLAN Switch settings to default.
Thanks for the setup description. I will be able to test this tomorrow evening. I will keep you posted.
Let me know as well
I can confirm the workaround from the other thread. By default, WAN is on VLAN 2, while LAN is on VLAN 1.
I added a third entry in the VLAN list, tagged it at CPU, untagged it at LAN port 2 (and set the same port to off under VLAN 1). Next, I configured a new interface on the 192.168.2.1 subnet and enabled a DHCP server.
Then I ran into the first bug. It seems like the labeling on the back of the router and in the switch interface is reversed. So port 1 on the back, was port 4 in LEDE, port 2 on the back was port 3 in LEDE, etc. So naturally, connecting my PC on port 2 did not result in the VLAN being used. Connecting it to port 3, however, successfully resulted in my PC getting an IP in the 192.168.2.X range.
Next, I renamed the VLAN id from 3 to 4 with the exact same settings otherwise. Then reconfigured the newly created interface to use VLAN 4 and.... Nothing. The VLAN was not working. I was not getting an IP adres.
So to test the workaround, I added a new VLAN entry. I used the 3rd entry to configure a dummy VLAN 3 (tagged at CPU, off everywhere else) and used the fourth entry to configure VLAN4 as I did in the previous test. This resulted in a successful connection and an IP in the earlier mentioned 192.168.2.x range again.
I also tried the master branch to see if I could get it to work there without a workaround (VLAN 4 as a third entry, without a dummy VLAN), but I was unsuccessful. However, I could not use LUCI because I do not have a working WAN connection to install it, so I could not use LUCI to double check my settings and I am not that good with UCI. However, I think the settings should have been good, since I configured it on 17.01.0 in LUCI, and then flashed the latest snapshot while keeping the settings.
Summary: Port numbers on the back of the router are in reversed order compared to the port numbers in the LEDE switch GUI. VLAN IDs needs to be identical to their entry position for them to work (starting at an index of 1).
If you want to test master with LuCI you can flash my test build, since it has it built in
Thank you very much for the link I just tested, and unfortunately it shows the same behavior as on 17.01.0: it requires the workaround for VLAN functionality to work. I will look into getting this bug reported. Hopefully it is an easy fix.
That's unfortunate. I thought it was fixed in the snapshot and master. I try to test the setup again the next days. Until then you can roll with the workaround. Glad that at least this works.
Ok. I just tested the same setup you described before and i can confirm your results. The VLAN functionality seems still broken in the latest snapshot.
I don't know why it worked in the meantime, but after resetting everything to basic and creating some VLANs the bug occured again.
Hopefully one of the more experienced maintainers can give further advice to debug this issue.
P.S: If possible could you test the workaround and the testsetups as well, yathavan101? Although in your case it would be more suitable to use a TL-WR841N as Middleware between the 860L and your ISP, since you have to tag the VLAN621, which could result in quite excessive work with the workaround.
I'd like to give some further feedback. In the other thread where the same problem is discussed, I wrote that with current trunk, vlan isn't working in case I need VLAN7. This was the case for doing the sysupgrade keeping the settings and deleting VLAN 3-6. it actually did work when I started from scratch, adding only VLAN7.
Adding in that I can confirm this issue is still present in LEDE stable 17.01.2 r3435-65eec8bd5f.
The workaround provided in Problem with VLAN tagging on DIR-860L (MT7530) DOES work around the error, however it's needed to keep all intermediate VLANs assigned to get to the desired. Removing any inbetween resurfaces the problem.
Looks like it's more or less just failing to assign the VLANs if they are not incrementing in order 1-2-3 etc.
I'm entirely uncertain then if this issue is limited to the MT7621 and/or the DIR-860L. In my test playground it doesn't really matter the assignments, but obviously for production this would be a larger issue.
Not a problem if your internet connection is trunked in the VLAN7, for example, but if you have it in the VLAN835, then it is.
Still no advance?.