ndiswrapper + wpa_supplicant

[George N. White III]

On Dec 6, 2007 3:54 AM, Sukku <m.sukumar at gmail.com> wrote:

> Hi George and Dan,
>
> First of all thank you very much for your replay.
>
> I tried with NetworkManager also.. with NM also I didn't get successes.
>
> In var/log/messages I am getting this logs:
>
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'ssid' value
> 'test1'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'key_mgmt'
> value 'WPA-EAP'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'identity'
> value 'default'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'password'
> value '<omitted>'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'eap' value
> 'LEAP'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'proto' value
> 'WPA RSN WPA RSN'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'pairwise'
> value 'TKIP CCMP TKIP CCMP'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Config: added 'group' value
> 'WEP40 WEP104 TKIP CCMP WEP40 WEP104 TKIP CCMP'
> Dec  6 12:44:14 sukumar NetworkManager: <info>  Activation (wlan0) Stage 2
> of 5 (Device Configure) complete.
> Dec  6 12:44:14 sukumar NetworkManager: <info>  (wlan0) Supplicant interface
> state change: 0 -> 2
> Dec  6 12:44:39 sukumar NetworkManager: <info>  Activation (wlan0/wireless):
> association took too long, asking for new key.
> Dec  6 12:44:39 sukumar NetworkManager: <info>  (wlan0) Supplicant interface
> state change: 2 -> 0
> Dec  6 12:44:44 sukumar NetworkManager: <WARN>  get_secrets_cb(): Couldn't
> get connection secrets: applet.c.2997 (get_secrets_dialog_response_cb):
> canceled.

I don't recall seeing this, but it looks bad.   When NM first connects
to a new AP that
needs a "secret", it should ask for one, which gets stored in your
Gnome keyring.  You
can verify the entries using gnome-keyring-manager.  Many people find
that NM will ask for the "secret" again after a disconnect.  I find
that entering
the secret here doesn't help -- I have to rmmod ndiswrapper, wait for
the scan to
succeed, and then NM will let me choose the AP and connect.

> Dec  6 12:44:44 sukumar NetworkManager: <info>  Activation (wlan0) failed
> for access point (Neolinksys)
> Dec  6 12:44:44 sukumar NetworkManager: <info>  Marking connection 'Auto
> Neolinksys' invalid.
> Dec  6 12:44:44 sukumar NetworkManager: <info>  Activation (wlan0) failed.
> Dec  6 12:44:44 sukumar NetworkManager: <info>  Deactivating device wlan0.
> Dec  6 12:44:44 sukumar NetworkManager: <info>  SWITCH: no current
> connection, found better connection 'Auto Ethernet (eth0)
>
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Config: added 'ssid' value
> 'test2'
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Config: added 'key_mgmt'
> value 'WPA-PSK'
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Config: added 'psk' value
> '<omitted>'
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Config: added 'proto' value
> 'WPA RSN'
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Config: added 'pairwise'
> value 'TKIP CCMP'
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Config: added 'group' value
> 'WEP40 WEP104 TKIP CCMP'
> Dec  6 12:45:52 sukumar NetworkManager: <info>  Activation (wlan0) Stage 2
> of 5 (Device Configure) complete.
> Dec  6 12:45:52 sukumar NetworkManager: <info>  (wlan0) Supplicant interface
> state change: 0 -> 2
> Dec  6 12:45:52 sukumar avahi-daemon[1896]: Interface eth0.IPv4 no longer
> relevant for mDNS.
> Dec  6 12:45:52 sukumar avahi-daemon[1896]: Withdrawing address record for
> fe80::20c:29ff:fe9d:5560 on eth0.
> Dec  6 12:46:17 sukumar NetworkManager: <info>  Activation (wlan0/wireless):
> association took too long, asking for new key.
> Dec  6 12:46:17 sukumar NetworkManager: <info>  (wlan0) Supplicant interface
> state change: 2 -> 0
>
>
>
>
> As per my understating the problem will be "what ever the IOCTL commands
> generated by wpa_supplicant  are not understood by  ndiswrappered  drivers"

I don't see these on my system using NM, and I don't see them above.  NM
controls wpa_supplicant directly using dbus, and ignores the config file.
You can get more details in wpa_supplicant.log by writing a little wrapper
script to add debugging options, e.g., something along the lines:

# mv wpa_supplicant wpa_supplicant.bin
# cat <<EOF > wpa_supplicant
#! /bin/sh
# -dd -- lots of debugging messages
# -t -- timestamps
# -s -- use syslog
exec wpa_supplicant.bin -dd -t -s "$@"
EOF
# chmod +x wpa_supplicant

> To resolve this problem where I need to change the code. Plz help me.
>
> Thanks and regards,
> Sukumar
>
>
>
>
> On Dec 5, 2007 8:47 PM, 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 2.6.23.1-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.
> >
> > dan
> >
> >
> >
>
>
>
> --
>
> -------
> ????????.



-- 
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia