DFS not working (properly) 5ghz reverts to channel 36

[Razerwire]

Dynamic Frequency Selection was added with commit 99d3879cc72f2a25d44fb4bee96fd84eca028b04

Several users reported in issue #57 that DFS was not working properly and that the router's radio was always reverting to channel 36, regardless of there actually being RADAR or not. @yuhhaurlin closed the issue (#57) for a lack of response.

DFS support is currently still not working like it should on OpenWRT.

Running DD Bleeding Edge, R49195, (which includes the latest driver and firmware) after some time (a day or so) the wireless radio will switch to channel 36 even though the router is no where near a airport and/or a RADAR installation.

Would be great if this was fixed...

[anazz20]

Ah, so this is why my 1900AC and 1200AC keeps doing exactly that with DD-WRT using the .16 and .17 drivers. I thought I was losing my mind.

A fix would be nice!

[johnnysl]

Already reported my issues with it in the previous (now closed) topic. Have the same issue.

[yuhhaurlin]

I will check QA to verify if radar detection of FW is all right.

[yuhhaurlin]

Firmware used by mwlwifi driver is the same as stock firmware. Can you check if you will encounter the same issue with stock firmware. It is very hard for me to know if radar signal is around your environment or not.

[anazz20]

I can try the stock in the next few days, unless someone else does it first. On a side note, I have Dish Networks Hopper DVR with wireless Joeys, the access point of it can and does use DFS channels and hardly ever changes channels, I used WiFi Analyzer to monitor it. That is what made me scratch my head as to why the WRT1900AC and the 1200AC would act like that.. Not sure if that helps or not.

[yuhhaurlin]

The detection is reported from firmware. Driver needs to configure it. If stock firmware is all right, I will check the code to configure firmware.

[anazz20]

I tried today, I flashed the newest (albeit almost a year old) stock firmware on both my 1200AC and 1900AC, and neither would even give me an option for any DFS channels to select. I thought it may be a bad flash, so I tried it three times on each router, changing the cable, port, no windows firewall or anti-virus or anything running.

After I gave up, I put Kong's 5/26 build on, and it gave me the DFS channels, was able to keep it on channel 100 and it did not switch to 36.

[Razerwire]

After I gave up, I put Kong's 5/26 build on, and it gave me the DFS channels, was able to keep it on channel 100 and it did not switch to 36.

It takes a while for the radio to switch to channel 36 give it a day, maybe two.

[yuhhaurlin]

It is very hard for me to tell if the detection is correct or not. Once if radar detection is reported, channel must be switched.

[Razerwire]

It is very hard for me to tell if the detection is correct or not. Once if radar detection is reported, channel must be switched.

@yuhhaurlin I live in the middle of a city with 150.000+ inhabitants the nearest airport is more than 75 miles away, so in my case the detections are definitely false.

