Cisco CleanAir will report the following traps on CUWN WLCs:
- AP APNAME06[1] (50:1c:bf:b4:d8:00) Device ID: 0x20f9, Type: WiFi Invalid Channel[31], Severity: 0, Channels: 149, Cluster ID: 0e:58:c0:79:38:7d, Previous Cluster ID: 0e:58:c0:79:38:7d, Event: Set
- AP APNAME17[0] (34:db:fd:d4:62:60) Device ID: 0xd979, Type: WiFi Invalid Channel[31], Severity: 0, Channels: 11, Cluster ID: 0e:58:c0:7b:e0:1a, Previous Cluster ID: 0e:58:c0:7b:e0:1a, Event: Set
- AP APNAME806[1] (50:1c:bf:b4:d8:00) Device ID: 0x20f2, Type: WiFi Inverted[30], Severity: 2, Channels: 149, Cluster ID: 0e:58:c0:7b:c9:8c, Previous Cluster ID: 0e:58:c0:7b:c9:8c, Event: Clear
These are more likely RF interferer devices that could easily be sending RF inverted signals or signals on invalid 802.11 channels (somewhere in the 2.4GHz and 5GHz bands), and hence reported as such (CleanAir was not able to confirm what specific type of device that was, but was able to notice some inverted signals or signals on those invalid channels, and hence the messages).
Basically, the WiFi invalid channel message means that the APs have detected some RF interferer devices transmitting on some shifted central frequency. For example, we have 1 - 13 channels on 2.4 GHz, imaging some device transmitting on channel 6.5 (in between 6 and 7), that will be invalid channel, which is simply detected by the Spectrum Expert of our ClearAir.
What does WiFi Inverted mean? WiFi is encoded on the physical carrier using I and Q data; this is the relationship between phase, amplitude, and frequency. The following document explains this in depth:
What is I/Q Data?
Basically, spectrally inverted WiFi is a WiFi signal with the I and Q reversed; if you have a transmitter and a receiver both expecting this, you have an undetectable bridge (since normal WiFi chips will see noise).
*** ABOUT THE LOGS ***
The logs basically show the AP name and radio that detected the invalid channel or inverted signal, as well as the channel used by the AP that could be affected by this RF interferer device:
AP APNAME1[1] (84:78:ac:e8:23:80) Device ID: 0x613e, Type: WiFi Invalid Channel[31], Severity: 2, Channels: 149, Cluster ID: 0e:58:c0:73:61:c1, Previous Cluster ID: 0e:58:c0:73:61:c1, Event: Clear
AP APNAME806[1] (50:1c:bf:b4:d8:00) Device ID: 0x20f2, Type: WiFi Inverted[30], Severity: 2, Channels: 149, Cluster ID: 0e:58:c0:7b:c9:8c, Previous Cluster ID: 0e:58:c0:7b:c9:8c, Event: Clear
The [31] doesn't make reference to a channel, but to the ID of this "Invalid Channel" or "Inverted" CleanAir detection action, and the Cluster ID is automatically made by CleanAir to give a MAC-Address based identifier to the interferer device that might not use MAC addresses (such as the signals from a Microwave oven). You can understand the purpose of this ID better with the following document:
Cisco CleanAir - Cisco Unified Wireless Network Design Guide
Therefore, you might want to physically look for RF interferer devices around the APs detecting and reporting these messages (so you can take them down -if possible- and if they are really affecting the performance of the WLAN).
NOW, if this is generating too many traps and those RF interferer devices can't be tracked or taken down, or are not really affecting the WLAN, then the other recommendation we normally give for such scenarios is to disable the specific trap for these events (which are real events and there is nothing that can be done from the WLC to avoid them). You can disable the trap by using the following WLC command:
config {802.11a | 802.11b} cleanair alarm device disable 802.11-nonstd
In the end, the only way to put our finger on what exactly might be transmitting those signals on those locations, is by going onsite with a spectrum analyzer to confirm if what CleanAir is reporting is True: RF Signals on Invalid channels and inverted signals.
If that onsite confirmation can't be done, then there is no way to confirm if this is actually true or not and we just need to rely on CleanAir, but if this is not happening anymore (just happened once or some days, and went away) then there are possibilities that this could happen due to:
We have seen this on busy sites, generally the alert is of short duration, classified, then dropped.
This indicates that this is likely due to a combination of collisions or bursty traffic that the APs can't interpret at all and perceives (due to the RF issues on the environment) that there are inverted signals or signals on invalid channels. In such cases this is basically a false alarm.
In addition, our Cisco RF engineers have confirmed the following:
"WiFi Invalid Channel" is a WIFI packet that is not sent using the standard 802.11 channels, and so are invisible to normal WIFI clients, wIDS, and sniffers. This can also be achieved on any Wi-Fi chipset that the user has access to the radio command set. This used to be a very small subset of the market, but major manufacturers have recently released their HAL layers as open-source which significantly increases the risk from this type of attack:
802.11 relies on knowledge of the center frequency in the channel to properly align both receiver and transmitter. The amount of offset from the standard required varies by technology, for example:
- For 11b (1/2/5.5/11), packets > 500 kHz from a nominal channel are not likely to be detected (except for +5M and +10M).
- For 11a/g/n, packets > 250 kHz from a nominal channel are not likely to be detected.
Hence, they can be used by hacker equipment to operate rogue networks that can't be detected by existing tools.
*** CONCLUSIONS ***
Based on the information above, there are basically three possibilities for this scenario:
1) There are RF interferer devices (non-802.11) on the environment generating those signals.
2) RF on the environment is very busy, with interference and a combination of 802.11 collisions or bursty traffic.
3) There are actually hackers (basically using Rogue APs at the most, not specifically connecting to your WiFi infra) with the appropriate equipment sending signals at a frequency that is perceived as invalid channel for 802.11.
For any of the three reasons, again, the only way to confirm if there are actually devices transmitting at these invalid frequencies or with those inverted signals (on those locations), is by going onsite with a spectrum analyzer to validate what CleanAir is telling us in case there are doubts.
