Yes the noise statistic is still anchored at -114dBm on Brainslayer's dd-wrt latest, r32555, as well.  At least they appear to be working on things. .

Ahh, I guess I have an 1900ACSv2 so I have to wait until it works, it is only 3200, right? Thanks so much! CIAO!

@david, I don't know how you build all the packages in your repo.  I assumed you could simply grab the latest files from github (which contained the 2 new commits that fix Rx/Tx and signal on 3200acm) and build only the kmod-mwlwifi.ipk file without building the entire image.  And since the version number is in the file hif/pcie/dev.h, I assumed you could simply edit it to whatever you wanted before you built the package.  I saw that is how @yuhhaurlin changes the version number in commits such as this one: https://github.com/kaloz/mwlwifi/commit … a4eb1f8629

Note: I've never actually gone through the process of building a ...working...   lede image myself, or even a package for that matter, so I guess I should just leave it up to the pros like you   I guess it's easier said than done.

Anyway, I see you already released a build with the latest mwlwifi commits, and updated the version number of the mwlwifi ipk, so the point is moot   Thanks for releasing new builds so quickly!

(Last edited by starcms on 5 Jul 2017, 09:34)

it already works on all models but the 3200...

The driver for the 1200ac/1900ac/1900acs (v1 and v2 models for all three) has been stable and fully functional for a long time now (yes, it may have a few small bugs according to the issues on github, but vast majority of people don't notice any), 

The 3200acm is a much newer model and uses a different wifi chipset (the 88W8964 instead of the 88W8864 that all the 1200/1900 models use).  So even though all the models and both wifi chipsets use the same mwlwifi driver, the functionality for the 88W8964 (in the 3200acm) in the driver is still maturing.

it is very weird, because no matter I do, on the 2.4ghz, it cannot turn on N, only B/G, I tried all options, N is not enabled at all.

patrikx3-digi-slow    AP    60:38:E0:10:A7:EE    7    2442    -53    -95    100    No    None    108(b/g)

I can see, it is 108b/g.
Are you enable N on 1900ACS???

Edit: Ignore previous comment on speeds.  Based on your response, I see you used MBps and not Mbps.  So you are achieving great speeds on 40MHz 2.4GHz.

But just curious, what configuration changes did you have to make to get 40MHz on 2.4GHz to work?

(Last edited by starcms on 6 Jul 2017, 06:24)

In Network -->Wireless, click Edit on radio1 (the second one), and for mode make sure you have N selected and not Legacy.  It is set that way by default, on @david's builds anyway.

Edit: What is 108?  Is that the speed?  The maximum speed of b is 11Mbps and g is 54Mbps.  So if 108 is the speed, you must be on N already.

(Last edited by starcms on 5 Jul 2017, 08:52)

Just curious, has anyone on a 1200/1900 seen a noise level that low?  The lowest I've ever seen on my 1200AC is -90 dBm, for both 2.4GHz and 5GHz.  Is it lower on the 1900 (and therefore on the 3200) because of 4 antennae instead of 2 on my 1200AC?

With my previous 1200AC v2 i had seen -91.
And with my new 1900ACSv1, the same, -91.

I usually get between -89 and -91 dbm on 5Ghz with a WRT1900ACS v1.
Bad channels might go as high as -83 dbm.

@davidc502

A suggestion: You should remove on the build kmod-mwifiex-sdio and mwifiex-sdio-firmware

It just makes trouble (for about 3 months) to be unable to use DFS channels on 5GHz (this was my case)

On LEDE build I simply cannot use DFS channels after realising this.

On DD-WRT neve had this problem...

And this is not only me: https://github.com/kaloz/mwlwifi/issues/173

Remove kmod-mwifiex-sdio from your image:

make menuconfig
Uncheck: Kernel modules->Wireless Drivers->kmod-mwifiex-sdio
make V=s

Appears yuhhaurlin recommended its removal some time ago.

Would like to hear some thoughts of this potential change.

Is this the 3rd radio most of us have disabled anyway?
https://github.com/lede-project/source/pull/893/files

Also, does this change affect the way the router detects signals in the DFS range? Keep out of mind, most all of us agree the detection of radar isn't working right on the 3200acm, and does this change affect the legal status of radar detection in the FCC's minds? People outside of the USA may or may not be affected by this.

Thanks,

(Last edited by davidc502 on 5 Jul 2017, 16:49)

One question that comes to mind... Did you manually remove these two packages, and has that fixed the DFS issue?

Yes. Just ssh

opkg remove kmod-mwifiex-sdio
opkg remove mwifiex-sdio-firmware
reboot

The mwifiex is for the 3rd radio?

I'm trying to get a USB LTE modem / jetpack to work and could use some help - thanks in advance

my router / firmware:
Model    Linksys WRT1200AC
Firmware Version    Lede leviathan VI r3716-cd0f990 / LuCI Master (git-17.068.73516-4c10d29)
Kernel Version    4.4.53

I've installed the following packages:
opkg install usb-modeswitch kmod-mii kmod-usb-net kmod-usb-wdm kmod-usb-net-qmi-wwan uqmi
opkg install kmod-usb-serial-option kmod-usb-serial kmod-usb-serial-wwan

after reboot, I expected to see /dev/cdc-wdm0 - but it does not exist

if I look at /sys/kernel/debug/usb/devices, I see my jetpack

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=10a9 ProdID=6080 Rev= 2.28
S:  Manufacturer=Pantech, Incorporated
S:  Product=PANTECH MHS291LVW
S:  SerialNumber=PTMHS291LVW20164093
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

If I look at dmesg | grep usb:

[    0.060870] usbcore: registered new interface driver usbfs
[    0.060902] usbcore: registered new interface driver hub
[    0.060930] usbcore: registered new device driver usb
[    1.106677] orion-ehci f1058000.usb: EHCI Host Controller
[    1.112119] orion-ehci f1058000.usb: new USB bus registered, assigned bus number 1
[    1.119787] orion-ehci f1058000.usb: irq 36, io mem 0xf1058000
[    1.141568] orion-ehci f1058000.usb: USB 2.0 started, EHCI 1.00
[    1.155957] usbcore: registered new interface driver usb-storage
[    1.249355] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.254724] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
[    1.262366] xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x00010010
[    1.270949] xhci-hcd f10f8000.usb3: irq 43, io mem 0xf10f8000
[    1.295768] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.301107] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 3
[    1.308664] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.621564] usb 2-1: new high-speed USB device number 2 using xhci-hcd
[    1.775006] usb-storage 2-1:1.0: USB Mass Storage device detected
[    1.781250] scsi host2: usb-storage 2-1:1.0
[    6.684054] kmodloader: failed to open /tmp/overlay/upper/etc/modules-boot.d/50-usb-uhci
[   10.651904] usbcore: registered new interface driver cdc_wdm
[   10.694412] usbcore: registered new interface driver ums-alauda
[   10.700672] usbcore: registered new interface driver ums-cypress
[   10.707197] usbcore: registered new interface driver ums-datafab
[   10.713700] usbcore: registered new interface driver ums-freecom
[   10.720066] usbcore: registered new interface driver ums-isd200
[   10.726368] usbcore: registered new interface driver ums-jumpshot
[   10.732807] usbcore: registered new interface driver ums-karma
[   10.739034] usbcore: registered new interface driver ums-sddr09
[   10.745334] usbcore: registered new interface driver ums-sddr55
[   10.751650] usbcore: registered new interface driver ums-usbat
[   10.763225] usbcore: registered new interface driver usbserial
[   10.769120] usbcore: registered new interface driver usbserial_generic
[   10.775728] usbserial: USB Serial support registered for generic
[   10.809998] usbcore: registered new interface driver qmi_wwan
[   10.817683] usbcore: registered new interface driver option
[   10.823359] usbserial: USB Serial support registered for GSM modem (1-port)