Furthermore, (if i'm correct) the router's radio scans for radar when booting (initializing) and/or when first transmitting on a channel. Radar is never detect on boot or when setting a channel for the first time, it always takes time for the problem to occur. I haven't timed it but I think it takes more then 6 hours for radar detection to occur. To me it seems that if RADAR is really present it would be detected when the router starts or when i set a channel but it never does it always takes a lot of time for the channel to switch.

And is it normal for the radio to switch to channel 36 when RADAR is detected shouldn't it just switch to the next available channel instead of channel 36 (which is crowded). So that (for instance) when i'm using channel 126 and RADAR is detected it switches to channel 116.

Also i think when RADAR is detected it is impossible to set any DFS channels until the router is rebooted

Is there anything i can do to help out with this problem, I really need DFS since channel 36 is really crowded.

[yuhhaurlin]

Hostapd decides the channel to switch. NOL is 30 minutes. I wonder if it is possible for you to set different channels in DFS channel range or another non-DFS channel.

[Razerwire]

I wonder if it is possible for you to set different channels in DFS channel range or another non-DFS channel. @yuhhaurlin You mean before or after RADAR is (falsely) detected?

[yuhhaurlin]

Either way. After radar detection, it needs 30 minutes to reuse the channel. I suggest this way to allow you to check if you can get a channel without radar signal detected.

[Razerwire]

@yuhhaurlin I'll look into it and report back

[Razerwire]

So yesterday i set the channel to 120 and last night, RADAR was detected again and the channel was switched to 36: ............................................................................................................................

`Sun May 29 00:23:23 2016 daemon.info hostapd: wlan0: STA xxxxxxxxxxxc WPA: group key handshake completed (RSN)

Sun May 29 00:23:23 2016 daemon.info hostapd: wlan0: STA xxxxxxxxxxxxaf WPA: group key handshake completed (RSN)

Sun May 29 00:25:00 2016 cron.info crond[1092]: USER root pid 11209 cmd /sbin/fan_ctrl.sh

Sun May 29 00:27:47 2016 daemon.info hostapd: wlan1: STA xxxxxxxxxb WPA: group key handshake completed (RSN)

Sun May 29 00:30:00 2016 cron.info crond[1092]: USER root pid 11215 cmd /sbin/fan_ctrl.sh

Sun May 29 00:32:44 2016 kern.info kernel: [30464.194391] ieee80211 phy0: radar detected by firmware

Sun May 29 00:32:45 2016 kern.info kernel: [30464.815241] ieee80211 phy0: channel switch is done

Sun May 29 00:32:45 2016 kern.debug kernel: [30464.820062] ieee80211 phy0: change: 0x60

Sun May 29 00:32:45 2016 daemon.info hostapd: wlan0: IEEE 802.11 driver had channel switch: freq=5180, ht=1, offset=1, width=3 (80 MHz), cf1=5210, cf2=0`

So this morning i tried to switch to channel 60, which works, temporarily because then (after about ten minutes) the radio detects RADAR on channel 60 and switches to channel 36 again: ........................................................................................................................................... Sun May 29 11:08:42 2016 daemon.notice netifd: radio0 (12165): wlan0: interface state HT_SCAN->DFS Sun May 29 11:08:42 2016 daemon.notice netifd: radio0 (12165): wlan0: DFS-CAC-START freq=5300 chan=60 sec_chan=1, width=1, seg0=58, seg1=0, cac_time=60s Sun May 29 11:09:42 2016 daemon.notice netifd: radio0 (12165): wlan0: DFS-CAC-COMPLETED success=1 freq=5300 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5290 cf2=0 Sun May 29 11:09:42 2016 daemon.notice netifd: radio0 (12165): Using interface wlan0 with hwaddr xxxxxxxxxxxxxxxxxx and ssid "Sxxxxxxxxxxxxxxxh" Sun May 29 11:09:43 2016 daemon.notice netifd: radio0 (12165): wlan0: interface state DFS->ENABLED Sun May 29 11:09:43 2016 daemon.notice netifd: radio0 (12165): wlan0: AP-ENABLED Sun May 29 11:09:43 2016 daemon.notice netifd: Network device 'wlan0' link is up ........... Sun May 29 11:17:46 2016 kern.info kernel: [69165.776308] ieee80211 phy0: radar detected by firmware Sun May 29 11:17:47 2016 kern.info kernel: [69166.320964] ieee80211 phy0: channel switch is done Sun May 29 11:17:47 2016 kern.debug kernel: [69166.325795] ieee80211 phy0: change: 0x40 Sun May 29 11:17:47 2016 daemon.info hostapd: wlan0: IEEE 802.11 driver had channel switch: freq=5180, ht=1, offset=1, width=3 (80 MHz), cf1=5210, cf2=0

So i set channel 100 as the WiFi channel, which works, for about one minute because then RADAR is detected on channel 100 and the radio switches to channel 36 again: .............................................................................................................. Sun May 29 11:39:29 2016 daemon.notice netifd: radio0 (12979): wlan0: DFS-CAC-COMPLETED success=0 freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0 Sun May 29 11:39:29 2016 daemon.notice netifd: radio0 (12979): wlan0: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0 Sun May 29 11:39:29 2016 daemon.notice netifd: radio0 (12979): wlan0: DFS-NEW-CHANNEL freq=5580 chan=116 sec_chan=1 Sun May 29 11:39:29 2016 daemon.notice netifd: radio0 (12979): wlan0: interface state DFS->DFS Sun May 29 11:39:29 2016 daemon.notice netifd: radio0 (12979): wlan0: DFS-CAC-START freq=5580 chan=116 sec_chan=1, width=1, seg0=122, seg1=0, cac_time=60s ........... Sun May 29 11:40:30 2016 daemon.notice netifd: radio0 (12979): wlan0: DFS-CAC-COMPLETED success=1 freq=5580 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5610 cf2=0 Sun May 29 11:40:30 2016 daemon.notice netifd: radio0 (12979): Using interface wlan0 with hwaddr xxxxxxxxxxxxx and ssid "xxxxxxxxxxxxx" Sun May 29 11:40:51 2016 kern.info kernel: [70550.610215] ieee80211 phy0: radar detected by firmware Sun May 29 11:40:52 2016 kern.info kernel: [70551.175100] ieee80211 phy0: channel switch is done Sun May 29 11:40:52 2016 kern.debug kernel: [70551.179935] ieee80211 phy0: change: 0x40 Sun May 29 11:40:52 2016 daemon.info hostapd: wlan0: IEEE 802.11 driver had channel switch: freq=5180, ht=1, offset=1, width=3 (80 MHz), cf1=5210, cf2=0 ................................................................................................

So then i switch to channel 116 (which actually gives me channel 52(?) ). Anyhow channel 52 works for about 13 minutes before RADAR is detected again and the channel is switched to 36 again.

So in short the radio seems to detect RADAR on virtually every channel and then switches to channel 36, RADAR detection is definitely broken.

To add to that: yesterday, I setup my Netgear R7000, running DD-WRT, on channel 120, i set 802.11h to strict and it never detected any RADAR signal

P.S. Problem might not appear in the first hours after a router boot or reboot

[johnnysl]

@yuhhaurlin: could it be a bug based on region settings? not sure what region you use to test the code? region NL surely shows the issue with me. The fact that i have neighbours using provider supplied and maintained 5GHZ routers in the same frequency ranges without issue is another clear sign to me that something goes wrong in the current firmware.

[verbit]

I also experienced that my WRT1200AC was very unstable on the higher channels (DFS channels), even with the newest drivers. However, I did not investigate it further. I gave it up altogether in the end, since the lower channels here are free enough.

@Razerwire findings might explain my problems.

[yuhhaurlin]

Thanks. I will check it.

[anazz20]

@Razerwire You were right, got home and it had switched back to 36 and stayed there, but it lasted a lot longer (used to be maybe 2-10 minutes) than when I was using Kong's 3/2 build. Not sure what driver/firmware version that was.

[anazz20]

After some more investigating, I recorded Acrylic WiFi for a week. My Dish Network AP reboots around 1 a.m., selects a DFS channel, within 24 hours it switches to any non-DFS 80MHz channels. I racked my brain, and remembered we have a university here, and they have a doppler radar unit. I think that may be the reason my WRT1200 and WRT1900 don't stay on a DFS channel, just wonder why it selects 36 each time.

[yuhhaurlin]

@anazz20 Hostapd selects channel after radar detection.

[adri-k]

@yuhhaurlin

I have exactly the same problem and like @johnnysl I get radar detected on virtually every DFS channel, even though other provider maintained and supplied router are happily using DFS enabled channels, which I can't use on a WRT1900ACS using driver 10.3.0.18-20160823-1 with firmware version 0x702091a with the country set to 'NL' (ETSI regulations). When I want to use a DFS enabled channel between 52-64 or 100-136, the driver either uses a completely different channel or I get a 'ieee80211 phy0: radar detected by firmware' error between a few minutes to a few hours afterwards. I also have an old NetGear WNDR3700v1, which has DFS enabled with OpenWRT CC 15.05.01 and this will occasionally detect radar on a few channels, but most are usable without any problems. Even when I use the same channel as a nearby AP from a know cable company, the mwlwifi firmware detects radar quickly and refuses to use the channel, while the cable company provided and maintained AP happily continues to use the channel! Maybe the mwlwifi driver is just too sensitive and decides radar is detected without it actually being a strong radar signal, but just interference?

I understand the issue is difficult to analyze or reproduce in a different environment. Perhaps you could modify the firmware and driver to print more debug information when radar is detected, to help you identify the problem?

[davidc502]

I would also ask this be looked at as it doesn't matter what DFS channel I choose, it always reverts to one end of the spectrum or another within a few hours. What I mean by one end of the spectrum or another is it either goes to 36 or 157 depending on which DFS channel is closest.

[yuhhaurlin]

Which channel to switch is not decided by driver.

[davidc502]

yuhhaurlin,

First let me say, thank you for responding.

The actually issue is that 5Ghz wifi never stays on a DFS channel any longer than a few hours.

It's 'almost' like any spurious transmission, on the frequency it is listening, will make it change to another channel off of DFS.

[toyotabedzrock]

It really sounds like the driver is seeing other devices on dfs channels as radar devices. It would be nice if there was a map of areas that users shouldn't expect to be able to use dfs channels.

[bmork]

@yuhhaurlin Did your investigation of the stock firmwre DFS configuration lead to anything interesting? I see that the DFS enable request to the firmware includes quite a number of parameters, which mostly are set unconditionally to hardcoded values in main.c. Comparing them to these stock firmware settings would be most usefull.

I tried to guess the meaning of the settings, but this is hard without seeing the firmware code or having any documentation. What is the unit of dfs_chirp_time_interval for example? It makes a bit of difference if it is given in ms or µs :) And what are all the different "counts"? There seem to be 3 of them? They surely can't all be a count of radar pulses... And the "pw_filter", is that useful for something? Is it a boolean, or are can different filters be selected?

