Just uploaded the latest wifi driver to the server.  This driver will be for people who are using r5501.

The last 2 changes were.

1. Change driver version to 10.3.4.0-20171214
2. Modified the code to get correct region code

https://davidc502sis.dynamic-dns.net/re … _vfpv3.ipk

When using 160Mhz width, this is what I'm finding in the logs. My wife who works from home is finding some intermittent issues with wifi on this setting. I've asked her to start telling me exactly when it happens and see if it correlates to the logs below. The issue I see is that 160mhz over laps with I want to say 40mhz of DFS spectrum, and when radar is detected, the below log is created.

Sat Dec 16 08:52:50 2017 kern.info kernel: [45274.343332] ieee80211 phy0: radar detected by firmware
Sat Dec 16 08:52:50 2017 daemon.notice hostapd: wlan0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0
Sat Dec 16 08:52:50 2017 daemon.notice hostapd: hostapd_dfs_start_channel_switch: no DFS channels left, waiting for NOP to finish
Sat Dec 16 08:52:50 2017 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0

*EDIT*
In the last 20 minutes I've seen it bounce to 2 different channels... Of course no matter what channel it chooses there will be some or all DFS spectrum. The issue I've had since the V1 is that radar is detected no matter the DFS channel selected, so I imagine it's going to bounce around changing channels all day.  That's probably the intermittent issue my wife is experiencing.

(Last edited by davidc502 on 16 Dec 2017, 16:10)

Also, I'm going to try and fire up a kernel 4.4 build and see if it has been fixed for V1 owners.

I'm still dealing with 160mhz width for supposed "Tri-band" configuration. Which I think is a bit of a misnomer, but that's a different story, and maybe someone can set me straight on the understanding of Tri-band.

What I'm dealing with is when 5Ghz is set to 160mhz width, radar is being detected, and bouncing radio0 to another channel. Each time this happens, the interface has to listen to the new channel before bringing the interface up, leaving users on 5ghz to wait until radio0 comes back up.

So, this is what I'm seeing so far. So, we can see about every 10 minutes or so radio0 is going to go down.

root@lede:~# logread |grep radar
Sat Dec 16 09:54:22 2017 kern.info kernel: [48965.800300] ieee80211 phy0: radar detected by firmware
Sat Dec 16 10:02:31 2017 kern.info kernel: [49454.854448] ieee80211 phy0: radar detected by firmware
Sat Dec 16 10:04:16 2017 kern.info kernel: [49559.462863] ieee80211 phy0: radar detected by firmware
Sat Dec 16 10:14:10 2017 kern.info kernel: [50153.973799] ieee80211 phy0: radar detected by firmware
Sat Dec 16 10:17:32 2017 kern.info kernel: [50355.941844] ieee80211 phy0: radar detected by firmware
Sat Dec 16 10:21:06 2017 kern.info kernel: [50569.691390] ieee80211 phy0: radar detected by firmware
Sat Dec 16 10:31:26 2017 kern.info kernel: [51189.789628] ieee80211 phy0: radar detected by firmware

I created a crontab entry that will check for the current wifi channel, time, and log it to USB stick. After thinking about it, I believe I'll add the last radar detected line from logread.

Basically, what this all boils down to is, if what I'm seeing is the expected behavior of 5ghz using 160mhz width. So, the logs will be captured, and I'll email yuhhaurlin with the evidence and see what he says. Going back to the V1 days, many of us have been concerned with radar detection, and have felt it may be just looking for spurious transmissions instead of the outlined and documented radar signaling patterns.

*edit
Cron setting just in case.
0,10,20,30,40,50 * * * *  date >> /mnt/usb/160mhz_log.txt ; iwinfo radio0 info |grep Channel: |awk '{print $3,$4,$5,$6}' >> /mnt/usb/160mhz_log.txt ; dmesg |grep radar | tail -1 >> /mnt/usb/160mhz_log.txt ; echo "" >> /mnt/usb/160mhz_log.txt

(Last edited by davidc502 on 16 Dec 2017, 19:48)

@WWTK

Any changes or is it stable now?

the tri-band comes from the other radio you don't have   two 5ghz bands and one 2.4.  Otherwise you'd not have an ac3200 router imho

edit:

The radio is up and still broadcasting an SSID thats about all I can really say at this point

edit2:

welll........

