Posted: Sun Oct 21, 2018 18:20 Post subject: Authentication failure on later builds for VAPs
Hey,
I am wondering if more people are facing this issue or if it is more specific to my specific unit. I found a related https://svn.dd-wrt.com/ticket/6404 issue on the issue tracker and put my reply there.
For convenience I will repeat it here:
-----------------------------------------------------------------
In short: Using latest Kong [R37015M] or BrainSlayer? [R37442] builds I cannot authenticate to VAP (guest network) on my R7000 on both 2.4 and 5ghz wifi. Even when entering a wrong password, i don't get the message 'invalid credentials' (or similar), my android (8.1) device keeps on trying, but it never succeeeds. Regular wifi [non-vap] works fine.
Steps to reproduce:
- Upload latest kong [test build] or brainslayer build [see versions above] using web interface
- Reboot
- Setup username/pwd, enable ssh
- Login using ssh and issue 'erase nvram && reboot'
- Setup username/pwd again
- Change router ip/subnet to 10.1.1.1/255.255.255.0 [not sure if strictly necessary to reproduce but since my router is used by rest of household this will keep people happy ]
- In wireless->basic add two virtual interfaces, one for 2.4ghz network, the other for 5ghz. all settings can be left as default. SSID for these new VAPs is dd-wrt_vap
- In wireless->security, configure both wl0.1 and wl1.1 with WPA2/PSK and the same password
- Now go to Networking tab and add a bridge [br1], assign it ip/subnet combo: 10.1.2.1/255.255.255.0
- Click apply settings, we can now assign wl0.1 and wl1.1 to this bridge (i set STP off on both bridge and teh assignment)
- Click apply settings again. Now we add dhcp to br1 using 10.1.2.40-10.1.2.100 range
Now verify:
- You can connect with regular network [dd-wrt] without problem.
- You CANNOT connect with guest network [keeps retrying]. Enabling syslogd and klogd does NOT show any output when the devices keeps on retrying to connect. Even if you configure your client to use a wrong password you are not notified on the client about this, it keeps on retrying.
Now: DOWNGRADE firmware to latest STABLE Kong build (36070M), without resetting the config. After the router rebooted: verify you CAN connect to both regular network (dd-wrt) AND (dd-wrt_vap) WITHOUT any problem.
By searching the forum I see mentioned:
> VAPs not working at boot (k3.10?); workaround startup command: sleep 10;stopservice nas;stopservice wlconf;startservice wlconf;startservice nas
In my case this does unfortunately NOT solve the issue
I posted just a few days ago with exactly the same problem.
That workaround doesn't work for me either, but someone else posted a response to me saying that clicking on "Apply Settings" in the Services tab seems to work. I think it's been working for me, but I haven't had a chance to verify it properly yet.
Joined: 24 Feb 2013 Posts: 1384 Location: Belgrade
Posted: Sun Oct 21, 2018 20:54 Post subject:
Instead of:
Code:
erase nvram && reboot
do:
Code:
nvram erase
After unit reboots, wait a few minutes... then add VAP (C class of IPs), unbrigde it, add dhcp... reboot and try it again... then if it is working add complexity (VAPs password, A class of IP, etc )
I have been doing all permutations and combinations with VAP. It works fantastic ... till I reboot.
Have reported what the OP reports on all the build-threads that I tried and reported. Now, I check the build threads to see if this is resolved - and give a pass to the build if this is not addressed.
As a user, I can say that this was one of dd-wrt's most popular features. _________________ PROFESSIONAL STUDENT my.Mistakes ∝ my.Learning ... provided I have the patience & persistence to learn
Running BS r35244 with vap working. There may be a slightly newer release with vap working but I cannot be bother wasting my time. Simpler to setup an extra AP for guest if I want to run the latest release.
Joined: 24 Feb 2013 Posts: 1384 Location: Belgrade
Posted: Mon Oct 22, 2018 6:08 Post subject:
@m0eb@ wrote:
I have been doing all permutations and combinations with VAP. It works fantastic ... till I reboot.
Have reported what the OP reports on all the build-threads that I tried and reported. Now, I check the build threads to see if this is resolved - and give a pass to the build if this is not addressed.
As a user, I can say that this was one of dd-wrt's most popular features.
BS probably doesn't know about this, or it is not reproducible on his equipment. He would fix it same day... So, my advice is to get your unit into the "fail state" with enabled remote ssh and give him access... send him email...
BS probably doesn't know about this, or it is not reproducible on his equipment. He would fix it same day... So, my advice is to get your unit into the "fail state" with enabled remote ssh and give him access... send him email...
Joined: 24 Feb 2013 Posts: 1384 Location: Belgrade
Posted: Mon Oct 22, 2018 7:55 Post subject:
there are lots of units/kernel/architectures etc...
I know that it is reported, but sometimes it is not enough for finding "bug"...
For me, there are no issues with VAP... works very good on both bands 2,4 and 5... BS tested VAP issues too and fixed them...
I read that Kong wrote that VAPs work for him too...
Lots of users thinks that devs are ignoring them but it is not true... they work very hard every day doing coding for us. With no charge... So, your statement that it is reported doesn't help anyone... just showing that you are dissatisfied but with no reason...
Joined: 24 Feb 2013 Posts: 1384 Location: Belgrade
Posted: Mon Oct 22, 2018 11:20 Post subject:
It was some days ago, but not sure if he was talking about bridged VAPs to separate bridge (wl0.1+wl1.1)... this is not standard ddwrt feature аs amoeba said... not sure if it can work at all when these VAPs are on separated physical interfaces..
For those running ARM based Broadcom routers, if you don't mind, try the following and see if it solves your problem:
1. Download the attached wlconf.gz file and transfer to your router.
2. 'gunzip' the file with the following command:
Code:
gunzip wlconf.gz
chmod u+x wlconf
3. Issue the following commands in the same directory that you have uploaded the wlconf.gz file:
Code:
stopservice nas
stopservice wlconf
./wlconf eth1 up
./wlconf eth2 up
startservice nas
You can ignore all the errors shown when the 'wlconf <intf> up' commands is executed.
From the changes in the source codes for the 'wlconf' utility, it looks like the way that the MAC addresses are getting generated for the wireless interfaces have changed for newer drivers. I guess it only applies to newer Broadcom wireless chipsets, which broke older chipsets.
I changed the 'wlconf' utility behaviour back to what it was previously and it seems to work OK for the following routers which I'm using:
D-Link DIR-868L
D-Link DIR-880L
Asus RT-AC68U/W
Do report back if the above works for you. It can then be used to report back to BS & Kong for further investigation.
For those running ARM based Broadcom routers, if you don't mind, try the following and see if it solves your problem:
I will try that when I have time (sometime in next 24 hours).
Hope it wont create a blast that sends me to jail ... or takes me and my whole house to the moon. _________________ PROFESSIONAL STUDENT my.Mistakes ∝ my.Learning ... provided I have the patience & persistence to learn
Joined: 08 May 2018 Posts: 606 Location: Texas, USA
Posted: Mon Oct 22, 2018 14:29 Post subject:
It's a case of 'one size does not fit all (chipsets, architectures, etc.)'. If you're not compiling strictly from source, drivers, nas daemon, wlconf, then you're not going to have 100% across the board. And if you're not compiling the drivers for the specific hardware in question, it's going to be a crap shoot. I'm pretty sure I mentioned this in a build thread or somewhere on the forum or a ticket on the bug tracker. Most of my serial log spam is for un-fixed issues, etc. and (wi-fi) hardware / options that isn't in the device I'm running DD-WRT (Official) on. Not entirely sure that it's a newer driver problem on older hardware, either... BUT nothing would surprise me.
It's a case of 'one size does not fit all (chipsets, architectures, etc.)'. If you're not compiling strictly from source, drivers, nas daemon, wlconf, then you're not going to have 100% across the board. And if you're not compiling the drivers for the specific hardware in question, it's going to be a crap shoot. I'm pretty sure I mentioned this in a build thread or somewhere on the forum or a ticket on the bug tracker. Most of my serial log spam is for un-fixed issues, etc. and (wi-fi) hardware / options that isn't in the device I'm running DD-WRT (Official) on. Not entirely sure that it's a newer driver problem on older hardware, either... BUT nothing would surprise me.
Yes ... and we need to be patient as we remind of the need for this feature. It's not that BS or Kong or the other devs do not know there is an issue. I'm sure they are working on it and we will have a solution (like so many other problems of the past) _________________ PROFESSIONAL STUDENT my.Mistakes ∝ my.Learning ... provided I have the patience & persistence to learn
For those running ARM based Broadcom routers, if you don't mind, try the following and see if it solves your problem:
1. Download the attached wlconf.gz file and transfer to your router.
2. 'gunzip' the file with the following command:
Code:
gunzip wlconf.gz
chmod u+x wlconf
3. Issue the following commands in the same directory that you have uploaded the wlconf.gz file:
Code:
stopservice nas
stopservice wlconf
./wlconf eth1 up
./wlconf eth2 up
startservice nas
You can ignore all the errors shown when the 'wlconf <intf> up' commands is executed.
From the changes in the source codes for the 'wlconf' utility, it looks like the way that the MAC addresses are getting generated for the wireless interfaces have changed for newer drivers. I guess it only applies to newer Broadcom wireless chipsets, which broke older chipsets.
I changed the 'wlconf' utility behaviour back to what it was previously and it seems to work OK for the following routers which I'm using:
D-Link DIR-868L
D-Link DIR-880L
Asus RT-AC68U/W
Do report back if the above works for you. It can then be used to report back to BS & Kong for further investigation.
HTH.
edit
Tried upgrade from another computer and now at r37442 from BS r35244. vap is finally working after applying your solution on my DIR-880L A2 port based AP.
Thank you very much for your expert help.
Last edited by gjaltemba on Mon Oct 22, 2018 19:32; edited 1 time in total
]
