Enable the port when disabling countermeasures, and disable it on enabling countermeasures. This bug causes the response of the system to certain attacks to be ineffective. It also prevents wpa_supplicant from getting scan results, as wpa_supplicant disables countermeasures on startup - preventing the hardware from scanning. wpa_supplicant works with ap_mode=2 despite this bug because the commit handler re-enables the port. The log tends to look like: State: DISCONNECTED -> SCANNING Starting AP scan for wildcard SSID Scan requested (ret=0) - scan timeout 5 seconds EAPOL: disable timer tick EAPOL: Supplicant port status: Unauthorized Scan timeout - try to get results Failed to get scan results Failed to get scan results - try scanning again Setting scan request: 1 sec 0 usec Starting AP scan for wildcard SSID Scan requested (ret=-1) - scan timeout 5 seconds Failed to initiate AP scan. Upstream commit: http://git.kernel.org/linus/0a54917c3fc295cb61f3fb52373c173fd3b69f48
Statement: This issue did not affect the version of Linux kernel as shipped with Red Hat Enterprise Linux 4 and 5 as they did not backport the upstream commit d03032af that introduced this issue. Future kernel updates in Red Hat Enterprise Linux 6 and Red Hat Enterprise MRG may address this flaw.
This issue has been addressed in following products: MRG for RHEL-5 Via RHSA-2011:0330 https://rhn.redhat.com/errata/RHSA-2011-0330.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0421 https://rhn.redhat.com/errata/RHSA-2011-0421.html
State: DISCONNECTED -> SCANNING Starting AP scan for wildcard SSID Scan requested (ret=0) - scan timeout 5 seconds EAPOL: disable timer tick EAPOL: Supplicant port status: Unauthorized Scan timeout - try to get results Failed to get scan results Failed to get scan results - try scanning again Setting scan request: 1 sec 0 usec Starting AP scan for wildcard SSID Scan requested (ret=-1) - scan timeout 5 seconds Failed to initiate AP scan. Via RHSA-2011:0421 https://goo.gl/nuKiGX