Yes, I can also confim that after removing both packages (kmod-mwifiex-sdio and mwifiex-sdio-firmware), when the 5GHz DFS channel detects a radar changes to a non DFS channel, but not after 30min or so... This happened to me after a few hours (4-6 hours)...

I'm installing again only mwifiex-sdio-firmware to see what happens.... but...

------------

According to yuhhaurlin the issue I opened  - https://github.com/kaloz/mwlwifi/issues/185 Said is just to remove pyh2 ?! My phy2 is ALLWAYS disabled.... How they mean "Remove phy2"?

Also mentions to not change country code...

---------------

New exiting commits arrived!
* Added code to support BSSID assignment of VAP
* Added code to report noise floor

Planning to make a new build?

@S Pimenta

Yes, will make a new one.  I tried just making the wifi driver, but when installed blows the system up and won't boot. Probably operator error on my side.

I see over at DD-WRT, Brainslayer says Marvell has added noise floor to the driver. He has a build available for that. Have not installed to see how it looks compared to what was available.

Guess we can expect to see a new build from David now also.

Thanks. I don't know all that much about Linux-based systems (though I am getting better XD). And much less about github, so I posted this on the github. Hopefully I did it right XD

https://github.com/kaloz/mwlwifi/issues/189

Looks good.  Did this behavior just start happening with @david's latest build (r4512) which includes the 2 commits to mwlwifi that enable rx/tx and signal status?

Yep, a new commit was added to mwlwifi to report the noise level, and a second new commit for VAP.  You can track the progress here: https://github.com/kaloz/mwlwifi/commits/master

Yeah I updated maybe 1 day before this started.

(Last edited by farchord on 7 Jul 2017, 16:10)

Look forward to more of your testing, but so far, it looks like my hypothesis was correct.  Without mwifiex-sdio-firmware, the 88W8887 isn't used in the background for DFS and the 3200acm reverts to the crappy behavior of being scared off DFS just like the 1200/1900 models.  With mwifiex-sdio-firmware, DFS continues to work better on the 3200ACM (because the 88W8887 must be being used in some way) and it doesn't get scared off DFS, simply switches to a different DFS channel, which is the proper behavior if radar is detected.

So, so far it seems kmod-mwifiex-sdio needs to go (to fix previously explained issues) and mwifiex-sdio-firmware needs to stay.

Only question.  You mentioned for the first part of your test (without mwiflex-sdio-firmware installed) it switched from channel 139?  Is that a typo?  I didn't think channel 139 existed.  And what channel did it switch to?  36?

(Last edited by starcms on 7 Jul 2017, 17:05)

I would definitely mention that in your github issue.  That the problem began after upgrading to the driver version that includes the two commits for rx/tx and signal status.

(Last edited by starcms on 7 Jul 2017, 16:18)

Is anyone able to get NTFS disks to show up?
I have a wrt1200ac but also having the problem with a ea4500 and OpenWrt.

NTFS formatted USB's yes.  Hard drives? No.

A word of caution about the latest commits to the mwlwifi driver.  Commit 0f023b7 changes how hardware addresses are assigned to VAP interfaces, but it does so in a way which may be incompatible with 3200ACM devices -- see "Note 1" in the commit message.  This potentially impacts anybody who uses multiple SSID per radio; the single-SSID case is unaffected.  The change is related to issue 162 in the mwlwifi github (I'd link it but I don't have link-posting privileges.)

That said, I am running the new driver and it seems to work despite the overlap in hardware address assignments, possibly because the overlapping addresses are in separate broadcast domains (5GHz vs 2.4GHz).  I haven't tested it extensively, however.

Here's what I mean by overlapping addresses:

root@LEDE:~# diff -y -W42 /sys/class/ieee80211/phy[01]/addresses
                    >   60:38:e0:b8:a9:99
60:38:e0:b8:a9:9a       60:38:e0:b8:a9:9a
60:38:e0:b8:a9:9b       60:38:e0:b8:a9:9b
60:38:e0:b8:a9:9c       60:38:e0:b8:a9:9c
60:38:e0:b8:a9:9d       60:38:e0:b8:a9:9d
60:38:e0:b8:a9:9e       60:38:e0:b8:a9:9e
60:38:e0:b8:a9:9f       60:38:e0:b8:a9:9f
60:38:e0:b8:a9:a0       60:38:e0:b8:a9:a0
60:38:e0:b8:a9:a1   |   62:38:e0:b8:a9:99
62:38:e0:b8:a9:9a   <

