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 because the commit handler
re-enables to 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.
Reported by: Giacomo Comes <comes@naic@edu>
Signed-off by: David Kilroy <[email protected]>
---
John, this patch could be a candidate for either stable or security
@kernel.org. I'm not to sure of the rules, so I haven't included a Cc...
---
drivers/net/wireless/orinoco/wext.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/orinoco/wext.c b/drivers/net/wireless/orinoco/wext.c
index 519e01e..9caec9f 100644
--- a/drivers/net/wireless/orinoco/wext.c
+++ b/drivers/net/wireless/orinoco/wext.c
@@ -912,10 +912,10 @@ static int orinoco_ioctl_set_auth(struct net_device *dev,
*/
if (param->value) {
priv->tkip_cm_active = 1;
- ret = hermes_enable_port(hw, 0);
+ ret = hermes_disable_port(hw, 0);
} else {
priv->tkip_cm_active = 0;
- ret = hermes_disable_port(hw, 0);
+ ret = hermes_enable_port(hw, 0);
}
break;
--
1.7.2.2
... and interface up.
In these situations, you are usually trying to connect to a new AP, so
keeping TKIP countermeasures active is confusing. This is already how
the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
tell userspace that countermeasures are active when they aren't.
Clear the setting so that the reporting matches what the driver has
done..
Signed-off by: David Kilroy <[email protected]>
---
drivers/net/wireless/orinoco/main.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index fa0cf74..f3d396e 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -1811,6 +1811,12 @@ static int __orinoco_commit(struct orinoco_private *priv)
struct net_device *dev = priv->ndev;
int err = 0;
+ /* If we've called commit, we are reconfiguring or bringing the
+ * interface up. Maintaining countermeasures across this would
+ * be confusing, so note that we've disabled them. The port will
+ * be enabled later in orinoco_commit or __orinoco_up. */
+ priv->tkip_cm_active = 0;
+
err = orinoco_hw_program_rids(priv);
/* FIXME: what about netif_tx_lock */
--
1.7.2.2
and interface up.
In these situations, you are usually trying to connect to a new AP, so
keeping TKIP countermeasures active is confusing. This is already how
the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
tell userspace that countermeasures are active when they aren't.
Signed-off by: David Kilroy <[email protected]>
---
drivers/net/wireless/orinoco/main.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index fa0cf74..f3d396e 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -1811,6 +1811,12 @@ static int __orinoco_commit(struct orinoco_private *priv)
struct net_device *dev = priv->ndev;
int err = 0;
+ /* If we've called commit, we are reconfiguring or bringing the
+ * interface up. Maintaining countermeasures across this would
+ * be confusing, so note that we've disabled them. The port will
+ * be enabled later in orinoco_commit or __orinoco_up. */
+ priv->tkip_cm_active = 0;
+
err = orinoco_hw_program_rids(priv);
/* FIXME: what about netif_tx_lock */
--
1.7.2.2
On Sat, Dec 4, 2010 at 8:42 PM, David Kilroy <[email protected]> wrote:
Truncated description - looks like missing text?
> and interface up.
>
> In these situations, you are usually trying to connect to a new AP, so
> keeping TKIP countermeasures active is confusing. This is already how
> the driver behaves (inadvertently). However, querying SIOCGIWAUTH may
> tell userspace that countermeasures are active when they aren't.
>
> Signed-off by: David Kilroy <[email protected]>
- Sedat -
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.
Reported by: Giacomo Comes <[email protected]>
Signed-off by: David Kilroy <[email protected]>
---
drivers/net/wireless/orinoco/wext.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/orinoco/wext.c b/drivers/net/wireless/orinoco/wext.c
index 519e01e..9caec9f 100644
--- a/drivers/net/wireless/orinoco/wext.c
+++ b/drivers/net/wireless/orinoco/wext.c
@@ -912,10 +912,10 @@ static int orinoco_ioctl_set_auth(struct net_device *dev,
*/
if (param->value) {
priv->tkip_cm_active = 1;
- ret = hermes_enable_port(hw, 0);
+ ret = hermes_disable_port(hw, 0);
} else {
priv->tkip_cm_active = 0;
- ret = hermes_disable_port(hw, 0);
+ ret = hermes_enable_port(hw, 0);
}
break;
--
1.7.2.2
On Sat, Dec 4, 2010 at 8:42 PM, David Kilroy <[email protected]> wrote:
> 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 because the commit handler
> re-enables to 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.
>
> Reported by: Giacomo Comes <comes@naic@edu>
> Signed-off by: David Kilroy <[email protected]>
> ---
>
Wrong Email - should be <[email protected]>?
- Sedat -