But even without having this info, I find it a bit surprising that all these values are set independently of the DFS region. Only radar_type_code changes. I've tried to match that up with for example https://mentor.ieee.org/802.11/dcn/09/11-09-1217-00-0reg-dfs-criteria-whitepaper.pdf and I just cannot get it to make sense. How come the interval and pulse numbers are the same for all DFS regions? I'd expect them to vary. And if that is all coded into the firmware based on the radar_type_code, then what's the point of sendng the other parameters to the firmware at all?

FWIW, I am also in the ETSI region and am having the same problems as everyone else here: The firmware will detect a radar within a few hours of operation, regardless of which DFS channel I try, making the DFS channels useless in practice. I can of course not say for sure that there are no radars in my neighbourhood, but I have the same sort of indication others have reported: Several of my neighbours seem to be happily using DFS channels on assorted closed source access points. So I strongly suspect the detected "radar" is a false positive.

[thagabe]

I can concur, I live in the suburbs where there are only a few people on 5 GHz. When I select >120 it detects a radio and will autoselect 120. I live ~7 miles from an airport and my isp's router does not change dfs channels

[adri-k]

@yuhhaurlin

Did you make any progress on this issue?

The 88W8864 chipset and the Linksys WRT1x00 routers are advertized and sold as being DFS compliant. The current firmware seems to be overly sensitive and obviously isn't DFS compliant since DFS enable channels are completely unusable. I would like to see this issue get some attention or feedback, since without DFS enabled channels, the router is restricted to only a few usable channels, which are becoming crowded with other neighbourhood AC routers all wanting 80 or 160 Mhz bandwidth.