root@LEDE:~# ifconfig wlan0 | grep HWaddr
wlan0     Link encap:Ethernet  HWaddr 60:38:E0:B8:A9:9A
root@LEDE:~# ifconfig wlan1-1 | grep HWaddr
wlan1-1   Link encap:Ethernet  HWaddr 60:38:E0:B8:A9:9A

Typo -- channel 136 and switched to 36. 

Will keep testing.

The last few latest builds(leve mvebu snapshot) killed my 5ghz as well, rolled back to David's 4470 build before a new one came out and it had better wifi performance because of building on stable I suppose. I'll wait out a few more commits before I flash again.  e: reminder 3200acm commits and maybe a lil buggy(wrt1200ac v2 here)

(Last edited by jdc2389 on 8 Jul 2017, 00:21)

Once again... this build (r4542) is recommended for Linksys 3200acm owners as it just addresses the latest mwlwifi commit. However, if you are new feel free to download and install. 1900ac Version 1 owners are continued to be warned that frequent reboots happen with the latest Kernel 4.9.34. If you want to just avoid the reboots, there's a separate build with Kernel 4.4.x  ->  https://davidc502sis.dynamic-dns.net/sn … u/generic/

3200acm driver improvement - "Added code to report noise floor" <- Thank you yuhhaurlin

So far I can confirm the Signal/Noise ratings appear to be working.

Also, this build removes the package kmod-mwifiex-sdio, but is available from the repo.

*EDIT*
Looking at the driver version, it says 0606, but is actually 0607.

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

(Last edited by davidc502 on 8 Jul 2017, 03:17)

Hey David, I might of messed up...I accidentally installed the WRT1200AC LEDE on a OEM WRT1900AC (v.1)

Any suggestions? Sorry, noob here. I Tried searching directly for this issue.

Just do the power on/off recovery to revert back to the other partition. Then try flashing again.

Instructions from the wiki.

Power off router with power switch.
Turn power back on and Power LED will light.
As soon as all LEDs turn off (~2s), power off router with power switch
Turn power back on and Power LED will light.
As soon as all LEDs turn off (~2s), power off router with power switch
Turn power back on and Power LED will light.
As soon as all LEDs turn off (~2s), power off router with power switch
Turn power back on and allow router to fully boot.
It should now be booted to the alternate firmware partition (partitions)

Wish it was that easy... any other suggestions? Tried it about three times.

When you power on wait 6 seconds and power off. Do this 4 times and power back up completely.

Then bring up command line, on your pc, and ping 8.8.8.8 and see if there's a response.

That worked...thank you for all the awesomeness. I almost resulted to watching Nick Cage films and drinking out of depression.

@david, I'm assuming it also includes the other new mwlwifi commit as well (since it was added between the two that fixed tx/rx and signal and the one that fixed noise) which "Added code to support BSSID assignment of VAP"?

and did you get adblock working again and plugins working for dnscrypt?

Just curious why you only recommend it for 3200acm users.  Sure, the new commits to mwlwifi are only for the 3200acm, but the build in general has newer versions of other packages and fixes made to LEDE since r4470.  Plus, if the new commits for the 3200acm break anything on the 1200/1900 models, it would be good to let @yuhhaurlin know asap before he publishes an official driver (one with the version number updated).

Edit: Also, did you forget we are in July now?  The version number really should be 20170707   The reason why
root@lede:~# strings /lib/modules/*.*/mwlwifi.ko | grep "^10.3" shows 10.3.4.0-20170606 is because the last time @yuhhaurlin made a commit that updated the version number, it was updated to version number 10.3.4.0-20170606.  You can change the version number of the ipk file by modifying the makefile as I'm guessing you did, but to actually change the version number of mwlwifi.ko, you need to update the file hif/pcie/dev.h before you make/compile.  See here for an example the last time @yuhharulin updated it:  https://github.com/kaloz/mwlwifi/commit … a4eb1f8629

Edit2: Adblock is working fine and dnscrypt has plugins enabled!  Great job.  I'll let you know if I encounter any issues.  Running on my 1200AC.

