Is there somewhere in cnMaestro, or in the device logs, where I can see a log or a realtime status of DFS events that could be causing dropouts?
e600 firmware 4.1-r3
Check your logs, it will say DFS on dfs detection.
Device. You should also configure a syslog server to gather the logs as the device cleans its logs enough to be troublesome
Thank you - I’ll try to set something up.
Just get a copy debian 10 (do not setup the graphical desktop, its not needed and makes things harder to secure) and nano /etc/rsyslog.conf
Follow the instructions in the file to send the logs to a dedicated log for that device and then ctrl+x then y and then touch the filename for the log file and chown root:root the file and chmod 774 the file.
This can be done by IP address or hostname and it is best to not send the logs to the standard syslog file.
Once it is setup, simply change the radio config to point the radio syslog to the remote syslog server, set the logging level and reboot the radio. Then wait 15mins for the log to populate and use tail -F /path/to/logfile to see what is happening in real time and nano /path/to/filename to review the logs and see what has happened and when.
I HIGHLY recomend setting up an ntp server and pointing the radio and the log server to it for time. This will make sure your logs actually reflect the same time as the log event.
1 Like
Haven’t had the chance yet to set up that syslog server @Douglas_Generous but, to anyone else interested, since switching from a hard-locked 5G channel 100 to “auto + prefer DFS”, those blips have disappeared. So my hunch was probably correct that these were radar detects
1 Like
If you click on an AP in cnMaestro, then Notifications tab you can see Alarm History and Events.
Under events, you can filter for two DFS related message type + once I saw an event where a cnPilot AP specifically alarmed for DFS interference and created an event for channel change.
maybe you should check this one.
@AH_WIFI4EU Thanks for that tip. I checked that area, and even exported the available event log as CSV and looked through it. It seems to only go back 5 days, but even within that timeframe, there were only 2 event types listed:
WIFI_CLIENT_CONNECTED
WIFI_CLIENT_DISCONNECTED
Is there somewhere else I need to enable more detailed logging or additional event types? Or does this just mean there were no DFS alerts triggered?
I think there is no configuration option for this, event logging seems to be simple SNMP trap or syslog receiving from the APs.
Anyway, best practice is to prevent the need for DFS, so disable all related channels. At my place, this is the instruction of the local authority too.
Here is a list of channels used on all outdoor wifi system I implement: 36 40 44 48 52 56 60 64 100 104 108 112 116 132 136 140
Missing ones are used by weather or military radars in my country.
You can set this up in the AP group, selecting “specific channels” for 5GHz.
Build a syslog server and point your radios to it with the syslog settings and enable all logging types.
I highly suggest rsyslogd for this as you can separate the logs by IP and MAC address into separate log files. This is handy and if you use logrotate to manage your logs then you can keep logs by the hour/day/week/whatever and split them by the same fairly easily. Save searching through a large monolithic logfile of all your devices
1 Like
Please remember that this equipment does not show channel number assignments as you select a channel width and center frequencies.
An easier way to ensure your not using DFS channels is on your AP when set to your country, will show (DFS) beside all DFS channels for your region. Dont use them as center frequencies.
Absolutely right, but @Luke_Hamburg talking about APs managed with cnMaestro. There you can set channels, not frequencies. Anyway, above channel list is for Hungary and validated by the national regulatory body. 