Re: Converting wpa_supplicat.conf to NetworkManager setup

[Dan Williams <dcbw redhat com>]

On Thu, 2008-03-13 at 17:15 -0400, Matt Lavin wrote:
> I'm using the madwifi drivers for my wireless card, and it could be
> that they don't properly implement the ap_scan functionality.

Well, if you cannot connect to a hidden SSID with ap_scan=2, then the
driver is technically not WEXT conformant.  Some drivers are, some are
not.  If the driver wants to support hidden SSIDs well, it needs to
either make ap_scan=2 behavior work (which in the driver means it needs
to scan for the SSID using probe requests when it gets a SIOCSIWESSID or
SIOCSIWBSSID call), or it needs to make ap_scan=1+scan_ssid=1 work _and_
say that it supports SSID scanning via the SIOCGIWRANGE call.  I'd guess
your madwifi doesn't support scan capabilities reporting via the
SIOCGIWRANGE call.

> In my case, the router doesn't broadcast the ssid, so scanning for it
> doesn't seem like it should be a requirement to connect.  Another 

Ah; but it is :)  When you use ap_scan=1 and scan_ssid=1, the driver
should send out a probe request for the specific SSID you wish to
connect to.  The AP is required to respond with a probe response
containing it's SSID, and then the supplicant can figure out what
capabilities the AP supports and do the right thing.  Many drivers will
do a probe scan when looking for the BSS to associate with anyway.

The driver needs details from the AP to be able to connect successfully;
stuff like supported rates, security parameters, etc.  If the driver
can't find that AP through a scan (possibly helped by probe requests for
the specific SSID), then it cannot connect.

> concern of mine is that when it does scan it takes quite a while for
> the scan results to come back, but when the ap_scan option is left 

If you have an a/b/g part, then it does take a long time to passively
scan the channels.  With the 2.4 and 5.8 bands combined, there are
something like 75 channels to scan, and you have to dwell on each
channel for a while listening for beacons.  If the card is doing an
active scan, it might be only 20 or 50ms per channel, but that still
adds up.

> out, the wpa_supplicant can connect to and authenticate with the
> router almost instantly.

That's because when the option is left out, ap_scan defaults to 1.
What's happening to you is that your driver isn't reporting scan
capabilities, therefore NM can't determine whether your driver will work
better with ap_scan=1 or ap_scan=2.

Dan



> On Thu, Mar 13, 2008 at 4:14 PM, Dan Williams <dcbw redhat com> wrote:
>         On Thu, 2008-03-13 at 14:18 -0400, Matt Lavin wrote:
>         > I've got a wpa_supplicat.conf file that can connect to my
>         wireless
>         > network, but I can't figure out how to make NetworkManager
>         use the
>         > same settings.  My wpa_supplicat.conf file looks like this:
>         >
>         > # ap_scan=2
>         > network={
>         >     ssid="<my-ssid>"
>         >     proto=WPA2
>         >     key_mgmt=WPA-EAP
>         >     eap=TLS
>         >     identity="<my-id>"
>         >
>         > # scan_ssid=1
>         >     private_key="<my-key>"
>         >     private_key_passwd="<my-password>"
>         >     priority=1
>         > }
>         >
>         > I tried to setup a corresponding WPA2 Enterprise with the
>         fields as
>         > you would expect, but when network manager connects it adds
>         in the two
>         > commented lined above.  If I add those two lines to my
>         > wpa_supplicat.conf fie then I can't connect.  Does anybody
>         know how to
>         > make NetworkManager use my wpa_supplicat.conf file above?
>         
>         
>         This means your wireless driver does not support scan
>         capabilities, and
>         doesn't implement the WEXT specification correctly.  I'd ask
>         your distro
>         vendor to apply the scan capability patch to their kernel
>         (it's quite
>         small and low-impact and already in 2.6.24) and then you
>         should be fine.
>         
>         The problem is that NM cannot detect whether your driver has
>         the ability
>         to use ap_scan=1 or whether it must fall back to ap_scan=2.
>          Drivers
>         that do not work with ap_scan=2 are _broken_ by definition,
>         but this is
>         a workaround.
>         
>         Dan
>         
>         
>