Hello forrest,

thanks for your reply.

forrest wrote

Now we don't permit to use "radartool" on the SSH. 

Yes, and this is bad. Even SOHO devices from TP-Link competitors allow to show information about detected wheather radars in the 5 GHz band (for example, devices from AVM).

You say you can run this command to detect channel changes caused by DFS, could you please tell us more details about it? 

I think very few products enable this privilege.

All WBS510 and CPE510 firmware versions from 1.x to 2.1.13 did allow radar detection. This is from a CPE510 with firmware 2.1.13:

$ ssh admin@192.168.0.254
admin@192.168.0.254's password: 

BusyBox v1.01 (2018.03.27-06:46+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# radartool numdetects
Radar: detected 0 radars
#

Starting with firmware version 2.2.0, Pharos introduced Privilege Separation and now radartool isn't allowed anymore. EAP225-Outdoor has disabled radartool for admins since the beginning if I remember correctly. Can't check old firmware versions at the moment, but will check whether we still have an EAP225-Outdoor with first available firmware.

When the EAP devices are always detecting the DFS, we are not sure if it will affect the performance of EAP.

I think there is a mis-understanding. Radar detection aka DFS is required in 5 GHz outdoor channels by law in allmost all countries world-wide except Russia. Every outdoor device always needs to have DFS enabled, no matter which model and from what vendor.

Thus, every TP-Link product using the U-NII2A/2C frequencies (that's 5250 MHz to 5720 MHz) is required to handle DFS and yes, this function of course does always affect the performance of an EAP as well as of a WBS/CPE.

That's why we need to check whether DFS causes excessive changes of channels in a given region due to a nearby wheather radar. The device does such changes of channels anyway, whether we can check for it or not using radartool.

Since we consider to change from Pharos CPEs to EAP225-Outdoor for installations such as this one, we need to be able to display information about detected radars.

Hello forrest,

of course is radar detection managed by hardware. But using driver I/O controls (ioctl) we can query the hardware's states.  The WiFi chip maintains a list of channels where radar has been detected in the NOL (non-occupancy list).

I have access to the confidential source code of the radartool command developed by Qualcomm Atheros. It clearly shows the I/O control command to query the ath chip beside many commands to set registers which control the radar detection of the chip. This is the desscription of the radartool command from the source code:

numdetects       get number of radar detects

This is the I/O control querying the hardware:

radar->atd.ad_id = DFS_RADARDETECTS | ATH_DIAG_DYN;

...

if (ioctl(radar->s, SIOCGATHPHYERR, &ifr) < 0)

If your R&D thinks it's not possible to query the chip for radar detects, then please ask them how AVM, Ubiquiti and Aruba can manage to show radar detects on their APs using Atheros WiFi chips.