I haven't tested in a while but on the 1900/3200 series routers you should be getting just about max speeds already. Last I checked it was approximately 900mbps/900mbps using NAT on the 1900acs and 3200acm. Two years ago I tested with the 1900ac V1, and it was getting around 725mbps/700mbps.

This is the latest thread on the subject.  https://forum.lede-project.org/t/qualco … e/4582/219

I've loaded the Linksys firmware on the 3200acm and am now testing DFS channels.

*edit*

Set on channel 108 to start. Under LEDE it would switch off of 108 within a few hours.

(Last edited by davidc502 on 9 Jul 2017, 15:52)

I wouldn't be surprised if on the official Linksys firmware the 88W8887 is fully functional in actually detecting radar (and doesn't simply interpret any noise/interference as radar) and therefore doesn't cause a channel jump within 30min to a couple hours...

If it doesn't behave completely properly on the official firmware, that is just sad...

Even if it does behave properly on the Linksys firmware (which it damn well should lol), I don't think @yuhhaurlin will be able to help getting it fully functional on LEDE because I know he has said in the past that mwlwifi will remain only for the 88W8864 and 88W8964...

(Last edited by starcms on 9 Jul 2017, 16:54)

I agree, but I'm concerned because yuhhaurlin has given mixed signals on if DFS will be supported or not. He closed the DFS Issue that was open for some time. I realize it isn't going to be supported on the 1900/1200x line because Linksys OEM does not, but thought it would be on the 3200acm.  At some point will bring DFS back up again when some of the other issues are worked out.

By the way... Linksys Factory Firmware has already switched from channel 108 to channel 124.  Will be interesting to see if it stays on DFS or eventually switch off.

Well, if the factory firmware switched that quickly, he definitely won't address it, unless you actually have radar in your area. Are you within 15 miles of an airport or a university?  He's made it crystal clear that if the factory firmware does something, the open source version will do the same.

With your testing on LEDE, you had said it switched from 108 to 132 on the first test with mwiflex-sdio-firmware installed. Did it stay on 132 or eventually move off DFS?  Or you didn't test long enough to see?

With your tests so far, it appears LEDE with mwiflex-sdio-firmware works exactly the same as stock firmware in regard to DFS (big surprise to me!).

Edit: The one thing that makes me think you don't have actual radar in your area is that if you did, it wouldn't let you change to channel 108 in the first place. Unless it's very intermittent, or more likely the firmware isn't looking for the actual radar patterns but simply any noise or interference.

(Last edited by starcms on 9 Jul 2017, 20:25)

hi davidc502,

thanks for the great alternative firmware.  i have been testing the firmware for a couple of days now.  the first issue i encountered was the random reboots.  i then uploaded the suggested firmware version from your website and have not had a random reboot yet.  i have installed the wifi schedule package and the internet access control package and cannot see it under services.  is this expected?  can someone please point me posts where the random reboots is explained?  thank you.  again thanks for the great firmware...

WRT1900AC V1

(Last edited by lceron on 10 Jul 2017, 02:08)

(Testing with LEDE) Yes, it eventually switched off of DFS, so I did test long enough to find out, and that was with mwiflex-sdio-firmware installed.

Last night I had to revert back to LEDE as I wasn't able to get my two fireTV boxes to connect via 5Ghz wifi to the stock firmware. I tried forgetting the SSID (FireTV menu option to forget) and re-entering my password, but both refused to connect no matter what I did. It was on the stock firmware long enough for me to determine that performance and DFS behave very close to what we use on LEDE.

One area the driver needs improvement is digging the signal out of the noise basement. Actually, I don't know how possible it is to make an improvement. To give you an example, every night between 5-11pm the noise level, in my home goes up, and download throughput drops in step with the noise (re-transmissions etc). Download usually drops to around 10mbps, but upload usually remains strong at around 250mbps (fluctuates).  It appears the router does not have an issue receiving transmissions from my phone, but my phone's have an issue receiving the signal until the noise drops off.   The same behavior is observed from the stock firmware last night.

Here is the lede conversation about the reboots >  https://forum.lede-project.org/t/wrt190 … -9/2025/51

As for wifi scheduling - did you install luci-app-wifischedule_git-17.186.70712-4f127c3-1_all.ipk?  That package is needed to see the options in Luci.  I've never used internet access, so I don't know if it has a luci package or not. I didn't a quick search and didn't come up with anything. If it is not included then all the configurations will be done through command line.

Looks like we have additional Wifi commits for the 3200acm.

