On Mon, 2007-01-15 at 17:11 -0500, Russell Harrison wrote: > > > On 1/10/07, Dan Williams <[EMAIL PROTECTED]> 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 _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
