Can someone try dissasoc low ack disable in advanced settings, both wlan0 and wlan1, then save and reboot?
That's disabled by default.
In my case, I have it disabled always and this issue still present with devices which are active a couple of meters away from ap. _________________ Linksys WRT3200ACM
Joined: 08 May 2018 Posts: 13292 Location: Texas, USA
Posted: Tue Aug 24, 2021 16:10 Post subject:
Uhm, we're not using a binary blob driver; the wifi chipset firmware binary blob(s) is(are) the same being used on stock and OpenWRT. I don't know *how* anyone things we are not using Mr. Kaloz's code, other than driver source code is not in the public svn. Just wanted to interject this information so no more disinformation continues on the subject. As for resetting nvram variables, there is and isn't some merit there. Reason being is that nvram is written to during the flash upgrade process and reboot; if an nvram variable does not exist, it is created. If it exists and has old values, it may be ignored... so any change to the value that may fix something might not be committed. This is why sometimes you have to click through and "Save" every page in the webUI and reboot to commit the new values if somehow they were not written. Also, the only recent patches I have found in respect to Divested, PureFusion and stock OpenWRT is the Linux 5.x compile patch(es). So, someone needs to point out specifically what "patches" are being referred to. _________________ "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... At some point, people just get plain tired of this place. Because they are tired of bottom-feeders and the same old hat.
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Joined: 04 Aug 2018 Posts: 1386 Location: Appalachian mountains, USA
Posted: Tue Aug 24, 2021 16:13 Post subject:
7heblackwolf wrote:
If the blame is on the Marvell drivers, it's easy to think that the solution is to revert them to the working version when 44048 came out. No need to have the source code for that. It just works, we keep that driver version, the rest of the system can be updated. Then everyone's happy.
AND security update that breaks the entire connection sounds like cutting your ethernet cable to prevent hacking. The driver revert until a well working new one comes, is a must to keep at least functionality.
I can't say you're wrong, certainly, but the idea has come up multiple times in these forum discussions of the issue, and to my knowledge, it hasn't been tried in spite of the fact that BS certainly watches the new-build forums where these discussions happen. To me that means either he knows that the problem is not the drivers or that he knows or strongly suspects that the problem addressed with the driver change is too serious to ignore. I think we have to respect his judgement on this one. (Not that we really have a choice.) _________________ Five Linksys WRT1900ACSv2 routers on 51530: VLANs, VAPs, NAS, client mode, OpenVPN client (AirVPN), wireguard servers (via AirVPN port forwarding) and clients (AzireVPN, AirVPN), 3 DNSCrypt providers via VPN clients.
Joined: 08 May 2018 Posts: 13292 Location: Texas, USA
Posted: Tue Aug 24, 2021 16:30 Post subject:
In response to the driver issue(s), I will say this: I have personally emailed BS on at least one occasion about this and he's specifically said that there is nothing to fix or that it's a known issue; meaning he can't seem to find any way to manipulate the driver code to fix this.
That being said, if we were using the stock firmware binary blob object file drivers, we would have to use a specific kernel version, or rather a kernel version that is in the same kernel family as stock firmware (i.e. if it were Linux 3.x, we would have to use Linux 3.x). I will say that most all of the Linux 3.x and newer kernels here are getting backports patches from mainline (Linux 5.x), so if that is in play here as far as the "problem", and we are using OpenWRT's drivers, ... and I forgot where I was going with this. Other than to also interject that the open-source, already-present kernel driver code for mwifiex is configured in the kernel configs... along with mwlwifi @ kaloz. _________________ "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... At some point, people just get plain tired of this place. Because they are tired of bottom-feeders and the same old hat.
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Joined: 08 May 2018 Posts: 13292 Location: Texas, USA
Posted: Tue Aug 24, 2021 21:47 Post subject:
Added a reference sticky for all the threads discussing this never-ending issue with Apple / wifi settings. I left out the discussion in build threads since that would've ballooned the post into an infinite scroll.
Posted: Tue Feb 15, 2022 12:58 Post subject: One problem solved, another appeared
With the v3.0-r48322 std (02/11/22) firmware the iOS devices indeed no longer disconnect and that's great. However, I noticed that the iOS connection speed is about half of what it used to be. My PC that uses WiFi 6 works fine and obtains full speed (almost same as when wired). My other PC that uses WiFi 4 and 5 doesn't even see the 5 GHz network and refuses to connect to the 2.4 GHz one. I tried two other firmware versions - 44715 (latest listed in the DD-WRT database) and 48362 (latest beta published today), but the two issues are the same; iOS devices on half speed and my other PC not seeing 5 GHz and not connecting to 2.4 GHz.
