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...

[bmork]

@adri-k

Let's be realistic. Nice as it would be, there is not much chance of ever getting the firmware source. Documentation of the firmware API would be good, though.

[thagabe]

@Fr3DBr as an owner of the wrt1900ac v1, contributor to lede, and testing mwlwifi from the beginning I do remember DFS being implemented on the original mwlwifi code but never actually worked bc the closed source firmware was way too sensitive to radio detection, then the work was put on back-burner to fix the 8xxx64 chips (wrt3200acm). Since the code has stabilize a bit I think @yuhhaurlin should look back to correctly implementing DFS (As it was advertised as such and works on the closed source firmware) for both generations of chips (I think the 3200 works but needs refinements while 1900 vX don't really work at all).

[adri-k]

@thagabe

I full agree with you.

DFS was implemented for the mwlwifi driver and added to the open source version on Jan 6th 2016 for the 8xxx64 chips, including the chip used in the wrt1900ac(s). Afterwards it turned out the DFS was way to sensitive and not working as expected. Instead of trying to find the cause, we got the message DFS support would be dropped. :(

After being advertized, it would be a better approach to try and fix the issue in the open source firmware or change the driver to work with the closed source firmware which has proper DFS support, like @yuhhaurlin is doing for the wrt3200acm.

[yuhhaurlin]

Are you sure stock firmware for devices other than WRT3200ACM supports DFS channels?

[davidc502]

Loaded stock firmware on the Wrt1900acs Version1, and checked Wifi settings. No DFS channels are available.

[yuhhaurlin]

Thanks.

[Chadster766]

I don't understand why mwlwifi needs to only implement what the Linksys stock firmware implements.

Why wouldn't you make this a more full featured and advanced driver? Is that not why open source firmware's exists?

:unamused:

[Razerwire]

Why was this issue closed are we NOT ever getting working DFS for the (WRT1900AC(v1)/(v2)/(S)??

[farchord]

@Razerwire I think that, if I understand well, the mwlwifi driver can only implement features as far as the wifi chip's internal firmware allows. DFS is something he can't do anything past what the firmware on the chip allows.

[Chadster766]

@yuhhaurlin is that the case that the api for the 88W8964 firmware doesn't support DFS and other features?

If so we should limit that driver section to only apply to the WRT3200ACM and continue the previous mwlwifi driver architecture development for the WRT1X00AC/S devices because that chip set firmware was more full featured and very stable for those devices.

[yuhhaurlin]

DFS implementation needed for mac80211 is done by mwlwifi. WRT3200ACM should work. For other devices, due to stock firmware does not support it, mwlwifi can just follow stock firmware.

[adri-k]

@yuhhaurlin

Can you please explain why mwlwifi HAS to follow stock firmware? Previously this didn't seem to be the case, since you added DFS support on Jan 6th 2016, when the WRT3200ACm didn't even exist. DFS detection is already implemented in the firmware used by the current WRT1X00AC/S chips, it just seems to be a little too sensitive, mistaking most interference as radar signals.

[jcodybaker]

Linksys sells the WRT3200ACM for more money than the WRT1*00. They’re not going to pay for development work which lets you get the expensive features for the inexpensive price. It may also be a matter of FCC licensing; if the device isn’t certified to properly clear those DFS channels it wouldn’t be in compliance.

You could fork the repo, look reverting to the Jan 6th commit, and compare it to the code that works for the WRT3200ACM. That all said, there may be reasons the physical hardware cannot reliably support DFS. The WRT3200ACM has an extra radio, more advanced chip, and other hardware which may be necessary for DFS to work properly.

Cheers,

Cody

From: adri-k notifications@github.com Reply-To: kaloz/mwlwifi reply@reply.github.com Date: Saturday, May 20, 2017 at 1:20 PM To: kaloz/mwlwifi mwlwifi@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [kaloz/mwlwifi] DFS not working (properly) 5ghz reverts to channel 36 (#75)

@yuhhaurlinhttps://github.com/yuhhaurlin

Can you please explain why mwlwifi HAS to follow stock firmware? Previously this didn't seem to be the case, since you added DFS support on Jan 6th 2016, when the WRT3200ACm didn't even exist. DFS detection is already implemented in the firmware used by the current WRT1X00AC/S chips, it just seems to be a little too sensitive, mistaking most interference as radar signals.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/kaloz/mwlwifi/issues/75#issuecomment-302896411, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEjz56ePjsl_zC5F6ZO17MoKosXiUOfQks5r70sWgaJpZM4IOP9W.

[davidelang]

guys, he tried adding DFS, but found that the radar detection generated a lot of false positives, and any false positive requires that it abandon the channel (which typically means switching to channel 36)

This is a very common problem with trying to use DFS channels, it's really hard for a device to tell the difference between real radar (which it must abandon the channel for) and random interference that it can live with (which can include another wifi device on the same channel that's too far away to hear clearly)

He decided that the hassles of dealing with complaints about DFS reverting to channel 36 aren't worth the value of trying to add support for channels the manufacturer doesn't support.

David Lang

[ghost]

Sadly DFS doesn't work 100% out of the box on the WRT3200ACM and even had two units of same hardware version 90% of the time it worked but at random hours the DFS was unstable when RF interference was at the highest amount in a high-density urban housing complex.

5Ghz WiFi has greater speeds, lower distance coverage, and is getting very saturated in the 5Ghz 149-165 channel range, I can only find 5Ghz stable for myself in the channel 36 range (5250-5170Mhz at 80Mhz channel width).

[yuhhaurlin]

Firmware of 88W8964 had been certified. Please use stock firmware to check again.

[davidelang]

On Sat, 20 May 2017, rs-se wrote:

Sadly DFS doesn't work 100% out of the box on the WRT3200ACM and even had two units of same hardware version 90% of the time it worked but at random hours the DFS was unstable when RF interference was at the highest amount in a high-density urban housing complex.

this is a common problem with DFS, it's really hard to tell the difference between radar and noise

5Ghz WiFi has greater speeds, lower distance coverage, and is getting very saturated in the 5Ghz 149-165 channel range, I can only find 5Ghz stable for myself in the channel 36 range (5250-5170Mhz at 80Mhz channel width).

It's insanely disappointing that there is no way to cut the power level, that's really needed to make things work in high-density environments.

sadly, this will mean I have to cross this family off the list of possibilities until thats changed.

[adri-k]

DFS detection has to follow certain rules.

1. The signal has to be relatively strong to qualify.
2. The pulses have to follow a certain pattern to qualify.

Using these rules it isn't too difficult to rule out most interference as non-DFS. To implement rule 2 properly, you may have to do some kind of FFT processing, but there is already existing open source code for the whole procedure.

It seems Linksys/Marwell are doing the standard thing:

1. Release a new device.
2. Abandon all development and support for old devices, even if they are not working properly or have bugs.,
3. Tell the customer he'll need to upgrade to the newer device to get his problems fixed.

Forking the repo, reverting the Jan 6th 2016 commit and comparing to the new WRT3200ACM code won't help. All the DFS detection is in the closed source binary blob of the firmware and the driver only gets a notification from the firmware DFS has been detected and the radio has been shut down. The only duty of the driver is to switch to another channel, since the firmware won't allow use of the existing channel for at least 30 minutes.

[Chadster766]

With mwlwifi wouldn't DFS detection be built into the chip firmware and only have to be enabled?

[adri-k]

@Chadster766

As far as I know, the DFS dectection is already build in to the firmware of the chip. It currently has a few problems and doesn't always work properly, giving a lot of false positives. Since the firmware is closed source and only Marwell or Linksys have the sources, they have to be willing to fix it.

[thagabe]

@adri-k that is one of the most informative comments I've read. Since the closed source firmware for the chip is within Marvell's ability to fix then we should put pressure on them to fix it even if it's only for the 3200acm this is an ongoing issue that does merit a quick response from Marvell as it pertains to something only they can fix while advertising it on their website (tl;dr this time it isn't linksys miss advertisement)

[kevinxucs]

diff --git a/hif/pcie/pcie.c b/hif/pcie/pcie.c
index da55913..1f5af72 100644
--- a/hif/pcie/pcie.c
+++ b/hif/pcie/pcie.c
@@ -455,10 +455,10 @@ static irqreturn_t pcie_isr(struct ieee80211_hw *hw)
                        }
                }