Sat Dec 16 13:17:39 2017 kern.info kernel: [ 2293.058294] mwifiex_sdio mmc0:0001:1: radar detected; indicating kernel
Sat Dec 16 13:17:39 2017 kern.info kernel: [ 2293.064948] mwifiex_sdio mmc0:0001:1: cancelling CAC
Sat Dec 16 13:17:51 2017 kern.info kernel: [ 2305.100492] mwifiex_sdio mmc0:0001:1: cmd_wait_q terminated: -110
Sat Dec 16 13:17:51 2017 kern.info kernel: [ 2305.106621] mwifiex_sdio mmc0:0001:1: Failed to stop CAC in FW
Sat Dec 16 13:17:51 2017 kern.info kernel: [ 2305.112508] mwifiex_sdio mmc0:0001:1: regdomain: 0
Sat Dec 16 13:17:51 2017 kern.info kernel: [ 2305.117318] mwifiex_sdio mmc0:0001:1: radar detection type: 0
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5260 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: DFS-RADAR-DETECTED freq=5260 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: DFS-NEW-CHANNEL freq=5180 chan=36 sec_chan=1
Sat Dec 16 13:17:51 2017 daemon.err hostapd: nl80211: Too many CSA counters provided
Sat Dec 16 13:17:51 2017 daemon.warn hostapd: DFS failed to schedule CSA (-22) - trying fallback
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: AP-DISABLED
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5260 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: nl80211: deinit ifname=wlan2 disabled_11b_rates=0
Sat Dec 16 13:17:51 2017 daemon.notice netifd: Network device 'wlan2' link is down
Sat Dec 16 13:17:51 2017 daemon.notice netifd: Interface 'wlan1' has link connectivity loss
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: interface state ENABLED->DISABLED
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: interface state DISABLED->COUNTRY_UPDATE
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: interface state COUNTRY_UPDATE->HT_SCAN
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: DFS-RADAR-DETECTED freq=5260 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0
Sat Dec 16 13:17:51 2017 kern.info kernel: [ 2305.206047] IPv6: ADDRCONF(NETDEV_UP): wlan2: link is not ready
Sat Dec 16 13:17:51 2017 daemon.err hostapd: Using interface wlan2 with hwaddr 60:38:e0:b7:b5:4b and ssid "test5g"
Sat Dec 16 13:17:51 2017 daemon.notice netifd: Network device 'wlan2' link is up
Sat Dec 16 13:17:51 2017 daemon.notice netifd: Interface 'wlan1' has link connectivity
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: interface state HT_SCAN->ENABLED
Sat Dec 16 13:17:51 2017 daemon.notice hostapd: wlan2: AP-ENABLED
Sat Dec 16 13:17:51 2017 kern.info kernel: [ 2305.688187] IPv6: ADDRCONF(NETDEV_CHANGE): wlan2: link becomes ready
Sat Dec 16 13:20:31 2017 daemon.info hostapd: wlan2: STA 00:e0:4c:14:ea:60 IEEE 802.11: associated
Sat Dec 16 13:20:31 2017 daemon.notice hostapd: wlan2: AP-STA-CONNECTED 00:e0:4c:14:ea:60
Sat Dec 16 13:20:31 2017 daemon.info hostapd: wlan2: STA 00:e0:4c:14:ea:60 RADIUS: starting accounting session 4B2FB282A2837ED1
Sat Dec 16 13:20:31 2017 daemon.info hostapd: wlan2: STA 00:e0:4c:14:ea:60 WPA: pairwise key handshake completed (RSN)
Sat Dec 16 13:21:54 2017 daemon.info hostapd: wlan2: STA 00:e0:4c:14:ea:60 IEEE 802.11: disassociated
Sat Dec 16 13:21:54 2017 daemon.notice hostapd: wlan2: AP-STA-DISCONNECTED 00:e0:4c:14:ea:60
Sat Dec 16 13:22:16 2017 daemon.notice netifd: Interface 'wlan1' is now down
Sat Dec 16 13:22:16 2017 daemon.notice netifd: Interface 'wlan1' is disabled
Sat Dec 16 13:22:16 2017 daemon.notice netifd: Interface 'wlan1' has link connectivity loss

when this happened I lost 5ghz completely on both radios

(Last edited by WWTK on 16 Dec 2017, 19:33)

@davidc502 It would be awesome to have an script to change again to the previous selected DFS channel when a radar is detected after the cooltime...

