LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Jouni Malinen" <jkm@devicescape.com>
To: Larry Finger <larry.finger@lwfinger.net>
Cc: Dan Williams <dcbw@redhat.com>,
	Johannes Berg <johannes@sipsolutions.net>,
	netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Hidden SSID's
Date: Thu, 1 Feb 2007 10:46:09 -0800	[thread overview]
Message-ID: <20070201184609.GE2652@instant802.com> (raw)
In-Reply-To: <45C00066.80807@lwfinger.net>

On Tue, Jan 30, 2007 at 08:35:18PM -0600, Larry Finger wrote:

> If one does the equivalent of 'iwlist eth1 scan essid myssid', then a probe response with
> NETWORK_EMPTY_ESSID set in the network flags will have 'myssid' returned in the SSID field of the
> returned buffer. If the input command were 'iwlist eth1 scan', then an empty SSID would be returned
> under the same circumstances. My code saves the SSID that is in the extra argument of the
> SIOCSIWSCAN call, and uses that in the SIOCGIWSCAN call.

Well, yes, but SIOCSIWSCAN and SIOCGIWSCAN calls are not in any way
linked together.. You could have two user space programs asking for a
scan of different SSID at more or less the same time and then have them
read the results with SIOCGIWSCAN. At this point, the SSID from the last
SIOCSIWSCAN would be returned for all APs that are in the scan list
without an SSID. This may not be the correct SSID and can produce quite
confusing results. I don't see this as an improvement over just removing
the "<hidden>" which will at least provide consistent results.

The proper fix for this is to use the information from the AP (Probe
Response frames) and create a local BSS list that has entries with SSID
updated from Probe Responses. If the underlying hardware/firmware does
not allow such handling, this kind of mapping of SSIDs from scan request
to scan results should probably in the hardware driver that would have
chance of mapping results from firmware to request for a given SSID. At
that point, it might be feasible to change the SSID in scan results, but
I see only problems for the case where this is done at higher layer.

> What is the method that should be used to associated with a given hidden AP?

The 802.11 stack should fill in the proper SSID data from Probe
Responses and maintain a local BSS list, i.e., the hidden APs would be
marked with proper SSID whenever Probe Responses are processed. See,
e.g., how driver/net/wireless/hostap/*.c use local->bss_list that will
be filled with information from both Beacon and Probe Response frames or
how wireless-dev.git net/d80211/ieee80211_sta.c handles updating of BSS
entry from both Beacon and Probe Response frames (i.e., do not allow
Beacon frames to replace data from Probe Response frames) in
ieee80211_rx_bss_info().

In other words, the hidden SSIDs are resolved in the BSS list based on
information from Probe Responses and user space programs will get proper
information in the scan results regardless of how the real SSID was
learned.

-- 
Jouni Malinen                                            PGP id EFC895FA

  reply	other threads:[~2007-02-01 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-27  3:48 Larry Finger
2007-01-27 12:08 ` Dan Williams
2007-01-27 15:29   ` Larry Finger
2007-01-28 21:28   ` Johannes Berg
2007-01-29 13:00     ` Dan Williams
2007-01-30  3:09       ` Jouni Malinen
2007-01-30  3:36         ` Dan Williams
2007-01-30  4:52           ` Larry Finger
2007-01-30  5:08             ` Jouni Malinen
2007-01-30  7:08               ` Larry Finger
2007-01-30 22:56                 ` Jouni Malinen
2007-01-31  2:35                   ` Larry Finger
2007-02-01 18:46                     ` Jouni Malinen [this message]
2007-01-28 22:18   ` Larry Finger
2007-01-30 22:53     ` Jouni Malinen

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=20070201184609.GE2652@instant802.com \
    --to=jkm@devicescape.com \
    --cc=dcbw@redhat.com \
    --cc=johannes@sipsolutions.net \
    --cc=larry.finger@lwfinger.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --subject='Re: Hidden SSID'\''s' \
    /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

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