Edit3:  Running perfectly fine on my 1200AC.  Doesn't look like any bugs reverted to 88W8864 from new changes to mwlwifi so that's good.

(Last edited by starcms on 8 Jul 2017, 08:40)

@starcms

Yes, I'm still living in the month of June. lol

I though for some reason, and apparently wrong, that I was able to change the version number without having to change it in the dev.h file. Looks like this needs to be done as well before compiling. Thanks for finding it, and will add it to the todo list.

For Wifi 5Ghz, I set the router to channel 64, and when I woke up this morning it had changed to channel 149.

*EDIT*

I am seeing this in the kernel log a lot.

[27408.382740] WARNING: CPU: 0 PID: 0 at compat-wireless-2017-01-31/net/mac80211/rx.c:4224 ieee80211_rx_napi+0x88/0x81c [mac80211]
[27408.394277] Modules linked in: pppoe ppp_async pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY ums_usbat ums_sddr55 ums_sddr09 ums_karma ums_jumpshot ums_isd200 ums_freecom ums_datafab ums_cypress ums_alauda ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp
[27408.466125]  nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt fuse sch_cake em_nbyte act_ipt cls_basic sch_prio sch_pie sch_gred em_meta sch_dsmark sch_teql em_cmp act_police em_text sch_codel sch_sfq sch_fq sch_red act_connmark nf_conntrack act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress mwlwifi mac80211 cfg80211 compat cryptodev xt_set ip_set_list_set ip_set_hash_netiface ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables msdos bonding ifb tun vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp437 sha512_generic sha256_generic md5 hmac authenc ohci_pci uhci_hcd ohci_platform ohci_hcd gpio_button_hotplug
[27408.567978] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W       4.9.34 #0
[27408.575141] Hardware name: Marvell Armada 380/385 (Device Tree)
[27408.581096] [<c0016010>] (unwind_backtrace) from [<c0012220>] (show_stack+0x10/0x14)
[27408.588874] [<c0012220>] (show_stack) from [<c020fb9c>] (dump_stack+0x7c/0x9c)
[27408.596127] [<c020fb9c>] (dump_stack) from [<c0029214>] (__warn+0xbc/0xec)
[27408.603031] [<c0029214>] (__warn) from [<c00292e8>] (warn_slowpath_null+0x1c/0x24)
[27408.610658] [<c00292e8>] (warn_slowpath_null) from [<bf1ae250>] (ieee80211_rx_napi+0x88/0x81c [mac80211])
[27408.620296] [<bf1ae250>] (ieee80211_rx_napi [mac80211]) from [<bf20e674>] (pcie_rx_recv_ndp+0x92c/0xa58 [mwlwifi])
[27408.630698] [<bf20e674>] (pcie_rx_recv_ndp [mwlwifi]) from [<c002daf4>] (tasklet_action+0x8c/0xe8)
[27408.639695] [<c002daf4>] (tasklet_action) from [<c002d28c>] (__do_softirq+0xd0/0x204)
[27408.647558] [<c002d28c>] (__do_softirq) from [<c002d644>] (irq_exit+0x94/0xb8)
[27408.654813] [<c002d644>] (irq_exit) from [<c0061d18>] (__handle_domain_irq+0x90/0xb4)
[27408.662676] [<c0061d18>] (__handle_domain_irq) from [<c0009428>] (gic_handle_irq+0x50/0x94)
[27408.671061] [<c0009428>] (gic_handle_irq) from [<c0012c8c>] (__irq_svc+0x6c/0x90)
[27408.678572] Exception stack(0xc0623f60 to 0xc0623fa8)
[27408.683644] 3f60: 00000001 00000000 00000000 c001b1c0 00000000 c0622000 c0624fe4 00000001
[27408.691856] 3f80: c061f168 00000000 c0623fb8 00000001 00000000 c0623fb0 c000f808 c000f80c
[27408.700065] 3fa0: 60000013 ffffffff
[27408.703569] [<c0012c8c>] (__irq_svc) from [<c000f80c>] (arch_cpu_idle+0x2c/0x38)
[27408.710999] [<c000f80c>] (arch_cpu_idle) from [<c005b04c>] (cpu_startup_entry+0xf0/0x19c)
[27408.719215] [<c005b04c>] (cpu_startup_entry) from [<c05dbc50>] (start_kernel+0x398/0x41c)
[27408.727438] ---[ end trace 8515f1bd62243ec5 ]---

