From: Amitkumar Karwar <[email protected]>
Auto auth mode is enabled by default. If user doesn't specify the
auth mode, while association driver will first try with open mode
and then with shared key mode. If user specifies an auth mode,
auto auth is disabled and driver will not try association with
another auth mode.
Signed-off-by: Amitkumar Karwar <[email protected]>
Signed-off-by: Bing Zhao <[email protected]>
---
drivers/net/wireless/libertas/assoc.c | 22 +++++++++++++++++++++-
drivers/net/wireless/libertas/dev.h | 1 +
drivers/net/wireless/libertas/main.c | 1 +
drivers/net/wireless/libertas/wext.c | 4 ++++
4 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/libertas/assoc.c b/drivers/net/wireless/libertas/assoc.c
index f03d5e4..95d3d4c 100644
--- a/drivers/net/wireless/libertas/assoc.c
+++ b/drivers/net/wireless/libertas/assoc.c
@@ -31,6 +31,9 @@ u8 lbs_bg_rates[MAX_RATES] =
0x00, 0x00 };
+static int assoc_helper_wep_keys(struct lbs_private *priv,
+ struct assoc_request *assoc_req);
+
/**
* @brief This function finds common rates between rates and card rates.
*
@@ -610,7 +613,7 @@ static int lbs_assoc_post(struct lbs_private *priv,
if (status_code) {
lbs_mac_event_disconnected(priv);
- ret = -1;
+ ret = status_code;
goto done;
}
@@ -813,7 +816,24 @@ static int lbs_try_associate(struct lbs_private *priv,
goto out;
ret = lbs_associate(priv, assoc_req, CMD_802_11_ASSOCIATE);
+ /* If the association fails with current auth mode, let's
+ * try by changing the auth mode
+ */
+ if ((priv->authtype_auto) &&
+ (ret == WLAN_STATUS_NOT_SUPPORTED_AUTH_ALG) &&
+ (assoc_req->secinfo.wep_enabled) &&
+ (priv->connect_status != LBS_CONNECTED)) {
+ if (priv->secinfo.auth_mode == IW_AUTH_ALG_OPEN_SYSTEM)
+ priv->secinfo.auth_mode = IW_AUTH_ALG_SHARED_KEY;
+ else
+ priv->secinfo.auth_mode = IW_AUTH_ALG_OPEN_SYSTEM;
+ if (!assoc_helper_wep_keys(priv, assoc_req))
+ ret = lbs_associate(priv, assoc_req,
+ CMD_802_11_ASSOCIATE);
+ }
+ if (ret)
+ ret = -1;
out:
lbs_deb_leave_args(LBS_DEB_ASSOC, "ret %d", ret);
return ret;
diff --git a/drivers/net/wireless/libertas/dev.h b/drivers/net/wireless/libertas/dev.h
index 6977ee8..058d172 100644
--- a/drivers/net/wireless/libertas/dev.h
+++ b/drivers/net/wireless/libertas/dev.h
@@ -133,6 +133,7 @@ struct lbs_private {
u8 wpa_ie_len;
u16 wep_tx_keyidx;
struct enc_key wep_keys[4];
+ u8 authtype_auto;
/* Wake On LAN */
uint32_t wol_criteria;
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index cd8ed7f..0e24c96 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -831,6 +831,7 @@ static int lbs_init_adapter(struct lbs_private *priv)
priv->is_auto_deep_sleep_enabled = 0;
priv->wakeup_dev_required = 0;
init_waitqueue_head(&priv->ds_awake_q);
+ priv->authtype_auto = 1;
mutex_init(&priv->lock);
diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
index 71f88a0..aad6263 100644
--- a/drivers/net/wireless/libertas/wext.c
+++ b/drivers/net/wireless/libertas/wext.c
@@ -1440,8 +1440,10 @@ static int lbs_set_encode(struct net_device *dev,
set_bit(ASSOC_FLAG_WEP_TX_KEYIDX, &assoc_req->flags);
if (dwrq->flags & IW_ENCODE_RESTRICTED) {
+ priv->authtype_auto = 0;
assoc_req->secinfo.auth_mode = IW_AUTH_ALG_SHARED_KEY;
} else if (dwrq->flags & IW_ENCODE_OPEN) {
+ priv->authtype_auto = 0;
assoc_req->secinfo.auth_mode = IW_AUTH_ALG_OPEN_SYSTEM;
}
@@ -1620,8 +1622,10 @@ static int lbs_set_encodeext(struct net_device *dev,
goto out;
if (dwrq->flags & IW_ENCODE_RESTRICTED) {
+ priv->authtype_auto = 0;
assoc_req->secinfo.auth_mode = IW_AUTH_ALG_SHARED_KEY;
} else if (dwrq->flags & IW_ENCODE_OPEN) {
+ priv->authtype_auto = 0;
assoc_req->secinfo.auth_mode = IW_AUTH_ALG_OPEN_SYSTEM;
}
--
1.5.3.6
> Auto auth mode is enabled by default. If user doesn't specify the
> auth mode, while association driver will first try with open mode
> and then with shared key mode. If user specifies an auth mode,
> auto auth is disabled and driver will not try association with
> another auth mode.
I'd rather would like if you guys chime in into the cfg80211 port rather
than adding stuff to assoc.c and wext.c, which hopefully get's removed
really soon now.
As a side note: I'm now inclined to get rid of Libertas' proprietary mesh
support in the driver. I don't know no one except OLPC that uses it, and
even they don't seem work with upstream. For me, this mesh stuff is the last
obstacle for cfg80211 support in libertas.
Hi Bing,
> Auto auth mode is enabled by default. If user doesn't specify the
> auth mode, while association driver will first try with open mode
> and then with shared key mode. If user specifies an auth mode,
> auto auth is disabled and driver will not try association with
> another auth mode.
I agree with Holger that the conversion into being fully cfg80211
compliant is basically the only way to go forward. Especially since
Holger and Samuel are already have patches for it.
However from a different point, how can you try open mode first and
detect a failure. Isn't this suppose to be the other way around, try
shared first and then fall back to open?
Regards
Marcel
On Fri, 2010-02-26 at 14:21 +0100, Johannes Berg wrote:
> On Fri, 2010-02-26 at 14:08 +0100, Marcel Holtmann wrote:
>
> > However from a different point, how can you try open mode first and
> > detect a failure. Isn't this suppose to be the other way around, try
> > shared first and then fall back to open?
>
> No, why? If open doesn't get rejected, it should be ok to use.
Unless the AP filters by MAC address; some don't reject open auth in
this case they just accept the device. I too was under the impression
that it was shared first, open second. Since shared is much more likely
to get rejected.
Dan
On Fri, 2010-02-26 at 14:08 +0100, Marcel Holtmann wrote:
> However from a different point, how can you try open mode first and
> detect a failure. Isn't this suppose to be the other way around, try
> shared first and then fall back to open?
No, why? If open doesn't get rejected, it should be ok to use.
johannes
On Feb 26 2010, at 15:01, Dan Williams was caught saying:
> On Fri, 2010-02-26 at 12:10 -0800, Andrey Yurovsky wrote:
> > On Fri, Feb 26, 2010 at 4:55 AM, Holger Schurig
> > <holgerschurig at googlemail.com> wrote:
> > >> Auto auth mode is enabled by default. If user doesn't specify the
> > >> auth mode, while association driver will first try with open mode
> > >> and then with shared key mode. If user specifies an auth mode,
> > >> auto auth is disabled and driver will not try association with
> > >> another auth mode.
> > >
> > > I'd rather would like if you guys chime in into the cfg80211 port rather
> > > than adding stuff to assoc.c and wext.c, which hopefully get's removed
> > > really soon now.
> > >
> > >
> > > As a side note: I'm now inclined to get rid of Libertas' proprietary mesh
> > > support in the driver. I don't know no one except OLPC that uses it, and
> > > even they don't seem work with upstream. For me, this mesh stuff is the last
> > > obstacle for cfg80211 support in libertas.
<snip>
> > Perhaps the OLPC folks might want to fork the driver or maintain a
> > patch set for the XO-1 mesh features. Meanwhile we could all move on
> > and use cfg80211 and clean things up accordingly.
<snip>
> It might not be a bad thing to rip out the mesh stuff and add it later,
> but we do want to coordinate with OLPC folks as they are still the
> *largest user by far* of this driver. As in a million+ units.
As has been pointed out, the next-gen XO wireless FW does not have mesh
support; however, there are still plenty of end users and developers on
the existing XO-1 laptops and I don't think completely removing mesh
support is an option our community would be happy with. However, I also
don't want to end up with a libertas fork (all our mesh patches are
currently upstream and not forkd off) in the OLPC tree so let's figure
out a path to make this work for everyone.
It looks like there is already some work in progress towards mesh support
using cfg80211 [1] and if I can get pointers to the latest version, I can
point the OLPC community to them and see if we can find some testers.
> Is it seriously that large of a block? I thought we'd discussed a
> fairly viable plan for keeping mesh around while still doing cfg80211.
> Would shipping you a usb8388 dongle or two make it easier to work with?
Or a few XO-1 laptops? :)
~Deepak
> support is an option our community would be happy with. However, I also
> don't want to end up with a libertas fork (all our mesh patches are
> currently upstream and not forkd off)
Oh, sorry for being misinformed and spreading this misinformation. I had some
read-only variables in the mainline libertas driver (for example
mesh_autostart_enabled get's never written to) and heard that this is a
remnant, and that the real implementation in in the OLPC tree.
Therefore I thought that you're sticking to some older kernel, and not
following mainline linux at all.
Isn't that true?
--
http://www.holgerschurig.de
On Mar 02 2010, at 13:02, Holger Schurig was caught saying:
> > support is an option our community would be happy with. However, I also
> > don't want to end up with a libertas fork (all our mesh patches are
> > currently upstream and not forkd off)
>
> Oh, sorry for being misinformed and spreading this misinformation. I had some
> read-only variables in the mainline libertas driver (for example
> mesh_autostart_enabled get's never written to) and heard that this is a
> remnant, and that the real implementation in in the OLPC tree.
That is definitely a remnant of old work and our tree seems to have the
same read-only issues.
> Therefore I thought that you're sticking to some older kernel, and not
> following mainline linux at all.
We're currently on 2.6.31, which I guess is somewhat pre-historic by
kernel development standards. We do have some patches to Libertas which
were co-developed along with Marvell to fix some bugs we've discovered
during the XO-1.5 ramp up process and unfortunately we were on a really
tight release schedule and not all of those have been pushed upstream,
including some changes to the SDIO stack that were needed for proper
suspend/resume support on the gen 2 laptops. I'll be working on moving
our kernel up to a newer version and will send up any patches that
we need merged and will also work with our users to figure out what
to do about mesh testing.
~Deepak
--
"People think all we need to fix our predicament is a free source of
energy, but I think we need to change out behaviour. More energy would
just deplete the Earth's lifeblood faster." - Janine Benyius
On Wed, 3 Mar 2010, Deepak Saxena wrote:
> We're currently on 2.6.31, which I guess is somewhat pre-historic by
> kernel development standards. We do have some patches to Libertas which
> were co-developed along with Marvell to fix some bugs we've discovered
> during the XO-1.5 ramp up process and unfortunately we were on a really
> tight release schedule and not all of those have been pushed upstream,
> including some changes to the SDIO stack that were needed for proper
> suspend/resume support on the gen 2 laptops. I'll be working on moving
> our kernel up to a newer version and will send up any patches that
> we need merged and will also work with our users to figure out what
> to do about mesh testing.
The SdIO patches are in the -mm tree and going to be merged for 2.6.34.
Nicolas