[adri-k]

@yuhhaurlin

Looking at the other DFS implementation, not all noise is considered a radar signal. Radar is identified by a combination of pulse width, pulse amplitude, pulse frequency spread and number of pulses per interval, see https://wireless.wiki.kernel.org/en/developers/dfs for examples. Any signal not falling into one of the possible radar categories, which can be different for every regulatory domain, is ignored. The opensource ath9k driver implements this using a FFT transformation of a number of samples, see https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ath/ath9k/dfs.c.

Does the 8W8864 firmware use a similar approach and does it handle the different radar definitions for each regulatory domain?

[davidc502]

Just an Observation -- The 3200ACM doesn't seem to have the issue with DFS like the 1900 series. Since I'm a good distance from any airport, I assume the 3200 is working correctly.

[adri-k]

@davidc502 @yuhhaurlin

Nice to hear the 3200ACM has a better working DFS implementation. I hope we can see the improved DFS backported to the WRT1x00 series soon. I still can't properly use my WRT1900ACS, being restricted to channel 36-48!

[harrylwc]

Wrt1200ac v2 dfs channel not working on lede with latest driver(0110) .No problem with 0531 openwrt cc build.

Dfs channel still not working with new driver(https://github.com/mrvltest/mwlwifi/). Here is android client log.

<6>[74267.253600] wlan: disconnected <6>[74267.253692] wlan(0) 00:00:00:00:00:00 Standalone <3>[74267.253905] wlan: [28357:E :SME] sme_8023MulticastList: Unable to find the right session <6>[74267.255645] cfg80211: Calling CRDA to update world regulatory domain <3>[74267.450011] wlan: [28357:E :SME] Invalid center channel (102), disable 40MHz mode <6>[74267.461852] wlan_hdd_cfg80211_reg_notifier: updating country code to 00 <6>[74267.462035] cfg80211: World regulatory domain updated: <6>[74267.462218] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) <6>[74267.462310] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) <6>[74267.462493] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm) <6>[74267.462645] cfg80211: (4910000 KHz - 4930000 KHz @ 10000 KHz), (N/A, 2300 mBm) <6>[74267.462737] cfg80211: (4910000 KHz - 4990000 KHz @ 40000 KHz), (N/A, 2300 mBm) <6>[74267.462890] cfg80211: (4930000 KHz - 4950000 KHz @ 10000 KHz), (N/A, 2300 mBm) <6>[74267.463042] cfg80211: (5030000 KHz - 5045000 KHz @ 10000 KHz), (N/A, 2300 mBm) <6>[74267.463134] cfg80211: (5030000 KHz - 5090000 KHz @ 40000 KHz), (N/A, 2300 mBm) <6>[74267.463378] cfg80211: (5050000 KHz - 5060000 KHz @ 10000 KHz), (N/A, 2300 mBm) <6>[74267.463591] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm) <6>[74267.463713] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm) <6>[74267.463927] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2300 mBm) <6>[74267.464110] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (N/A, 2000 mBm) <3>[74268.456267] wlan: [28357:E :PE ] limProcessJoinFailureTimeout: 3997: In state eLIM_MLM_WT_JOIN_BEACON_STATE. <3>[74268.456420] wlan: [28357:E :PE ] limProcessJoinFailureTimeout: 4000: Join Failure Timeout occurred for session 0 with BSS <3>[74268.456572] wlan: [28357:E :PE ] limPrintMacAddr: 1309: 62:38:E0:A:F:xx <6>[74268.456817] wlan: connection failed with 62:38:e0:0a:0f:xx reason:3 and Status:7 <6>[74268.456939] wlan: connection failed with 62:38:e0:0a:0f:xx reason:1 and Status:9 <3>[74268.491851] wlan: [28357:E :SME] Invalid center channel (102), disable 40MHz mode <3>[74269.496245] wlan: [28357:E :PE ] limProcessJoinFailureTimeout: 3997: In state eLIM_MLM_WT_JOIN_BEACON_STATE. <3>[74269.496398] wlan: [28357:E :PE ] limProcessJoinFailureTimeout: 4000: Join Failure Timeout occurred for session 0 with BSS <3>[74269.496581] wlan: [28357:E :PE ] limPrintMacAddr: 1309: 62:38:E0:A:F:xx <6>[74269.496856] wlan: connection failed with 62:38:e0:0a:0f:xx reason:3 and Status:7 <6>[74269.496978] wlan: connection failed with 62:38:e0:0a:0f:xx reason:1 and Status:9