@yuhhaurlin
Ignored incorrect rx accounting.  …
yuhhaurlin committed 18 hours ago
8a71713 
@yuhhaurlin
Corrected the way to extend BSSID for VAPs.  …
yuhhaurlin committed 18 hours ago
4fd0788 
@yuhhaurlin
Modified the way to support BSSID for VAPs.  …
yuhhaurlin committed 18 hours ago

The "Ignored incorrect rx accounting" is supposed to fix the kernel log and crash issues some, including yourself, were reporting:

[27408.382740] WARNING: CPU: 0 PID: 0 at compat-wireless-2017-01-31/net/mac80211/rx.c:4224 ieee80211_rx_napi+0x88/0x81c [mac80211]

so a new build as soon as you can would be great because @yuhhaurlin is asking for feedback to see if it worked

Edit:  Good thing you didn't build yet.  Apparently it was still happening and he just added one new commit to try to fix it.

@yuhhaurlin
Added more checks for rx accounting.
yuhhaurlin committed 3 minutes ago
53e10cf

(Last edited by starcms on 11 Jul 2017, 03:15)

This is an odd issue.  Do you see your noise levels increase during this time?  What do they increase to?  I'm assuming you are talking about 5GHz.  Have you tried different channels (does it do it just as badly on ch 36 as on 161)?  Can't believe it drops all the way to 10mbps, every night.  That seems to suggest something major is happening very close to you.  Do you live near a power substation?  Have you observed similar things on other routers?  Possibly the strangest part is that upload remains fine...almost as if something is happening in the room where your router is located during that time period...

Well, this is good to know.  So conclusion seems to be that LEDE (with mwifiex-sdio-firmware) doesn't seem to muck up DFS performance on the 3200acm.

I'm going to upload just the driver in the next hour or so.

Doesn't appear to muck, but my testing is un-scientific. I wish I could create what would be a radar signal that it should be avoiding in a room where only that signal can be heard.

So you know, I've tested every DFS channel on 40 and 80mhz, and it refuses to stay on that channel any more than a couple of days (most just hours). I still want to do additional testing now that we know more about rado2 and mwifiex.

Yes, I am less than 15 miles from an airport, but from what I understand, and could be wrong, that only certain airports emit this type of radar, and I don't believe Nashville International is one of them, so if this is true, then the channel should never change. Once again more research should be done to confirm this.

Yes, it is very very odd... no substation or any electromagnetic interference that I'm aware of.

I have a laptop running linux, and will create a shell script that will test upload/download every 30 minutes and output the noise level. If time allows, will work on getting it set up in the next few days.

*EDIT*  Yes, I've tested all the available channels.

(Last edited by davidc502 on 11 Jul 2017, 03:39)

If you can build just the updated driver, that would be great, and I'm sure save you alot of time and effort!  I know you've tried before a while ago, but for whatever reason it wouldn't let the router boot. 

@yuhhaurlin added instructions on how to build an updated driver in the readme at the bottom of https://github.com/kaloz/mwlwifi but they make absolutely no sense to me.  "How to replace mwlwifi on your current LEDE/OpenWrt build"

And check out https://github.com/kaloz/mwlwifi/issues/186 for the latest on the kernel error issue related to the rx/tx status on the 3200acm.

(Last edited by starcms on 11 Jul 2017, 03:51)