(Last edited by davidc502 on 8 Jul 2017, 15:24)

@davidc502,

I think this crash has been reports in https://github.com/kaloz/mwlwifi/issues/186.
It seems to be caused by reporting a wrong rate index.
@yurhaulin said he'd look into it.

@david,

As for the kernel error, as @adri said, it has been reported to @yurhaulin.  It is caused by the commit that fixed the rx/tx rate, but he said he will fix it.  Luckily, not seeing it here on my 1200AC, so it only shows up on the 3200acm I am guessing.  It can either cause the router to crash, or simply appear in the log without causing a crash.

The DFS behavior you are seeing now on your 3200acm, with it switching from one DFS channel to either another DFS channel or a non-DFS channel (in your first test with mwifiex-sdio-firmware it switched to another DFS channel (132) and in the second test with mwifiex-sdio-firmware it switched to a non-DFS channel (149)), is this the same behavior as when you had kmod-mwifiex-sdio installed in addition to mwifiex-sdio-firmware? 

I'm pretty sure it must be.  So looks like I was correct: kmod-mwifiex-sdio should be removed, but mwifiex-sdio-firmware should be kept for proper (or at least better) DFS behavior, just as you have it in your latest build, r4542.  Because as your previous test without mwifiex-sdio-firmware showed, the 3200acm jumps from a DFS channel to channel 36 always when radar is detected which is the very incorrect behavior that the 1200/1900 models exhibit.  So mwifiex-sdio-firmware is definitely having a positive impact on channel selection when radar is detected.

Edit/addition: I am sure radar is still being falsely detected when there is none on DFS channels (random interference on the current DFS channel is not supposed to trigger radar detected and a channel switch.  The FCC has published very specific and unique patterns of interference which is the only thing meant to trigger a radar warning and a channel switch when on a DFS channel).

However, on the 1200/1900, when radar is "detected", it always switches to channel 36 (most likely because the 1200/1900 don't officially support DFS, and in the official Linksys firmware, you can only select from non-DFS channels (36, 40, 44, 48, 149, 153, 157, 161).  Therefore, it was probably never programmed in the 88W8864 firmware what to do when radar was detected (since it doesn't support DFS officially) and just switches to the first available channel (36) when ordered to switch channels by LEDE.  On the 3200acm with mwiflex-sdio-firmware package installed, when radar is "detected," it switches to any other channel, DFS or not. It most likely switches to the channel the 88W8887 senses has the least interference at the moment of switching.  Without mwifiex-sdio-firmware installed on the 3200acm, it's channel switching behavior reverts to that of the 1200/1900 models (it will only switch to channel 36). 

So the 3200acm doesn't have better/more accurate radar detection (well it does because it has the 88W8887, but it isn't currently being utilized); but it does have a working channel switching behavior when "radar" is detected.  For accurate radar detection on the 3200acm, an algorithm is needed which monitors the current channel (if it is DFS) with the 88W8887 and listens for the specific patterns of interference which correspond to actual radar.  Or, the algorithm may be built into the firmware of the 88W8887, but either a) we are missing an open-source DFS driver for the 88W8887 (remember kmod-mwifiex-sdio is an AP driver only) which doesn't exist yet or b) the firmware for the 88W8887 in the mwifiex-sdio-firmware package is out of date or c) both.

Anyone know if all routers which officially support DFS (the 1200/1900 models do not as mentioned before) incorrectly detect any interference as radar on LEDE/OpenWRT and quickly switch channels (within approx 30 minutes to a couple hours)?  Or is it only the 3200acm?

Lastly and un-related to the above, does LEDE/OpenWRT support MU-MIMO on the 3200acm?  If so, does it work?  I'm guessing no, and it will need to be added to the mwlwifi driver.

(Last edited by starcms on 9 Jul 2017, 04:44)

Hi! I read the review of SmallNetBuilder for the WRT3200 and see the performance in WAN-LAN TCP and LAN-WAN TCP is very low, can the LEDE firmware solve the low performance?

PD: Is any one working to make a gwlin fastpath LEDE versión for WRT3200