ndiswrapper + wpa_supplicant
Thu Dec 6 04:03:34 PST 2007
On Thu, 2007-12-06 at 07:49 -0400, George N. White III wrote:
> On Dec 5, 2007 11:17 AM, Dan Williams <dcbw at redhat.com> wrote:
> > On Wed, 2007-12-05 at 11:09 -0400, George N. White III wrote:
> > > On Dec 5, 2007 10:25 AM, Sukku <m.sukumar at gmail.com> wrote:
> > > > Hi All,
> > > >
> > > > From last two weeks, I am working on this problem. I am working on FC8 with
> > > > kernel version 126.96.36.199-42.
> > > >
> > > > I am using Linksys wireless adapter (WUSB54G). I didn't found any linux
> > > > drivers for this device. so by using ndiswrappers I installed windows native
> > > > drives in linux box. finally adapter got detected.
> > > >
> > > > after words I try to use this wpa_supplicant on this adapter. Hear I am
> > > > facing problem
> > > >
> > > > In debugging mode I am getting so many IOCTL errors. I am not getting,
> > > > there errors are from ndiswrapper or wpa_supplicant.
> > >
> > > I saw those errors, and failed to connect, also using FC8 with a ndiswrapper
> > > but a different USB dongle (TEW). However, NetworkManager is more or
> > > less working (too frequent disconnects from my AP, connects to random
> > > open AP's). Check that there isn't a 2nd copy of wpa_supplicant running.
> > NM itself will only ever connect to an AP that you've chosen from the
> > menu.
> > If you've never chosen that AP from the menu, it's important to remember
> > that the driver and/or firmware also control roaming, and that
> > often-times the driver/firmware will decide to associate to an access
> > point without being told to so (ipw* does this a lot). Some drivers
> > have module options to disable that functionality, and the only real
> > arguments I've heard for this behavior are that people alone in the
> > woods then don't need to issue manual iwconfig commands when they start
> > their computer up. I'm not sure what the security implications of the
> > card connecting to a random open AP are, but it can't be much good.
> All true. There are several issues here:
> 1. ndiswrapper doesn't have module options to disable association with
> open access points. Module writers should ensure that the default is to
> disable this.
Yep, I agree. It may not be possible to change existing drivers to do
this (unless people start yelling about security), but new drivers
should certainly respect this.
> 2. Iwlist wlan0 scan often shows multiple "dlink" AP's, but only
> one "dlink" appears in the NetworkManager list. Even if I give my AP a name,
> an evil perp could use the same name and NM might well use that AP.
> NM needs a way to present multiple AP's with the same name.
With 0.7, the applet will only combine SSIDs that have the same mode
(infra/adhoc), band (a/bg), and security settings (none/wep/wpa/wpa2).
If there are, say, two linksys access points, both with WEP and both on
channel 11, the applet will certainly combine those APs. NM itself
always presents each AP split out via the D-Bus interface. UI bits are
responsible for combining (or not) the results.
You simply cannot fix this situation at all unless you start displaying
BSSIDs in the menu. We know what a BSSID is, but I have no clue what my
AP's BSSID is right now, and I just don't care. Nor do 90% of users.
The nm-applet won't be showing each separate BSSID in the menu, but
you're certainly welcome to write your own tool that shows each BSSID
and allows you to select the exact one you want using the NM D-Bus
> 3. it is easy, e.g., in NetworkManager, to accidentally select the wrong AP
> (poor hand-eye coordination, jerky mouse on a busy system, screen updates
> just as you click).
The menu in the gnome applet doesn't dynamically update the menu though,
so that shouldn't be a problem.
> This says there is a need for a mechanism to remove an AP from NM's list,
> and probably also a way to list AP's that should never be used.
There are two things we're going to do for removing APs:
1) Provide the ability to flip the autoconnect bit from the notification
2) Provide the connection editor to allow you to remove connections
(already almost working)
More information about the Hostap