From: Dan Williams <dcbw@redhat.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: drago01 <drago01@gmail.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
Jouni Malinen <j@w1.fi>,
ipw3945-devel <ipw3945-devel@lists.sourceforge.net>,
Zhu Yi <yi.zhu@intel.com>
Subject: Re: mac80211 / iwl3945 + dynamic wep (again)
Date: Mon, 26 Nov 2007 11:04:24 -0500 [thread overview]
Message-ID: <1196093064.4202.46.camel@localhost.localdomain> (raw)
In-Reply-To: <1196079245.4149.255.camel@johannes.berg>
On Mon, 2007-11-26 at 13:14 +0100, Johannes Berg wrote:
> > what works:
> > connect to a hidden ssid with ap_scan=1 in wpa_supplicant.conf
> > what does not work:
> > connect to a hidden ssid with ap_scan=2 in wpa_supplicant.conf
> > ---
> > for non mac80211 drivers its the opposite ie. ap_scan=2 can connect to
> > hidden ssid while ap_scan=1 works
> > (thats also whats documented in the wpa_supplicant docs and what nm uses).
> >
> > so NM can't support mac80211 and non mac80211 drivers at the same time
> > without ugly hacks due to this issue.
>
> That's weird. But why does it use ap_scan=2 to start with? With
> mac80211, ap_scan=1 is *much* much better because it lets wpa_supplicant
> control much of roaming, mac80211 really is designed that way.
Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
use ap_scan=2.
There are a few problems here:
1) Historically, some drivers worked better with ap_scan=1 (madwifi),
others worked better with ap_scan=2 (many fullmac drivers)
2) scan_ssid=1 hasn't worked consistently on all drivers because it's
pretty new and many drivers don't support it yet. This is supposed to
make the driver/firmware send out probe request for the SSID in
question.
So basically, we're up shit creek without a paddle. You have to use
ap_scan=2 on some cards because they don't support specific-ssid
scanning (with scan_ssid=1) to find the BSS you want to connect to, but
some cards can handle ap_scan=1+scan_ssid=1 OK.
NM has logic to cache the BSSIDs of APs you've connected to before, and
to match those up with an SSID when it sees them in the scan list if the
AP isn't broadcasting the SSID. Unfortunately, that information isn't
available to wpa_supplicant because wpa_supplicant doesn't have an
interface to handle that sort of thing. Therefore, when faced with an a
request to connect to a hidden network, wpa_supplicant must rely
_entirely_ on the driver Doing The Right Thing with scan_ssid=1 or
ap_scan=2, and that almost never works due to inconsistency in driver
implementation.
Dan
> I don't see why ap_scan=2 doesn't work though, can you enable some
> wpa_supplicant debugging and send me the logs? Or can you turn off
> encryption and see if you can connect to a hidden SSID? I'd think it
> should work because we do a directed scan so the probe response should
> tell us the SSID.
>
> johannes
next prev parent reply other threads:[~2007-11-26 16:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-25 10:02 mac80211 / iwl3945 + dynamic wep (again) drago01
2007-11-25 10:49 ` Johannes Berg
2007-11-25 11:00 ` drago01
2007-11-26 12:14 ` Johannes Berg
2007-11-26 16:04 ` Dan Williams [this message]
2007-11-26 16:14 ` Johannes Berg
2007-11-26 16:50 ` drago01
2007-11-27 3:49 ` Jouni Malinen
2007-11-27 17:38 ` Dan Williams
2007-11-27 3:40 ` Jouni Malinen
2007-11-26 14:50 ` dragoran
2007-11-26 15:52 ` Johannes Berg
2007-11-26 16:51 ` drago01
2007-11-26 17:01 ` Johannes Berg
2007-11-27 3:34 ` Jouni Malinen
2007-11-28 14:06 ` drago01
2007-11-28 16:50 ` Johannes Berg
2007-11-28 19:45 ` dragoran
2007-11-28 19:47 ` Johannes Berg
2007-11-28 19:50 ` dragoran
[not found] ` <f6ca9fed0801110052ja95e86s9f1842846f0dd8fc@mail.gmail.com>
[not found] ` <1200068256.3861.172.camel@johannes.berg>
[not found] ` <f6ca9fed0801160208x40acfb91p8446298fda9e7726@mail.gmail.com>
2008-01-16 18:38 ` Johannes Berg
2008-01-17 15:38 ` drago01
2008-01-17 15:40 ` Johannes Berg
2007-12-03 10:14 ` Johannes Berg
2007-12-03 11:47 ` dragoran
2007-12-04 6:57 ` dragoran
2007-12-04 7:57 ` dragoran
2007-11-26 15:19 ` Dan Williams
2007-11-26 15:47 ` Johannes Berg
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=1196093064.4202.46.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=drago01@gmail.com \
--cc=ipw3945-devel@lists.sourceforge.net \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=yi.zhu@intel.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).