Re: iwlwifi3945 and WPA-EAP LEAP

[Dan Williams <dcbw redhat com>]

On Wed, 2008-01-09 at 12:01 -0500, Ryan Novosielski wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dan Williams wrote:
> > On Wed, 2008-01-09 at 10:57 -0500, Ryan Novosielski wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Has anyone gotten the combination of iwlwifi3945 working for LEAP on WPA
> >> Enterprise? My ipw3945 does work in this setup, however the other one
> >> does not. The only other negative to iwlwifi is that it does not operate
> >> my LED on my Dell. However, this driver solves a nasty crash on this HW.
> >>
> >> Anyone have any ideas? I haven't really tried it by hand with
> >> wpa_supplicant, but I wanted to see if anyone had any experience first.
> > 
> > (Ryan said the network is hiding the SSID)
> 
> Whoops! Clicked the wrong reply button! Thanks, Dan.
> 
> > Ok; this is a driver/kernel bug such that there is not enough
> > information for NetworkManager to be able to tell the driver how to find
> > your hidden SSID.  ipw3945 handles this, but the new iwl3945 does not.
> > I've submitted a patch for 2.6.25 that is easily backported to earlier
> > kernels that will allow NetworkManager to find out the necessary
> > information (ie, whether or not the driver supports SSID-specific
> > scans), and I'll be modifying NetworkManager use this information to fix
> > hidden SSID support.
> 
> Have you received any feedback from the kernel group on whether or not
> this has been accepted? I wish personally that Ubuntu made it easier to
> rebuild a kernel using their source packages, but this is a gripe for
> another crowd. :)

Yes, the patch will be going upstream and is scheduled for 2.6.25.  It's
something that distros should backport if they want better hidden SSID
handling.

The hack that Ubuntu currently does is to special-case driver names and
send ap_scan=1 or 2 depending on the driver name.

> > The core issue is that some drivers need ap_scan=1+scan_ssid=1 when
> > driven by wpa_supplicant, and others need ap_scan=2 [1].  There is no
> > way to determine which you need except strcmp()-ing the driver name,
> > which is just plain evil.  The kernel patch will allow NM to handle this
> > situation in the correct manner.
> 
> I know NetworkManager is supposed to be a "just works" method, but isn't
> there some way that some of these things could be snuck in there? I know
> that this is not currently possible, but it would be nice to be able to
> set these little options manually if you KNOW that you need them.
> Presently, there's no way, yes?

Well, NM walks a fine line between hacking around broken stuff and
wielding the cluebat to force drivers to be better.  If we just worked
around stuff, nothing would get better and drivers' implementations of
WEXT would still be a huge mess.  I like to keep the upstream NM sources
clean of such hacks, and let the distros themselves do what they need to
do to make stuff work.

For Fedora, for example, I'm going to push out the NM update that
recognizes the new scan capabilities, and I'm going to work with the
Fedora kernel wireless maintainer to backport the kernel scan capability
patch, which should fix the problem for Fedora users.  For other
distros, they will either have to do the same, or else that distros
package maintainer will have to patch NM to do driver matching like some
currently do.

Dan

> > Dan
> > 
> > [1] my assertion is that all drivers must support ap_scan=2, but
> > mac80211-based drivers do not currently handle this well.  So in reality
> > it's purely a kernel/driver bug, but something that NM will have to work
> > around.
> 
> Thanks!
> 
> - --
>  ---- _  _ _  _ ___  _  _  _
>  |Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Systems Programmer II
>  |$&| |__| |  | |__/ | \| _| |novosirj umdnj edu - 973/972.0922 (2-0922)
>  \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHhP4Dmb+gadEcsb4RAkr+AJ4iWoXHKQbg+6bC5f9PPCZRzKx/7wCg45XV
> +VHzXBBm7lbmzVqK9jeUifk=
> =oeJ5
> -----END PGP SIGNATURE-----