I think the main issue is that even though Linksys went out of the way to add the 88W8887 to aid in DFS/radar detection (it isn't even needed, both the 88W8864 and the 88W8964 are capable of DFS on their own), they didn't program it properly.  As I've said previously, radar should only be detected if a very specific pattern or patterns of noise are detected, which the FCC has specified.  I think Linksys basically programmed it in the firmware that if any noise or interference is detected on the current channel to mark it as radar and force a channel switch.  This is speculation of course, but it seems to be the case with the way it's been observed to operate.

I know you tested the stock Linksys firmware for less time, but the same behavior was observed?

Have you tried putting a phone or laptop directly next to the router during that time period to see if it's performance goes back to normal while its in immediate proximity to the router?

Does this happen all year round?

Edit:  Also, I noticed you said "One area the driver needs improvement is digging the signal out of the noise basement."

Since it's the download that craps out, but the upload speed remains fine, wouldn't that mean the router is actually doing a great job of digging the signal out of the noise, but the same can't be true for your phones/laptop/etc?  As you said yourself:  "It appears the router does not have an issue receiving transmissions from my phone, but my phone's have an issue receiving the signal until the noise drops off."

(Last edited by starcms on 11 Jul 2017, 04:26)

Okay, the new 3200acm wifi driver is ready to be downloaded.  https://davidc502sis.dynamic-dns.net/re … _vfpv3.ipk

Recommending the following to install.

1. Recommending build r4542 because that's what I tested on.
2. Recommend the following commands. (Recommend typing out or copying the full driver name when in installing new driver. In other words don't TAB to auto complete the name because it will put an extra \ in the name).  If you do use the TAB key to auto complete the name, just remove the extra \ and it will be fine.

root@lede:~# opkg list-installed |grep mwl
kmod-mwlwifi - 4.9.34+10.3.4.0.git-2017-06-10-1
root@lede:~# opkg remove kmod-mwlwifi - 4.9.34+10.3.4.0.git-2017-06-10-1
Removing package kmod-mwlwifi from root...
root@lede:~# opkg install /tmp/kmod-mwlwifi_4.9.34+10.3.4.0.git-2017-07-10-1_arm_cortex-a9_vfpv3.ipk
Installing kmod-mwlwifi (4.9.34+10.3.4.0.git-2017-07-10-1) to root...
Configuring kmod-mwlwifi.
root@lede:~# reboot

#3.  Even though I created my own archive for the mwlwifi driver and updated the version number in the dev.h file, the command output for the version number is incorrect. For some reason it defaulted to 0606, but it really is 0710 (the latest).

root@lede:~# strings /lib/modules/*.*/mwlwifi.ko | grep "^10.3"
10.3.4.0-20170606

Excellent job!  Works great!  Just a few things to add to make sure everyone is successful:

1. @david's r4542 build is required or you will wind up in a boot-loop.

2. Instead of removing the old version, you can simply do:
opkg install kmod-mwlwifi_4.9.34+10.3.4.0.git-2017-07-10-1_arm_cortex-a9_vfpv3.ipk --force-reinstall

That is all

@david, that is so wierd how mwlwifi.ko is still reporting 0606 as the version.  You edited hif/pcie/dev.h just like in this commit and then compiled?  Very strange, but also not very important https://github.com/kaloz/mwlwifi/commit … a4eb1f8629

edit: Also, I am running this on my 1200AC.  Why?  Because I wanted to make sure the new commits for the 3200acm didn't mess up anything on the 1200/1900 models and because I'm OCD. 

(Last edited by starcms on 11 Jul 2017, 04:59)

@david, lol, @yuhhaurlin made a commit changing the driver version to 0711

@anyone with a 3200acm, please:

a) Please install @david's latest build (r4542) and the latest mwlwifi (wifi) driver he posted 2 posts above this.
b) Run the iperf3 test a few times
c) Check your kernel log and see if you see long errors that begin with something very similar to (or if your router simply crashes and/or reboots):

[27408.382740] WARNING: CPU: 0 PID: 0 at compat-wireless-2017-01-31/net/mac80211/rx.c:4224 ieee80211_rx_napi+0x88/0x81c [mac80211]

d) Also check your Rx Rate/Tx Rate for Associated Stations either on the Status --> Overview page or the Network --> Wireless page on LuCi and see if they give correct results all the time, or if they sometimes show 0.

@yuhhaurlin, the maintainer of the mwlwifi driver, is trying to make sure that he has both fixed the kernel error issue (which was caused by him enabling Rx/Tx rates on the 3200acm), but also that the fix for the kernel issue isn't sometimes causing a rate of 0 to be reported.  The kernel error might not appear when you run iperf3, and may take just a few days of run-time to get it to appear, but iperf3 or other high activity (such as IPTV) has been known to trigger it. 

If any issues, please also say so and if you don't mind, copy and paste the kernel log error line that is extremely similar to the one above (but please post your actual one, not the one above) and the fact that you are running @david's build which is based on LEDE snapshot r4542 (which includes kernel 4.9.34 and mac80211 module version 2017-01-31) to this issue thread: https://github.com/kaloz/mwlwifi/issues/186 @yuhhaurlin thanks you in advance!

For more info on this, please see that link as well.

Thanks everyone for your help!

(Last edited by starcms on 11 Jul 2017, 11:56)

Even though I prepared a mwlwifi package and placed in the dl folder, after checking the directory after compile, a new mwlwifi source was downloaded and used, hence why it defaulted back to 0606.

I think it had something to do with how I named the wmlwifi package. With the latest driver being today's date, I won't have to do anything to re-compile tonight.

Thanks for the help.

WRT1900ACv1 user here. Switching from DDWRT to Lede Reboot SNAPSHOT r4470-f788fd0 has been very worthwhile. Overall latency and wifi speeds are the best they have ever been for me. Thank you for the great firmware.

Be sure to go over to the lede forum and do the same as the developers and maintainers deserve the credit.