usbmode -l
Found device: 10a9:6080 (Manufacturer: "Pantech, Incorporated", Product: "PANTECH MHS291LVW", Serial: "PTMHS291LVW20164093")

Can I manually run mknod with the info above?  unfortunately I don't know how to set the minor and major device number

(Last edited by btrv on 6 Jul 2017, 04:13)

Please mention i use M_B_ps, not M_b_ps. Bytes, not bits. It's peak transfer speeds for real files. I cheat a bit at first one - because it's between 1900AC and Buffalo G450h (3x3 mimo, 3x15db antenna, 10m and 3m higher then Linksys).

I tell you before - it's a combination of "noscan 1" and BM (Bermuda) or reghack as a reg zone.

@david, from what I have read elsewhere and my research, those 2 packages should be removed.  The third radio in the 3200ACM (the 88W8887), which is used for radar detection/DFS, is meant to be used silently in the background for this purpose. mwifiex is the driver for the 88W8887 (but not a DFS driver, an AP driver) and not only allows the 88W8887 to be used as an AP, but also messes up DFS in countries except the US because kmod-mwifiex-sdio sets the country code of the 88W8887 to US with no way to change it.  So if someone has a non-US router, this results in an overall country code of 98 (which contains the superset of US regulations and their router's country's regulations, resulting in more channels/power levels being restricted than should be; in addition to causing DFS channels to be unable to be used).

Edit:see below...

Edit2: Clarification/correction on last edit

kmod-mwifiex-sdio is the AP driver for the 88W8887 that is causing problems (by allowing the third radio to be shown and used, and by messing with the country codes for non-US routers causing DFS channels to be unusable) and should be removed.

