Joined: 08 May 2018 Posts: 14216 Location: Texas, USA
Posted: Tue Nov 30, 2021 16:11 Post subject:
Speaking of, you know better than most of us what the verdict is for fixing this bug. Last I knew, it was "wontfix"... but anyway, people have to open new tickets.
Speaking of, you know better than most of us what the verdict is for fixing this bug. Last I knew, it was "wontfix"... but anyway, people have to open new tickets.
Speaking of, you know better than most of us what the verdict is for fixing this bug. Last I knew, it was "wontfix"... but anyway, people have to open new tickets.
Joined: 08 May 2018 Posts: 14216 Location: Texas, USA
Posted: Sun Dec 05, 2021 19:48 Post subject:
Not sure if anyone else did or not, but I just passed on your commentary for the ticket and this thread. We hope that this will finally put things to rest and the issues will no longer be issues. Thank you for taking two years to have this epiphany, just in time for Christmas. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sun Dec 05, 2021 22:29 Post subject:
Lanchon wrote:
but BS missed a 3rd change needed in that function.
I understand that submitting patches upstream is complicated using SVN, its retarded SVN hasn't evolved in this department, However Git patches/PR's are compatible with SVN, if you make such a patch would be easier to submit for review.
but BS missed a 3rd change needed in that function.
I understand that submitting patches upstream is complicated using SVN, its retarded SVN hasn't evolved in this department, However Git patches/PR's are compatible with SVN, if you make such a patch would be easier to submit for review.
Enjoy and thanks for the effort.
thanks for the info, much appreciated.
i could sort out some stuff, but i feel there is little engagement here. i ask stuff about the codebase and nobody replies. yes, the answer is in the code, but requires time to dig, and people familiar with it would save a lot of time by giving an effortless answer. but they dont. it is a bit discouraging.
but BS missed a 3rd change needed in that function.
unfortunately that is a dirty proof-of-concept fix i did editing the binaries, but it is not fully correct.
also the same issue is present all over the codebase, at least in these places (but could be others), and all need fixing:
Code:
rod@rod-latitude:~/dd-wrt/dd-wrt/src/router$ grep -sR '"wlan", 4'
hostapd-wps/src/drivers/driver_hostap.c: if (os_strncmp(ifname, "wlan", 4) == 0) {
hostapd-wps/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
libutils/libutils/bridgetools.c: if (strncmp(dev, "wlan", 4) != 0) { // this is not an ethernet driver
libutils/libutils/bridgetools.c: if (strncmp(dev, "wlan", 4) != 0) { // this is not an ethernet driver
libutils/libutils/bridgetools.c: if (!strncmp(dev, "wlan", 4) && (sep = strstr(mainif, ".sta"))) {
libutils/libutils/libbridge_if.c: if (strncmp(dev, "wlan", 4) != 0) { // this is not an ethernet driver
libutils/libutils/libbridge_if.c: if (strncmp(dev, "wlan", 4) != 0) { // this is not an ethernet driver
libutils/libwireless/wl.c: if (strncmp(ifname, "wlan", 4))
libutils/libwireless/wl.c: if (strncmp(prefix, "wlan", 4))
services/services/bonding.c: if (!strncmp(port, "wlan", 4)
services/networking/generic/network.c: if (strncmp(name, "wlan", 4) && strncmp(name, "ra", 2))
services/networking/generic/network.c: if (strncmp(realname, "wlan", 4) != 0) { // this is not an ethernet driver
services/networking/generic/network.c: if (strncmp(realname, "wlan", 4) != 0) { // this is not an ethernet driver
services/networking/generic/network.c: if (strncmp(interface, "wlan", 4))
hostapd-20120910/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
hostapd-2014-04-24/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
httpd/visuals/dd-wrt.c: if (!strncmp(var, "wlan", 4) && strstr(var, ".sta"))
httpd/visuals/portsetup.c: if (!strncmp(var, "wlan", 4) && strstr(var, ".sta"))
hostapd-2017-08-24/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
hostapd-2014-10-25/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
hostapd-2014-06-03/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
hostapd-2018-07-08/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
hostapd2/src/drivers/driver_hostap.c: if (os_strncmp(ifname, "wlan", 4) == 0) {
hostapd2/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
tcpdump/tcpdump.c: strncmp(device, "wlan", 4) == 0) {
hostapd-2016-06-15/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
aircrack-ng/lib/osdep/linux.c: if (strlen(iface) == 5 && memcmp(iface, "wlan", 4) == 0)
hostapd-2016-09-05/src/drivers/driver_wext.c: if (os_strncmp(drv->ifname, "wlan", 4) == 0) {
you have no idea what you are posting here. you simply post a "grep" output without taking care that alot of these codepieces are not even used in broadcom builds. you have to check what these single lines are doing and if they affect the issue before flooding the forum with such totally unrelated postings _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 08 May 2018 Posts: 14216 Location: Texas, USA
Posted: Mon Dec 06, 2021 13:37 Post subject:
The only thing I could see that might get broken here as a result of fixing Broadcom is all other platforms because of shared code. There may be a need to add defines to employ the proper fix to Broadcom and use the previous code for all others. (I am going to copy and paste this to a reply to BrainSlayer's email, too).
Joined: 18 Mar 2014 Posts: 12881 Location: Netherlands
Posted: Wed Dec 08, 2021 13:24 Post subject:
Just tested 47810 I did not do a reset on this router and it is heavily used for testing but I simply made an unbridged VAP the modern way (so without br1 and using DHCPd to setup DNSMasq).
This is also the case on the Atheros routers.
After adding a new DHCP server you have to restart the router otherwise the clients of the VAP can't get an IP address somehow.
I assume that something is not started via the "apply" button.
Joined: 08 May 2018 Posts: 14216 Location: Texas, USA
Posted: Wed Dec 08, 2021 16:07 Post subject:
I think we can lay most of these threads to rest finally (after the next public beta). Not sure anyone would be wanting to use unsecured guest wi-fi, and if they did, I don't think they would be mucking around with clicking "apply settings"(?):
2.4 and 5 GHz, with 2 VAPs on each band (4 VAPs, 6 APs total)
MACs are all ok (but the 2.4 GHz band will support only 14 VIFs -not 16- before clashing with ethernet MACs)
all 6 IFs running WPA2+AES
works fine on boot
works fine after Wireless / Main "apply settings"
works fine with bridged and unbridged VAPs
works fine with different passwords (keys) per VAP
detected issue
all VAPs must use the same auth scheme. if a VAP security is disabled (open network), all works fine after boot. however, as soon as Wireless / Main "apply settings" is clicked, the open VAP vanishes: it is no longer shown on clients. at this stage stopservice wlconf; startservice wlconf restores functionality. (and we are back again with the same workaround, aghhh!)
EDIT: The unsecured vap issue is still an issue to be fixed at some point, per BrainSlayer. But outside of that, all is well in the world of Broadcom VAPs again for the most part _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Joined: 18 Mar 2014 Posts: 12881 Location: Netherlands
Posted: Wed Dec 08, 2021 16:44 Post subject:
kernel-panic69 wrote:
I think we can lay most of these threads to rest finally (after the next public beta). Not sure anyone would be wanting to use unsecured guest wi-fi, and if they did, I don't think they would be mucking around with clicking "apply settings"(?):
2.4 and 5 GHz, with 2 VAPs on each band (4 VAPs, 6 APs total)
MACs are all ok (but the 2.4 GHz band will support only 14 VIFs -not 16- before clashing with ethernet MACs)
all 6 IFs running WPA2+AES
works fine on boot
works fine after Wireless / Main "apply settings"
works fine with bridged and unbridged VAPs
works fine with different passwords (keys) per VAP
detected issue
all VAPs must use the same auth scheme. if a VAP security is disabled (open network), all works fine after boot. however, as soon as Wireless / Main "apply settings" is clicked, the open VAP vanishes: it is no longer shown on clients. at this stage stopservice wlconf; startservice wlconf restores functionality. (and we are back again with the same workaround, aghhh!)
EDIT: The unsecured vap issue is still an issue to be fixed at some point, per BrainSlayer. But outside of that, all is well in the world of Broadcom VAPs again for the most part
Actually I noticed that when the VAP is setup it already had Security in place which I really liked, normally it is open and you have to set security, I like this better.
I checked you can change the password to something else
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Wed Dec 08, 2021 19:54 Post subject:
ho1Aetoo wrote:
egc wrote:
After a reboot it started to work
This is also the case on the Atheros routers.
After adding a new DHCP server you have to restart the router otherwise the clients of the VAP can't get an IP address somehow.
I assume that something is not started via the "apply" button.
Its a question of restarting the right services depending whats changed.