Has VLAN support been fixed in the final 17.01 release? I am looking to buy a DIR-860l myself.
Which older build has VLAN support?
Bump. (10 char)
Bump. (10 char)
Just to test, try to set the Switch configuration to this:
Important: The untagged parts should stay, where they are at the moment in your configuration. The only changes are VLAN 7 tagged at CPU and WAN.
I had problems with gaps at the VLANs e.g. at a 1, 2, 4 configuration only 1 and 2 worked. At 1, 2, 3, 4 configuration every VLAN worked fine.
I used LEDE 17.01 Build
Just an uneducated guess: They used the index of the for loop instead of the array element they wanted to address to configure the VLAN Switch.
Thank you so much, Aufhaxer! This did it for me! All VLAN IDs had to be tagged on CPU port and i have working PPPoE Connection in VLAN7 on WAN Port!
Glad to hear.
With the current snapshot and the master i built myself it seems to be working as expected and without the need of the useless VLANs.
I would like you to test the current snapshot and delete the unused VLANs, to confirm my results:
You have to install luci manually through ssh with "opkg update && opkg install luci".
I'm sorry to tell you that with the current snapshot, deleting all VLANs from 3 to 6 still brings me back to the old problem:
Sat Mar 18 20:51:30 2017 daemon.warn pppd: Timeout waiting for PADO packets
Sat Mar 18 20:51:30 2017 daemon.err pppd: Unable to complete PPPoE Discovery
Sat Mar 18 20:51:30 2017 daemon.info pppd: Exit.
I'll stick with your workaround for now. Let me know if you need more logs or if you want me to test some more for you, i'll be happy to do so. Thanks so far anyway!
thank you for your results. This input is very helpful.
I have to withdraw my results from last post. The issue like in your case still seems to be broken in the latest snapshot of LEDE. But still glad to hear, that the workaround does his job.
We are currently discussing this issue in two separate threads. Since the problem of yours has been fixed for the moment, I would like you to participate, if possible, in the other thread to limit it to only one. Mt7621 DIR-860L does not support VLAN's
Having to deal with a couple of different ISPs, working with different protocols and different VLAN IDs, i just found out, that the current stable LEDE Release 17.01.4 has some fixes for a part of the issue. Using VLAN 7 (Germany's Telekom ISP via VDSL), there is no problem having VLAN IDs 1, 2, 7 present, using PPPoE.
Dealing with a PPPoE FTTB Connection from a different ISP (Germany M-Net) which requires to use VLAN 40, it is only possible to get a connection when again inserting VLANs 3-39 in between.
The issue seems to be persistent for higher numbered tags.
Having different LEDE routers at hand, a direct comparison with the same build for different platforms does not show this issue on other devices which use different Hardware.
Could we try and upvote the issue on the bug tracker? Hopefully a fix will be found sooner then
Managed to pinpoint the issue. Not sure yet where a fix should be applied. Please view the bug tracker for more details.
I noticed that we have a similar discussion going on in Mt7621 DIR-860L does not support VLAN's
Can we safely close the linked topic, in order to follow up with this issue in only one thread?
I am fine with that. Would it maybe be possible to merge the topics instead though?
I could move the other thread over to this one, but this would result in all messages being appended to this thread, breaking the chronological order. I don't think that this would be a good idea.
I can close the other thread and attach a note that discussion of this topic will go on in this thread here.
Sounds good to me, thank you.
I only have limited experience with compiling my own firmware, so just to make sure this is the proper way to do it:
- I simply clone the master branch of your staging tree and then compile as usual?
- Or: I apply this commit to the regular Lede master branch (how?) and then compile that?
Either way should work; to just apply the patch; use a command like:
wget -O - "https://git.openwrt.org/?p=openwrt/staging/jow.git;a=patch;h=0ecf301acb3bc78423056b868d22f8b755b74e31" | git am
To later revert this patch, use
git reset --hard origin/master to reset your cloned master branch to its vanilla upstream state.
After applying the branch you can build as usual. Please only flash the resulting image if you're familiar with the recovery procedures and/or if you have TTL serial access.
Perfect. The girlfriend will be back in an hour, so not enough time to go playing around with our internet now But I will test the patch and report back tomorrow Thank you very much for your effort trying to fix this issue!