linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Dan Williams <dcbw@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	drago01 <drago01@gmail.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	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 19:49:34 -0800	[thread overview]
Message-ID: <20071127034934.GD5698@jm.kir.nu> (raw)
In-Reply-To: <1196093064.4202.46.camel@localhost.localdomain>

On Mon, Nov 26, 2007 at 11:04:24AM -0500, Dan Williams wrote:

> Because in the case of hidden SSIDs, wpa_supplicant pretty much says to
> use ap_scan=2.

Or ap_scan=1 with scan_ssid if and only if the driver supports it..

> 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.

This is not only a driver issue, though. I believe there are full MAC
cards that do not support scan request with a specific SSID and the only
way to make them work with hidden SSIDs is to try to associate with the
SSID (i.e., use ap_scan=2).

In theory, wpa_supplicant could try to figure out whether the scan with
a specific SSID works or not (though, this is not that easy to do since
old drivers are likely to just ignore the provided SSID and do a
wildcard scan) and if that is the case, start probing the network with
ap_scan=2 like behavior. This would mean that it would go through the
configured networks and try to associate with each that is enabled and
marked with scan_ssid=1. If association is completed successfully, the
network could be added to scan results (at this point, the driver would
also be more likely to actually include it in the scan results, so
proper data could now be available).

The main problem with this is that it can take quite long time to do
this kind of association probing just to be able to get scan results.
Furthermore, at least some cards may require a full match in security
parameters, i.e., each SSID could potentially require multiple
association attempts (assuming the network block was not configured with
explicit security parameters).

Taken into account how much I like hidden SSIDs, I would likely just
prefer to ignore the issue and try to make people use proper security
with visible SSIDs if they want to limit access to their network. Use of
hidden SSIDs is just plain horrible way of making clients suffer without
any level of increased security.

-- 
Jouni Malinen                                            PGP id EFC895FA

  parent reply	other threads:[~2007-11-27  3:50 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
2007-11-26 16:14         ` Johannes Berg
2007-11-26 16:50           ` drago01
2007-11-27  3:49         ` Jouni Malinen [this message]
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=20071127034934.GD5698@jm.kir.nu \
    --to=j@w1.fi \
    --cc=dcbw@redhat.com \
    --cc=drago01@gmail.com \
    --cc=ipw3945-devel@lists.sourceforge.net \
    --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).