XT8 wireless backhaul problems, DFS channels, local regulations and "recent" firmwares

[roxxor]

Hi everyone,

After long reading and tests regarding the famous "XT8 wireless backhaul constant drops" topics we find all over the place on the web (since, let say, few months before the first 388 branch release), I understand that the problem only concerns gear used outside of the US, in countries where (because of local regulations) there is no "non-DFS" channels available to use in the 5 GHz-2 radio frequency range.

As DFS sucks (yes it sucks, at least in the way it's managed in current Asus/Broadcom implementation), the solution to have a stable 5 GHz setup is to:
- untick the "Enable 160 MHz" for 5 GHz-2 radio (less channels used = less "chance" to be in competition with radars and face channel switching/WiFi drops)
- and untick "Auto select channel including DFS channels" for 5 GHz-1 radio, to avoid DFS "pleasures" at any cost

Note that you cannot untick "Auto select channel including DFS channels" for 5 GHz-2 radio outside of the US because all channels in the range of this radio are DFS channels.

Once we know all of this,

What changed, at some point (when ?), in Asus/Broadcom code, regarding DFS management and had these consequences where XT8's wireless backhaul is not usable anymore with 160 MHz bandwith outside of the US ?

Is it normal, that, in recent firmwares (late 386's and now 388 branch firmwares), when a DFS event occurs on 5 GHz-2 radio, there is a storm impacting ALL 5 GHz connections (everything disconnects and then reconnects) including all devices connected to 5 GHz-1 radio with "Auto select channel including DFS channels" unticked ?

I'll be happy to read your answers/thoughts.

 

[OzarkEdge]

This probably won't help ... I have not used the XT8... and anything is possible with each model and firmware.

If you can use DFS bands/frequencies for WiFi in your region without the router prohibiting it and disrupting your WLAN/clients, then it works for you. Otherwise, it presumably works for the other/RADAR DFS band user out there.

If you have wireless clients that do not tolerate DFS control channels, then you should restrict your WiFi to non-DFS control channels (untick 'include DFS control channels'). This will likewise determine which available DFS band can still be used for extension channels for a given bandwidth that requires them (still subject to DFS disruption).

So, if DFS does not work for you in your region (disrupts WLAN/clients), don't use it... avoid DFS bands.

If DFS does work for you in your region, but regional and your own client restrictions limit the available DFS bands to use, compounded by trying to squeeze two WLANs out of the 5.0 band, then this is what it is... not workable... avoid this product (buy dual-band and wire it for max headroom).

If DFS does work for you in your region without these restrictions, you still may not want to subject your clients/users to possible DFS disruption.

DFS has been working here steadily for the first time with my current AiMesh (ax-ax; DFS did not work for me with ax-ac). I restrict to a non-DFS control channel to accomodate a legacy client, so using bands 1,2a at 160MHz.

OE

 

[roxxor]

OK ...

First, what does "DFS does work" mean ? I don't even know how it should exactly behave by design because, up until few firmwares releases, like a lot of other people, i had no problem/question at all regarding all of this. I had no WiFi dropouts. Today, my setup and clients are the same so, as I had no problem (or what I consider to be problematic) one year ago, can we assume that they (my clients/AP/node) do tolerate DFS control channels ?

In an environment where no radar signal is ever present/detected (maybe it's your case), yes, DFS does work in the sense that I can tick all the boxes (160 MHz and "...including DFS channels") and I have no dropouts as no channel switching occur. In this case, DFS is absolutely perfect.

In an environment where radar signals are detected (maybe you've never been in this scenario), if you tell me that, by design, DFS tech as no "overlap/buffer" mechanism (I'm simplistic on purpose) so you may have slight dropouts during the switch from one channel to another then, yes, DFS does work also. Perfectly. If you tell me that, in this scenario, we should have no dropout at all then I confirm there is a problem with XT8 firmware since few months.

Anyways, as you guessed it , it does not answer my questions: Why do we (I say "we" because I'm really not alone on this, unfortunately) have dropouts/unstable 5 GHz WiFi with XT8's for a year now whereas it was rock solid before ? If the explanation is that DFS was not working before (hence perturbating radars for instance), has been fixed and is now working has it should (meaning also with short dropouts for all clients), then OK, I can even hear that. Also, on a product with two 5 GHz radios, is it normal/by design that a DFS event on one radio seems to impact the second radio (set to not use DFS channels) ?

Regarding your 1,2a band choice, unfortunately the 160 MHz radio on XT8 does not operate on 1 and 2a bands.