mwifiex-sdio-firmware I believe should actually be kept, to ensure the 88W8887 works in the background for DFS/radar detection.  Not 100% positive if it is actually required for the 88W8887 to work in the background, but it makes sense since it is the firmware for the 88W8887 and also leaving mwifiex-sdio-firmware won't cause any issues by itself.  Safer to keep it than remove it, since keeping it doesn't cause any issues, and removing it may.

(Last edited by starcms on 6 Jul 2017, 22:49)

I don't think there would be any use for keeping the mwiflex-sdio-firmware package.
If it is like any other firmware package, it requires the kmod-mwiflex-sdio driver to actually load the firmware onto the card.

Good point, I hadn't thought of that. In that case, both packages can be safely removed, but kmod-mwifiex-sdio should definitely be removed. All it does is cause problems by

a) allowing the 88W8887 being used by the user as an AP
b) causing non-US users to be unable to use DFS channels.

Since mwlwifi will only use the country code built into the eeprom, there is no worry about removing the two mwifiex packages from interfering with the legal status/FCC compliance of the router. Actually the mwifiex driver (kmod-mwifiex-sdio) makes the router non-FCC compliant because it doesn't use the country code built into eeprom and allows the country code and therefore the power tables of radio2 to be changed if it is used as an AP.

A new pull request should be made to LEDE to revert the addition of these 2 packages made by the pull request @david linked to which causes both of the mwifiex packages to be included in the official 3200acm LEDE builds.  Because athough @david can remove the packages from his builds, they shouldn't be included in any builds.

Edit:. After thinking about it more, I still feel mwifiex-sdio-firmware should stay included, just to be on the safe side. As I said before, it definitely won't cause any harm. Only kmod-mwifiex-sdio needs to be removed. 

Edit2:  Addition to Edit1: My reason for thinking this is unlike the kmod-mwlwifi driver which includes the driver AND firmware; mwifiex has it's firmware in a separate package than the driver.  So it (the mwifiex firmware, mwifiex-sdio-firmware package) may be able to load itself in the background or have other packages use it without the additional driver package, and if so, it would be being used for DFS...

(Last edited by starcms on 6 Jul 2017, 22:46)

Okay, I think I'm convinced about this, and to start I guess I'll go ahead and remove kmod-mwiflex-sdio.

Question though... Yesterday evening I removed both packages and rebooted then selected a DFS channel. Within an hour the channel was changed to a non DFS channel. Before going to bed, I tried a different DFS channel, but when I got up this morning, the channel had once again changed to non DFS.

So I had a bit of an odd thing happen this morning.... not sure if this is related to what you guys were talking about.

I started working, and BAM wifi just completely stopped working. Ethernet too, as my TV went down too. So I hard-rebooted my router (To remind everyone, I use a 3200acm), and I go in ssh to check the logs (I have the kernel logs written to a file, it never flushes until it gets to a certain size).

When the router froze, I see a chain of crashes that seemed to have happened in succession:

Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.489125] ------------[ cut here ]------------
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.493785] WARNING: CPU: 0 PID: 19536 at compat-wireless-2017-01-31/net/mac80211/rx.c:4224 ieee80211_rx_napi+0x88/0x81c [mac80211]
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.505689] 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_sddrThu Jul  6 08:41:19 2017 kern.warn kernel: [85560.578129]  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 mwifiex_sdio mwifiex 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_mirredThu Jul  6 08:41:19 2017 kern.warn kernel: [85560.682698] CPU: 0 PID: 19536 Comm: kworker/u4:2 Tainted: G        W       4.9.34 #0
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.690470] Hardware name: Marvell Armada 380/385 (Device Tree)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.696421] Workqueue: phy0 mwl_account_handle [mwlwifi]
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.701768] [<c0016010>] (unwind_backtrace) from [<c0012220>] (show_stack+0x10/0x14)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.709544] [<c0012220>] (show_stack) from [<c020fb9c>] (dump_stack+0x7c/0x9c)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.716796] [<c020fb9c>] (dump_stack) from [<c0029214>] (__warn+0xbc/0xec)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.723699] [<c0029214>] (__warn) from [<c00292e8>] (warn_slowpath_null+0x1c/0x24)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.731320] [<c00292e8>] (warn_slowpath_null) from [<bf1ae250>] (ieee80211_rx_napi+0x88/0x81c [mac80211])
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.740957] [<bf1ae250>] (ieee80211_rx_napi [mac80211]) from [<bf20e454>] (pcie_rx_recv_ndp+0x92c/0xa58 [mwlwifi])
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.751357] [<bf20e454>] (pcie_rx_recv_ndp [mwlwifi]) from [<c002daf4>] (tasklet_action+0x8c/0xe8)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.760354] [<c002daf4>] (tasklet_action) from [<c002d28c>] (__do_softirq+0xd0/0x204)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.768217] [<c002d28c>] (__do_softirq) from [<c002d644>] (irq_exit+0x94/0xb8)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.775471] [<c002d644>] (irq_exit) from [<c0061d18>] (__handle_domain_irq+0x90/0xb4)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.783334] [<c0061d18>] (__handle_domain_irq) from [<c0009428>] (gic_handle_irq+0x50/0x94)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.791719] [<c0009428>] (gic_handle_irq) from [<c0012c8c>] (__irq_svc+0x6c/0x90)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.799230] Exception stack(0xd92c3e90 to 0xd92c3ed8)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.804301] 3e80:                                     d4419f94 fffffff0 00000000 00000000
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.812513] 3ea0: dd800988 dd800a7c d4419e6c 00800806 ddfa15c0 ddfa4700 0001ae95 d4419f74
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.820723] 3ec0: 00000000 d92c3ee4 00000000 c020f068 00000013 ffffffff
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.827364] [<c0012c8c>] (__irq_svc) from [<c020f068>] (__memzero+0x48/0x7c)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.834449] [<c020f068>] (__memzero) from [<bf206430>] (pcie_process_account+0x19c/0x380 [mwlwifi])
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.843540] [<bf206430>] (pcie_process_account [mwlwifi]) from [<c003d5a8>] (process_one_work+0x1d4/0x310)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.853233] [<c003d5a8>] (process_one_work) from [<c003e290>] (worker_thread+0x2d8/0x410)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.861445] [<c003e290>] (worker_thread) from [<c00421d0>] (kthread+0xd8/0xec)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.868698] [<c00421d0>] (kthread) from [<c000edf8>] (ret_from_fork+0x14/0x3c)
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.875982] ---[ end trace 0b872fd2e1ddb361 ]---