[starcms]

@yuhhaurlin Have you been able to make any progress on this issue for the 1200/1900AC/ACS models?

[yuhhaurlin]

Stock firmware does not support DFS channels for these devices, right?

[yuhhaurlin]

Since stock firmware does not support DFS channels for 88W8864, mwlwifi will not support it. Especially if your device is with device power table, these channels are blocked. I close this issue. Thanks.

[adri-k]

@yurhaulin

If I am correct Linksys has advertized the 88W8864 based WRT1900ACS as being DFS capable! If the DFS problem isn't going to be fixed by Marwell, then remove the faulty code from the firmware?

[yuhhaurlin]

I mean stock firmware does not allow user to set DFS channels. Mwlwifi will follow it.

[adri-k]

On the new WRT1200AC v2 and the new WRT1900ACS v2, the embedded power tables have all the DFS channels listed, so this IMPLIES support for being DFS capable! If the hardware is not DFS capable, then the DFS channels would not be listed in the embbeded power tables.

[yuhhaurlin]

Can you set these DFS channels via GUI of stock firmware?

[adri-k]

I have a WRT1900ACS v1 and will have to load the stock firmware once I get home tonight to check. Maybe some else can also try it on a WRT1x00AC(s) v1 or v2?

[adri-k]

@yuhhaurlin

In issue #37 you wrote on Oct 28, 2015 'DFS will be supported later.' In the same issue you wrote on Jan 6, 2016 'DFS is added. Please check 99d3879.'

Why did you now all of a sudden change your mind and withdraw all support for DFS? I don't think this is normal or fair.

