LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Larry Finger <larry.finger@lwfinger.net>
To: Jouni Malinen <jkm@devicescape.com>
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: Tue, 30 Jan 2007 20:35:18 -0600	[thread overview]
Message-ID: <45C00066.80807@lwfinger.net> (raw)
In-Reply-To: <20070130225641.GH32304@instant802.com>

Jouni Malinen wrote:
> On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote:
> 
>> Any AP with a hidden SSID will only respond to probe requests that specify its SSID, and will ignore
>> any other probes. In addition, the response will have an empty SSID field. These responses are the
>> only ones in which a substitution would occur. These are the same responses where the current code
>> sends back the "<hidden>" pseudo-SSID. My change would put the correct one there.
> 
> Is the SSID from the probe response really used here? Your patch did not
> look like that.. The SSID from the last scan request command may not be
> the one that triggered the last scan (e.g., one could request a new scan
> without specifying an SSID).

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.
> 
>> We aren't guessing. The response frame with the empty SSID field must have come from the AP with the
>> SSID we want. Filling in the expected value is just making it easier for the user-space tools.
> 
> I don't see how the proposed patch would be using the correct SSID value
> in all cases. Especially cases where there are multiple APs using hidden
> SSIDs, but with different real SSID values and cases where multiple scan
> requests are being processed would be likely to leave windows open for
> reporting incorrect SSID.

I can think of one instance where the wrong value could be reported. That is if some other STA
probes a different hidden AP just when we have sent a probe request. For WPA this should not cause a
problem as wpa_supplicant will sort that out while authenticating.

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

Larry





  reply	other threads:[~2007-01-31  2:35 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 [this message]
2007-02-01 18:46                     ` Jouni Malinen
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=45C00066.80807@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=dcbw@redhat.com \
    --cc=jkm@devicescape.com \
    --cc=johannes@sipsolutions.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).