Wow, such an amazing response on this topic! Thanks all for replying!! Very much appreciated, it is good to see such an active and helpful community!
quarkysg wrote:
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.
WOOHOOOOOO DUDE(or chick!). This _WORKS_ (at least on Kong 37015M). Does this mean it's an error/oversight in the current code? Can we submit a patch to help Kong&BrainSlayer? Also, I do get a lot of errors when I execute your version, I hope that doesnt do harm
Thank you so much for fixing this so insanely fast!
Edit:
if it is of any value, here is the output of 'wlconf eth1 up'
Code:
total vif count 2
eth1: Not supported
base addr XX:XX:XX:XX:13
local bit addr XX:XX:XX:XX:13
eth1: Bad address
eth1: Invalid argument
eth1: Not supported
eth1: Not supported
eth1: Invalid argument
eth1: Invalid argument
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
eth1: Not supported
enable bss eth1 0 (1)
enable bss eth1 1 (1)
Posted: Tue Oct 23, 2018 1:03 Post subject: The code needs a debugging and quality clearance
quarkysg wrote:
For those running ARM based Broadcom routers, if you don't mind, try the following and see if it solves your problem:
.
.
.
.
Do report back if the above works for you. It can then be used to report back to BS & Kong for further investigation.
HTH.
My router is R6400v2 configured as:
2.4GHz + LAN connectors 1 and 2 configured under openDNS and separated out via br1.
5 GHz + LAN connectors 3 and 4 configured under openVPN using PBR
Running Kong's 37015
I set up wl0.1 and put this under br2 with DHCP giving different subnet range. As expected, this stopped on reboot and devices were not connecting.
Then put your code in directory /opt and used telnet to run the lines as you mentioned. As you mentioned - lots of errors to ignore ... and then all SSIDs started to work. So far so good.
TROUBLE STARTED when I rebooted the router.
* SSID: None were connecting
* Browser configuration ... unreachable
* Telnet ... not working
* winSCP ... says only FTP enabled and Telnet is not possible (just like it happens when we try on a new Netgear Router running OEM firmware)
Options for me at this stage: Enable Telnet forcefully OR Revert back to stock/earlier version. I used nmrp to get back to Kong's .chk file and return to normalcy
A new user would be shocked and lost !! To a newbie, this is almost like a bricked router. I wonder how many posts above have rebooted the router before jumping with joy.
My take on the code:
## Code is working but with major bugs ... it did set my VLAN working
## Should come with a stern warning that this can semi-brick some routers
## Lacks trust. No one knows what the compiled thing actually does. dd-wrt is an open forum where multiple programmers know what is being posted. It is secure and hence trustworthy. In order to become useful, the code needs to be debugged (does need a deep look ... with so many errors popping up and routers getting semi-bricked). Please share this with Kong/BS wnd work together so that it can be used to everyone's benefit. _________________ PROFESSIONAL STUDENT my.Mistakes ∝ my.Learning ... provided I have the patience & persistence to learn
Joined: 18 Mar 2014 Posts: 12881 Location: Netherlands
Posted: Tue Oct 23, 2018 8:38 Post subject:
Just hit the reset button should get you going.
But it is really strange this should not permanently change anything, so a simple reboot (unless you placed the script in startup) should get you back to normal operation.
Lesson learned do not place anything in startup you do not fully trust.
What you can do is use a startup command to start this as a script in /opt, so if you just remove the USB stick (where /opt resides) the script can not execute.
But it is really strange this should not permanently change anything, so a simple reboot (unless you placed the script in startup) should get you back to normal operation.
Thanks egc.
1. I do not know the background - just posted what I observed. Facts only. I did say this code worked.
2. As mentioned, I used telnet (not in startup)
3. Did not reset and went straight to nmrp because of the reason of trust. In any case - whether it worked or not, I would have erased everything and refreshed the router. (Now that you give the credentials, I know that I can keep the working code - which is the first one that at least set the VAP working). I believe Quarkysg will understand and appreciate my apprehension here. And I did load this on my router and try.
@Quarkysg: Apologies ... I was just stating what I saw. No offense meant. _________________ PROFESSIONAL STUDENT my.Mistakes ∝ my.Learning ... provided I have the patience & persistence to learn
@quarkysg I am by no means an expert, but i tried to have a look at the code. Is it this commit that you reverted in your custom version of wlconf? https://svn.dd-wrt.com/changeset/36366/
I guess this works fine for the newer models but (at least) for the R7000 it should be like the old code?
If I am on the right track then I could update the issue that I linked to earlier (https://svn.dd-wrt.com/ticket/6404) to get some attention from BrainSlayer or Kong .
@Briefcase yes you’re correct. That’s exactly the portion of code that I’ve reverted. Seems to work for for the Northstar prototype boards whereas the latest code broke all the VIF configuration.
BrainSlayer denied that those codes are the root cause tho. He claims that newer drivers configured the MAC addresses using the new algorithm but it doesn’t look right to me tho. The old codes looks correct.
@Briefcase yes you’re correct. That’s exactly the portion of code that I’ve reverted. Seems to work for for the Northstar prototype boards whereas the latest code broke all the VIF configuration.
BrainSlayer denied that those codes are the root cause tho. He claims that newer drivers configured the MAC addresses using the new algorithm but it doesn’t look right to me tho. The old codes looks correct.
Thanks for your follow-up, I am glad I found the right commit but obviously all the credits are for you on this one haha!
I have updated the issue, see https://svn.dd-wrt.com/ticket/6404#comment:9 . I hope this accurately reflects what we did in this thread. I also added a link from the issue you created to 6404. Hope the devs will have a second look. Thanks again so much for your help Quarkysg.
Joined: 18 Mar 2014 Posts: 12881 Location: Netherlands
Posted: Sun Nov 18, 2018 16:02 Post subject:
@Quarkysg, I use your patched wlconf (and your patched shortcut-fe.ko module) on my Netgear R6400v2 with the latest Kong build 37715 and can confirm that it works, without it I can not connect to the VAP, with the patched wlconf it starts to work.
I noticed that when it is not working it seems I was missing an ethernet address on the bridge, it looks like a layer 2 problem, the names of the MAC's maybe indicate that they are switched or something like that. Really wierd.
@Briefcase yes you’re correct. That’s exactly the portion of code that I’ve reverted. Seems to work for for the Northstar prototype boards whereas the latest code broke all the VIF configuration.
BrainSlayer denied that those codes are the root cause tho. He claims that newer drivers configured the MAC addresses using the new algorithm but it doesn’t look right to me tho. The old codes looks correct.
It probably is unit depended, maybe works on yours but not on his, I don't have any issues on mine with current code. VAPs have always been problematic, timing number of vaps units etc. it never has worked for all configs. _________________ KONG PB's: http://www.desipro.de/ddwrt/
KONG Info: http://tips.desipro.de/
@Briefcase yes you’re correct. That’s exactly the portion of code that I’ve reverted. Seems to work for for the Northstar prototype boards whereas the latest code broke all the VIF configuration.
BrainSlayer denied that those codes are the root cause tho. He claims that newer drivers configured the MAC addresses using the new algorithm but it doesn’t look right to me tho. The old codes looks correct.
It probably is unit depended, maybe works on yours but not on his, I don't have any issues on mine with current code. VAPs have always been problematic, timing number of vaps units etc. it never has worked for all configs.
try to bridge wl0.1 and wl1.1 with same SSID (and WPA) together on freshly reseted r6300v2. I am pretty sure you cannot connect to this VAP
It probably is unit depended, maybe works on yours but not on his, I don't have any issues on mine with current code. VAPs have always been problematic, timing number of vaps units etc. it never has worked for all configs.
VAP has always been working for me until the changes was done recently to wlconf. It looks to me that the new MAC address computation algo is assigning the same MAC address to the virtual wireless interfaces. I guess the BCM wireless driver or the Linux kernel disagree with this and therefore the interface is not useable. The virtual interfaces finally ended up with invalid MAC addresses of 00:00:00:00:00:00.
In any case it looks like reverting the codes fixes the issue for all Northstar prototype router boards, or those boards using the BCM43xx chips.
Without looking at the driver codes, it’s hard to tell tho. Only you guys will be able to debug.