[yuhhaurlin]

WRT3200ACM supports DFS channels For other devices, mwlwifi needs to follow stock firmware.

[aaron1959]

He has been saying that all along. you need to read and understand before you say unfair. "mwlwifi needs to follow stock firmware" it has nothing to do with what is in the power table and data in the power table can't be construed as some promise of some non standard feature.

[adri-k]

@aaron1959

I was saying unfair, because it was @yuhhaurlin in the first place, who promised DFS support. I specifically bought the router because it had DFS support and I checked this repo, seeing the commit 99d3879. Should I now return the router to Linksys or to Marwell for a full refund?

[aaron1959]

So you purchased a router based on a git that promised DFS for a DRIVER! mwlwifi. There is NO MENTION of any 1900 router in that LINK you post. You have been told o0ver and over and over that the driver follows what the stock firmware does in respect to DFS it was stated long ago. Your 1900 doesn't do DFS so sell it and chalk it up to your inexperience but don't start calling folks "unfair" just because of your lack of understanding. Marvell didn't make your router you need to deal with Belkin, or whoever you bought it from. You have NO complaint with anyone here.

[bmork]

Let's try to be constructive, eh?

Guessing a lot here, since real docs are hard to get by. But looking at stock firmware version 1.1.7.159143, we see that dfs_enabled is set by default for the 5Ghz radio:

bjorn@miraculix:~/docs/hardware/linksys/wrt1900ac$ grep dfs stock/FW_WRT1900AC_1.1.7.159143/etc/system_defaults 
$wl0_dfs_enabled=0
$wl1_dfs_enabled=1

This setting is then later user to set the "magic" 11hspecmgt driver private setting:

bjorn@miraculix:~/docs/hardware/linksys/wrt1900ac$ grep -4 DFS stock/FW_WRT1900AC_1.1.7.159143/etc/init.d/service_wifi/wifi_utils.sh
set_driver_dfs() 
{
        PHY_IF=$1
        SYSCFG_INDEX=`syscfg_get "$PHY_IF"_syscfg_index`
        DFS=`syscfg_get "$SYSCFG_INDEX"_dfs_enabled`
        if [ "1" = "$DFS" ]; then
                iwpriv $PHY_IF 11hspecmgt $DFS
        else
                iwpriv $PHY_IF 11hspecmgt 0
        fi
}

This function is again called from /etc/init.d/service_wifi/wifi_physical.sh. There also appears to be some DFS related code in the driver, but we don't know what it does:

bjorn@miraculix:~/docs/hardware/linksys/wrt1900ac$ strings stock/FW_WRT1900AC_1.1.7.159143/lib/modules/3.2.40/ap8x.ko |grep DFS
Hget11hDFSMode
Cannot allocate memory for DFS SM
DFSApCtor
DFSApReset
DFSGetExtensionChannelOfDFSChan
evtDFSMsg
DFSGetCurrentRadarDetectionMode

Now it would of course be nice if someone would flash stock firmware and verify...

EDIT: Googling for those driver functions, I found: https://github.com/kmihelich/wlan-smileplug/blob/master/core/mgt/AP/dfsSM.c

[adri-k]

@aaron1959 The link to the commit for the mwlwifi driver says 'Added code to support DFS. Signed-off-by: David Lin dlin@marvell.com' Since this is a commit for the opensource mwlwifi driver, it applies to the 1900 routers. According to Belkin/Linksys, the 1900 routers are fully supported by open source firmware, like OpenWRT, which uses the mwlwifi driver. So I fail to see any relevant point in your earlier 'rant' and still stand by my original opinion that the 1900 routers were supposed to support DFS.

[Fr3DBr]

@adri-k Was this a functionality announced by Linksys for the product you've purchased ? If not, then you shouldn't complain, but hey, this is the opensource community, so feel free to try doing it by your own, other than fighting with marvell developers about something they have a business contract with Belkin/Linksys to deliver the expected features/functionalities and no more... Again, this is open source, so you can download the code and do it yourself.

[adri-k]

@Fr3DBr

I'd be happy to look and try to fix it myself. But the DFS scanning and detection is in the closed source binary firmware blob. :( The current mwlwifi driver just interfaces and get a notification DFS has been detected and the radio has been shutdown. So if @yuhhaurlin can make the sources of the firmware available, we can have a look and try to fix things. Without these sources, it is not possible.