kernel-panic69 DD-WRT Guru
Joined: 08 May 2018 Posts: 14249 Location: Texas, USA
|
Posted: Wed Sep 04, 2019 15:07 Post subject: |
|
What errors? Is it a K2.6 build? If so, the shell errors were not fixed until 40708 or so. The problem ultimately rests in the generic code used, I think. If this is an N device, single band or dual band, the existence of vlan0 is trivial, but ultimately is not a good thing. This is an issue 'that is not an issue', but it is. This is why a lot of code needs to be revised to be specific to specific lists of devices IMHO. But you are talking a LOT of TEDIOUS work. |
|
speakxj7 DD-WRT Novice
Joined: 09 May 2013 Posts: 25
|
Posted: Wed Sep 25, 2019 1:14 Post subject: Re: fixed |
|
piers7 wrote: | speakxj7 wrote: |
Code: | root@DD-WRT:~# nvram set lan_ifnames="vlan1 eth1"
root@DD-WRT:~# nvram set vlan0ports="0 1 2 3 8*"
root@DD-WRT:~# nvram set vlan1ports="3 2 1 0 8*"
root@DD-WRT:~# nvram set vlan2ports="4 8"
root@DD-WRT:~# nvram commit
root@DD-WRT:~# reboot |
tested on 29739
first change fixes lan interfaces (switch is live), last 3 changes fix port assignments and cpu/default vlans (wan port and routing).
|
gti wrote: |
I want to know if the newest firmware like this 33772 would still need those script to be run .... as I don't have time or want to do any debugging after I flash it if something goes wrong.
|
My painful trial-and-error testing has lead me to understand that as of 33772 you don't need to do any of this - that the 'factory reset' configuration will work as-is, provided you wait and perform a second reboot after the box has booted up after flash-and-reset. It comes up with lan_ifnames=vlan1,eth1,eth2 (which is not exactly what speakxj7 had above) but seems to work.
I also realize that connecting via the WiFi is (counter intuitively) the 'safe' option after flashing/reset, having let https://wiki.dd-wrt.com/wiki/index.php/Switched_Ports sink in a bit. That could have saved me much frustration starting out.
I would love, however, for someone to explain patiently to me what is going on with the vlan1ports config line being the same as vlan0ports, but with the non-CPU ports backwards.
Also why - given that both 'vlan2ports=4 8' and 'wan_ifname=vlan2' tell me the WAN is on VLAN2, does the VLANs tab in the web GUI show the 'W' port as VLAN 1? What *is* that VLANs tab attempting to show me anyway?
(edit: corrected a mistake from previous version of this post which was just wrong, and schooled me about actually doing the second reboot) |
golly it's been a while. interesting to hear it's been cleaned up in more recent fw's, but i haven't had cause to go through a clean setup on default nv. device is still chugging for me a as a wap, but it's been demoted from gateway duty for a while.
going back to the what's and why's of my previous advice, the logic there was that there was some conflation of vlan0 and vlan1 due to some off by one (base zero/base one) issues, this also extended into the wan setup which is why it's inconsistent between vlan1 and 2 depending on the where. the individual port order on 0 & 1 shouldn't matter as long as you make them otherwise match (or at least, i can't remember why), i didn't have much success back then with removing the waste one entirely, with the other inconsistencies mentioned. if you do go down the command line path, don't bother with the UI (unless it's all been sorted out now). i assume this is basically because of how the nvram stuff was mapped out to named values vs internally consumed.
iirc, i did a bunch of testing to 'figure' this out (at least for the builds of the time), including one-by-one tweaks (and then checking the nvram), and dirty flashes from stock (and then checking nvram)
for reference, while i'm not worrying about wan stuff anymore (for the reason i mentioned above), i'm still running a k3 setup on it, currently r39654. |
|