And it will be nicer (but I think it's not possible) to force the 5GHz clients to 2.4GHz to have the minimal disruption when a radar is detected...

It is interesting that shortly after the cron job was put into place, mwlwifi settled down on channel 36, and has not moved since.  Will continue to monitor though. Also, I need a Android app that will show 160mhz width as currently 80mhz is the most I've seen.

If the 2.4Ghz SSID is available to the wifi devices it will automatically switch to 2.4 when 5Ghz goes down, however will stay there when 5Ghz comes back on-line. I think hostapd makes the decision on which channel to switch to, and I don't know if it can be manipulated.

Bad news for V1 owners, the build process for kernel 4.4 dies at the same point as before... Something about image-armada-388-clearfog-pro.dtb failed. I'll continue to look at the possibilities.

My immediate recommendation would be to buy a new/used or refurbished 1900acs or 3200acm. Good deals can be had on ebay, but you have to stay patient and snipe the deal at the closing seconds. That may not be an option for everyone, and highly recommend pushing the LEDE developers to fix the issue, so your unit is not left behind.

Also, though it doesn't work for everyone, try disabling IPV6 as others have suggesting in previous posts and see if it works for your unit. The idea has come up to disable certain modules in the V1 which will lead to a hotter running unit. I'm hesitant of doing so because as a previous V1 owner I remember how hot that unit used to get, and creating more heat on the cpu may not be good in the long run. However, this issue is still active, and there may be other solutions yet to be put on the table that will fix this issue once and for all, so all hope is not lost.

I appreciate all the comments, and though I can't respond to everyone, as usual, I appreciate other contributors, in this thread, who step up and answer questions every day of the week.

Best Regards,

@davidc

thats a target device, did something get hosed in your .config ???

A thread regarding the 4.4 build issue where folks can made their voice heard. Has a link to the fix, such that it is, probably easier at this point to try the patch from the reboot thread.

(Last edited by Villeneuve on 16 Dec 2017, 22:32)

ahhh i see what a pita

Tried v5501 without disabling WAN IPV6 got a reboot at about 7min35sec.
Tried v5501 disabling WAN IPV6 got a reboot at about 9min55sec.

Read up on Villeneuve's thread and patch link above but I'm somewhat hesitant to turn my WRT1900AC V1 into a 'pilaf rice cooker'    although that may be scrumptious for a day.... by disabling cooling options...

At this point I somewhat lack confidence about it being an IPV6 issue...but looks to be cpu idle driver related as suggested by Villeneuve's links... we'll see how this develops going forward.

Cheers

Hans

When I patched, is the following output normal??

davidc502@pc2:~/Desktop/lede-build/lede/target/linux/mvebu$ patch < 4.9.patch
patching file config-4.9
Hunk #4 FAILED at 85.
Hunk #8 succeeded at 423 with fuzz 2.
1 out of 9 hunks FAILED -- saving rejects to file config-4.9.rej

This is in the .rej

--- config-4.9
+++ config-4.9
@@ -85,27 +90,23 @@ CONFIG_CPU_CACHE_VIPT=y
 CONFIG_CPU_COPY_V6=y
 CONFIG_CPU_CP15=y
 CONFIG_CPU_CP15_MMU=y
-CONFIG_CPU_FREQ=y
-CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+# CONFIG_CPU_FREQ is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
 # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
-CONFIG_CPU_FREQ_GOV_ATTR_SET=y
-CONFIG_CPU_FREQ_GOV_COMMON=y
-# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
-CONFIG_CPU_FREQ_GOV_ONDEMAND=y
-CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
-# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
-# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
-CONFIG_CPU_FREQ_STAT=y
+# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
+# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
 CONFIG_CPU_HAS_ASID=y
  # CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
 # CONFIG_CPU_ICACHE_DISABLE is not set
-CONFIG_CPU_IDLE=y
-CONFIG_CPU_IDLE_GOV_LADDER=y
+# CONFIG_CPU_IDLE is not set
+# CONFIG_CPU_IDLE_GOV_MENU is not set
+# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
+# CONFIG_CPU_NO_EFFICIENT_FFS is not set
 CONFIG_CPU_PABRT_V7=y
 CONFIG_CPU_PJ4B=y
-CONFIG_CPU_PM=y
 CONFIG_CPU_RMAP=y
-CONFIG_CPU_THERMAL=y
 CONFIG_CPU_TLB_V7=y
 CONFIG_CPU_V7=y
 CONFIG_CRC16=y

(Last edited by davidc502 on 17 Dec 2017, 01:30)

Are the channels limited to either channel 50 or channel 114 with the 160Mhz bandwidth? https://en.wikipedia.org/wiki/List_of_WLAN_channels

Just curious because I don't even have any ac devices to test with my WRT1200AC.

David, disabling IPv6 doesn't help with reboot issue, i check it before. Instead, some guys report you need to enable it and have IP assigned!

I saw the 3200acm bounce between channel 32 and 112, and that doesn't seem to coincide with what wikipedia has documented. However, I'm not sure if the advertised channel really matters as long as it is somewhere in the 160mhz spectrum.

Currently it's sitting on channel 36 and has stayed there for hours now. What I'd like to have is a wifi analyzer which can verify the width is actually 160mhz.

Wow, so there are some who enable IPV6 and have a IP assigned to stop the reboots?  Talk about consistency....

Well, I've patched, though I'm not sure what all it does or doesn't do, and is in the process of building kernel 4.9 for V1 hardware. It will be interesting to see if it actually completes, and then if it does complete what people are going to say about if it works or not.

4.9 always rebooted for me and i'm assigned an ipv6 address from comcast.

If you used that patch set above for mamba and 4.9, consider posting the disclaimer by NainKult (see link to the post)

https://forum.lede-project.org/t/wrt190 … 9/2025/143

(Last edited by grunt on 17 Dec 2017, 06:53)

What has it to do with Kernel 4.4/4.9? Please follow this thread: https://forum.lede-project.org/t/wrt190 … ernel-4-9/

It is obvious, that the issue of most reboots (doesnt matter what model to me) is related to CPUIDLE and CPUFREQ scaling, which seems not to work properly for ANY Armada/XP CPU. You can see evidence for this going back several years on mailing lists for OpenWRT ( https://gitlab.labs.nic.cz/turris/openw … 2519a07932 )

It seems to me, it is still bugged, even on Kernel 4.9. Therefor, you should give a 2nd (test) image for people having reboot issues, where you disable all CPUIDLE and power save mechanisms of the CPU ( https://gist.github.com/NainKult/1b0603 … 94e1ce7203 ).

(Last edited by makedir on 17 Dec 2017, 13:15)

@makedir   I don't find it obvious at all, my 1900acs and 3200acm have never rebooted, not once.

I feel there are multiple issues at play.

@davidc502
I am using a Linksys WRT1900ac v1 Mamba and am testing two other builds that have the CPUIDLE and power save mechanisms of the CPU disabled. (for the firmware view the previous comment from makedir)

I can confirm that I no longer experience spontaneous reboots.
The processor gets slightly hotter "5 degrees" with the power save mechanisms disabled.

With davidc502 kernel 4.9 builds the rebooting with a active IPv6 connection was still there but was less common.

Router: WRT1900ac v1
Firmware tested: OpenWrt (Linux 4.9.67)
Firmware tested: LEDE (Linux 4.9.65) (current)
Status: REBOOTING in both firmware versions is resolved.

(Last edited by racef@ce on 17 Dec 2017, 16:21)

Interesting comment from the LEDE thread:
https://forum.lede-project.org/t/wrt190 … 9/2025/151

"sludgepump22h
Hi and thanks to everyone for trying to sort this out.
Here is some additional data points from my side:

Environment: WRT-1900AC V1 (mamba)

Have been attempting to run various kernel 4.9 releases for many months. All releases ultimately fail with a reboot within 48 hours. No error logging occurs at the time of the reboot. The router is not heavily loaded.
Kernel version 4.4 has run rock solid on same WRT1900ACv1 for many months without errors.
I compiled new kernel 4.9.65 last week with “CPU IDLE” and “CPUFREQ SCALING” both disabled in kernel config. Router has been now running for over 8 days now without reboots or errors.
Today I have recompiled a new kernel with “CPUFREQ SCALING” re-enabled and left CPU_IDLE still disabled in kernel config. Will test for one week to see the results. I will report back.
Based on some anecdotal evidence, I’m speculating that the problem may arise when the CPU is coming out of an IDLE state. On a couple of occasions my router was pretty much idle when I logged into LUCI. As soon as LUCI started, the router rebooted.
The Marvell doc shows the Armada XP CPU has 3 possible states (IDLE, DEEP IDLE, and SLEEP) Each progressive state is more power efficient but will take longer to restart. I’m not sure which state we are actually using in this 4.9 kernel. Maybe someone could give us some insight how this all works.
Thanks much."

It would appear that the reboot bug has some considerable issue COMING OUT OF CPU IDLE STATE according to the LEDE thread...   :0

pilaf rice cooker, surely this is the season of the Instant Pot, 9 in 1 do it all, put in one cup of water and 8 minutes later pull out a perfectly done venomous snake.

@davidc502, I assume you sorted the issue, not sure how you are managing things but you might be interested in git worktree, looks interesting at least but have not tried it yet myself.

Quite interesting, thank you.
BTW, this explains why active IPv6 stop reboots as well.

@david, can you please make a 4.9 build for 1900ac with all idle/freq disabled for testing?

(Last edited by T-Troll on 18 Dec 2017, 04:53)