Fix for topic: "Connected wireless once using WPA, cannot connect again"

[Dan Williams]

On Mon, 2007-01-15 at 17:11 -0500, Russell Harrison wrote:
> 
> 
> On 1/10/07, Dan Williams <dcbw at redhat.com> wrote:
>         Not entirely true; if you don't broadcast your SSID, then
>         wpa_supplicant
>         isn't necessarily able to determine your APs capabilities from
>         a scan,
>         and therefore isn't able to automatically set up the ciphers
>         that your 
>         AP supports, or other capabilities of the AP.
> 
> Except that you've already configured the SSID by hand so NM should
> have everything it needs to reconnect stored from the first time you
> manually connected.  If you're disconnected you should have everything
> you need to reconnect seamlessly. 

Because to associate with a hidden network, wpa_supplicant requires all
options to be set exactly as the AP requires.  Except that because you
are not broadcasting the SSID, NM has no idea what cipher types your AP
requires, and therefore doesn't know exactly what options to tell
wpa_supplicant to use for the connection Information Element.

NM currently provides "TKIP CCMP" as the cipher types regardless of
whether or not your AP supports both.  If you were broadcasting the
SSID, then wpa_supplicant would know from the scan results which cipher
types were suppported, and filter out the ones that weren't, and
continue with the connection.  But because it cannot find your AP, it
tries with both ciphers and if your AP is not configured to support both
the connection will fail.

The solution to this is to allow users to manually configure the
supported cipher types for their AP.  If a user or sysadmin insists on
making life hard, then that's their problem, and the life of the user
will be hard when they have to use their network.

This should work if your AP is stored, but it's a chicken/egg problem,
because to connect the first time you need the correct cipher types, and
since NM does not yet allow you to configure those ciphers, you cannot
connect, hence NM will not be able to cache the BSSID of the AP and
therefore will not be able to match that up with the scan results of the
hidden AP and therefore not be able to extract the correct cipher types.

> 
>         So basically, WPA + non-broadcasting SSID isn't going to work
>         reliably
>         until 0.7, where if you don't broadcast hte SSID, you'll have
>         to
>         manually configure your ciphers and other information before
>         NM will
>         allow you to connect.  That's just life.
> 
> What's different between 0.6.x and 0.7 allowing NM to handle hidden
> SSID's properly? 

A better configuration architecture that will allow things like manually
configured cipher types.

> 
>         Besides, non-broadcasting of SSIDs is pretty much useless
>         since your 
>         SSID is transmitted _in the clear_ whenever you attempt to
>         [re]associate
>         to the AP.  It's not really protection at all.
> 
> I won't argue the point.  However, many network managers do turn off
> SSID broadcasting simply because its an option to do so.  The fact it
> isn't any more secure is beside the point since there is a perception
> of increased security, even if its false. 

Yes, we have to accommodate non-SSID-broadcasting networks, and while
this works for WEP, it does not work for WPA.  NM and the config system
just aren't flexible enough for this in the current version.

Dan