DFS Triggers when one laptop is used?

[dderbowka]

I have several Cisco AIR-LAP1142N-A-K9 units installed in our home/homeoffice, all of which are connected to a 4402WLC. Several devices all of which are 5GHz capable. The WLC allows the AP's to use channels 40-64, 100-116, 132-140, Excluding Channels 36, 149-165. There is moderate activity neighboring on those channels.
The AP's remain primarily in the 100-140 channels, and are usually there for weeks on end and never show any DFS triggers.

Wasn't until I started using my  ASUS X205TA laptop on the network we would be dropping out and loosing Network access. Happens every time instantly when it connects. The AP's would go to another channel that is DFS and it starts broadcasting, laptop joins, dropped out again. Repeats this until the AP chooses a non-DFS channel like 40, 44, 48. After an hour or so it will return back to the other channels. Along as the laptop's wireless is not used. I have Disabled it temporarily to avoid interruptions and all seems to be fine since. 

Upon connection of the laptop, in the Log of the WLC it shows what is below in the image. We have other laptops that can run all day and never once will there be a DFS trigger in the log. Same goes with the tablets, phones and chromecast devices. In-fact we will stream to the Chromecasts from the tablets, phones and laptops all day trouble free and interruption free. That is if that ASUS one stays off the Wireless or I use the USB to Ethernet one.  

[Michael Combs · Accepted solution]

That's certainly interesting if you observe these radio channel changes due to perceived DFS events 100% of the time whenever the ASUS EeeBook X205TA connects (or attempts to connect) to an AP on a UNII-2 or UNII-2e channel.

Though not common, I have seen this before with certain client STAs in the field. Essentially the WLAN adapter and specific antenna design in your particular client device is emitting an RF "spur" whose signature is similar to that of a radar signal as perceived by an 802.11 radio. Due to stringent regulatory and associated DFS requirements, the AP will therefore of course immediately defer the current channel to the perceived radar entity and begin to move to another channel accordingly. Though without some kind of spectrum analysis when such an event occurs, it's of course difficult to say if that is indeed your issue with any real kind of certainty.

There has been some improvements here and there in more recent versions of WLC code (i.e. 8.0+, preferably latest 8.2 code) in attempts to reduce and mitigate some of these "false positive" events. However, that is of course a non-starter in your scenario sadly given that the EoL 4400 series WLC only supports up to the 7.0 code train. Given that this is for a home/home office I imagine there is a limited number of APs in use, so perhaps the simplest solution is to indeed use non-DFS channels (i.e. UNII-1 and UNII-3) or utilize an alternate WLAN adapter (i.e. USB, etc.) on your ASUS EeeBook and disable the offending internal adapter.

It may well be worth your while to try to see if updating your WLAN adapter drivers first and see if it hopefully offers some improvements. Otherwise, it would certainly be worth reaching out to ASUS for support on this, as they can then engage the WLAN adapter manufacturer as an OEM partner.

[dderbowka]

Thank you for your detailed response, really useful information. 
If I had some tools just for the sake of being able to see what the spurs emitted are like, and how it all plays out as a whole I would do that.

I will contact ASUS Support to see what they have as a solution for it.  I assume the Wireless Chip in the card is likely built in because of how small it is. I may be better off like you said to just purchase a USB WLAN adapter for it to use it.

However with that being said I have a USB to Ethernet one that I use if I need to print with it or if it needs updates and so forth. Otherwise I use it outside of the home. 

Thanks Again!