From: Dan Williams <dcbw@redhat.com>
To: Michael Wu <flamingice@sourmilk.net>
Cc: Hong Liu <hong.liu@intel.com>, Jiri Benc <jbenc@suse.cz>,
"John W. Linville" <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org
Subject: Re: [PATCH 3/5] mac80211: fix key restricted/open display
Date: Fri, 16 Mar 2007 23:46:17 -0400 [thread overview]
Message-ID: <1174103177.3026.8.camel@localhost.localdomain> (raw)
In-Reply-To: <200703161328.41006.flamingice@sourmilk.net>
On Fri, 2007-03-16 at 13:28 -0400, Michael Wu wrote:
> On Thursday 15 March 2007 23:28, Hong Liu wrote:
> > + if (erq->flags & (IW_ENCODE_OPEN | IW_ENCODE_RESTRICTED))
> > + if (sdata->type == IEEE80211_IF_TYPE_STA ||
> > + sdata->type == IEEE80211_IF_TYPE_IBSS)
> > + sdata->u.sta.auth_algs =
> > + (erq->flags & IW_ENCODE_RESTRICTED) ?
> > + IEEE80211_AUTH_ALG_SHARED_KEY :
> > + IEEE80211_AUTH_ALG_OPEN;
> > +
> This is not right because encrypted access points often do not require shared
> key authentication to associate. In fact, some cannot or refuse to use shared
> key authentication and your patch prevents retrying with a different
> authentication algorithm.
I think you're misreading the patch? It looks correct to me. The
second check for (erq->flags & IW_ENCODE_RESTRICTED) should ensure that
Shared Key is only selected when the userspace program requested it.
> IW_ENCODE_RESTRICTED simply means that the interface should not make/accept
> unencrypted connections. In client mode without wpa_supplicant, the AP
> selection code already refuses to select any APs without encryption enabled
> if the default key is set. In adhoc mode, there's no such check, but I'm not
> sure how much it matters.
Not quite. Somewhere along the line WEXT turned ENCODE_RESTRICTED into
the selector for Shared Key, while ENCODE_OPEN is Open System. Arguably
there's a larger need to specifying auth mode than rejecting unencrypted
associations. Most drivers do it this way, with the exception of
madwifi because they like to be irritatingly different. Nobody ever
really used the 'don't accept unencrypted' thing anyway in the old days,
plus ENCODEEXT has a separate flag for this.
So I think the patch is correct. Ideally all this gets fixed and all
the overloaded meanings go away with cfg80211 :)
Acked-by: Dan Williams <dcbw@redhat.com>
Dan
next prev parent reply other threads:[~2007-03-17 3:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-16 3:28 [PATCH 3/5] mac80211: fix key restricted/open display Hong Liu
2007-03-16 17:28 ` Michael Wu
2007-03-17 3:46 ` Dan Williams [this message]
2007-03-17 3:57 ` Michael Wu
2007-03-17 4:38 ` Dan Williams
2007-03-17 4:57 ` Michael Wu
2007-03-17 17:23 ` Dan Williams
2007-03-18 16:45 ` Jouni Malinen
2007-03-18 23:35 ` Dan Williams
2007-03-22 3:43 ` Hong Liu
2007-03-23 18:27 ` Jiri Benc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1174103177.3026.8.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=flamingice@sourmilk.net \
--cc=hong.liu@intel.com \
--cc=jbenc@suse.cz \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).