Could this be related?

I don't believe so.  It appears the mwlwifi driver crashed (so not mwifiex).  In the trace, there are 4 entries mentioning mwlwifi:

Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.740957] [<bf1ae250>] (ieee80211_rx_napi [mac80211]) from [<bf20e454>] (pcie_rx_recv_ndp+0x92c/0xa58 [mwlwifi])
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.751357] [<bf20e454>] (pcie_rx_recv_ndp [mwlwifi]) from [<c002daf4>] (tasklet_action+0x8c/0xe8)

and

Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.834449] [<c020f068>] (__memzero) from [<bf206430>] (pcie_process_account+0x19c/0x380 [mwlwifi])
Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.843540] [<bf206430>] (pcie_process_account [mwlwifi]) from [<c003d5a8>] (process_one_work+0x1d4/0x310)

at the very bottom of the trace, meaning this is what initiated the crash.

I see memzero in the third of those four.  The memory issue with the 3200ACM had been corrected a few months ago correct?

Edit: And just noticed

Thu Jul  6 08:41:19 2017 kern.warn kernel: [85560.696421] Workqueue: phy0 mwl_account_handle [mwlwifi]

at the very top of the trace.  So looks like your 5GHz AP caused the crash. Possibly due to running out of memory (speculation, I'm not a kernel expert).   It could have been a one time, all the stars align, crash.  I'd wait and see if it ever happens again.  If so, you could open an issue in the mwlwifi github.  But definitely nothing to do with mwifiex.

(Last edited by starcms on 6 Jul 2017, 22:49)

I know this is the behavior of the 1200/1900 models; but on the 3200, the DFS normally works better and stays on the DFS channel, correct?  Basically, is this different behavior than you observed on DFS channels before removing the two mwifiex packages?

I'm assuming there were log entries about radar being detected?

Edit: Please see the underlined Edit2 that I just added in my prior post related to this (post# 2544). Try keeping mwifiex-sdio-firmware installed if you are seeing different behavior with both mwifiex packages removed.

(Last edited by starcms on 6 Jul 2017, 22:47)

Will do some testing.

Still testing but have some results

With both packages removed it took about 30 minutes to switch off of DFS channel from channel 139.

[ 80.585289] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0-1: link becomes ready
[  160.019769] ieee80211 phy0: staid 3 deleted
[ 3412.680807] ieee80211 phy0: radar detected by firmware
[ 3412.878023] ieee80211 phy0: staid 6 deleted
[ 3413.254481] ieee80211 phy0: channel switch is done
[ 3413.259310] ieee80211 phy0: change: 0x40

Installed mwifiex-sdio-firmware and rebooted.
Switched to channel 108 and within 30 minutes it switched to channel 132 (DFS).

[ 6047.874355] ieee80211 phy0: staid 2 deleted
[ 6298.348653] ieee80211 phy0: radar detected by firmware
[ 6298.884522] ieee80211 phy0: channel switch is done
[ 6298.889383] ieee80211 phy0: change: 0x40

So, will leave it like it is and see if it stays on this DFS channel or moves again.