Wrong Timestamp in DFS Log Entry
Background:
Radar signals are frequent in this area. To get a better understanding on the use of DFS channels, it was decided to test and monitor the channel changing process and see how it affects the network’s security cameras.
Test setup:
The outdoor EAP is configured to operate on channel 100 (DFS). One battery-powered IP camera is configured for the 5 GHz SSID and is the only 5 GHz client. All other clients connect using the 2.4 GHz SSID. The camera is also “locked” to the access point and will not connect to another access point in the network in the event of a disconnect.
Results:
Once a radar signal was detected, the EAP correctly changed the DFS channel to another DFS channel. As shown in the attached log screenshot, the channel changed from 100 to 108 at 13:14. It is assumed that the EAP transmitted a Channel Switch Announcement as the camera followed the channel change and did not disconnect according to the logs.
After five hours, the EAP was still using channel 108. From information found on this forum, it is understood that the EAP will not return to its configured channel while clients are still connected. Therefore, the camera was forced to disconnect at 18:24 by clicking the Reconnect icon in the controller display. In monitoring the RF spectrum, the EAP ceased to transmit on channel 108 almost immediately after the camera disconnected. After several minutes, the EAP began to transmit again on its configured channel of 100 and shortly thereafter the camera reconnected successfully at 18:38.
The logging issue occurred an hour later when the EAP entry at 19:34 stated “EAP772 Outdoor changed 5GHz channel from 108 to 100 after NOP”. Real-time monitoring confirms the actual event took place at around 18:34. Since all other log entries are accurately timestamped, the one-hour difference for this NOP entry remains unexplained.