-               if (int_status & MACREG_A2HRIC_BIT_RADAR_DETECT) {
-                       wiphy_info(hw->wiphy, "radar detected by firmware\n");
-                       ieee80211_radar_detected(hw);
-               }
+               //if (int_status & MACREG_A2HRIC_BIT_RADAR_DETECT) {
+               //      wiphy_info(hw->wiphy, "radar detected by firmware\n");
+               //      ieee80211_radar_detected(hw);
+               //}

                if (int_status & MACREG_A2HRIC_BIT_QUE_EMPTY) {
                        if (!pcie_priv->is_qe_schedule) {
@@ -922,10 +922,10 @@ static irqreturn_t pcie_isr_ndp(struct ieee80211_hw *hw)
                        }
                }

-               if (int_status & MACREG_A2HRIC_NEWDP_DFS) {
-                       wiphy_info(hw->wiphy, "radar detected by firmware\n");
-                       ieee80211_radar_detected(hw);
-               }
+               //if (int_status & MACREG_A2HRIC_NEWDP_DFS) {
+               //      wiphy_info(hw->wiphy, "radar detected by firmware\n");
+               //      ieee80211_radar_detected(hw);
+               //}

                if (int_status & MACREG_A2HRIC_NEWDP_CHANNEL_SWITCH)
                        ieee80211_queue_work(hw, &priv->chnl_switch_handle);

seems to work pretty well 😏

[eduperez]

@kevinxucs: does that disable radar detection completely? does it comply with current regulations?