ioctl[SIOCSIWENCODEEXT]: Invalid argument

Dan Williams dcbw
Tue Jul 27 18:19:40 PDT 2010


On Tue, 2010-07-27 at 20:44 +0200, Vladimir Botka wrote:
> On Tue, 27 Jul 2010 12:21:40 -0700
> Dan Williams <dcbw at redhat.com> wrote:
> 
> > On Tue, 2010-07-27 at 17:56 +0200, Vladimir Botka wrote:
> > > in openSUSE 11.3, kernel 2.6.34, wpa_supplicant reports
> > > "ioctl[SIOCSIWENCODEEXT]" [3] when used with ipw2200
> > > [2] driver and WEP. For the record I've opened bug on [1]. Disabling
> > > 802.11w didn't help. Any idea ?
> > > 
> > > [1] http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2236
> > 
> > It depends on what parameter wpa_supplicant is trying to set, and what
> > options are sent with that parameter.  If there's a chance you can
> > change and rebuild your wpa_supplicant, we can figure out what that
> > is. What configuration are you using?  Can you include the "-dddt"
> > logs from the supplicant so that we can see what the supplicant is
> > trying to do?
> > 
> 
> I'm using configuration [1]. Please find attached wpa_supplicant.log.
> Process was started from the command-line [2]. I'm not able
> to find reason why the "Association request " failed [3]. Also the AP

Probably because if the driver fails to set the key, the supplicant
shortens the time limit for association because the driver is probably
going to fail the assocaition request anyway.

> MAC before disassociation [4] looks bad. The same configuration works

That's how WEXT (the old kernel wireless API) signals a disassociation
event, or a failure to associate event:  all zeros.  Thats how we know
that the driver failed to talk to the AP.

I'm having some trouble duplicating your problem, but I'm able to get
associated with wpa_supplicant 0.6.8 and kernel 2.6.33.6 and kernel
2.6.34.1.  However, wpa_supplicant git does not work correctly for some
reason.

Try this:

rmmod ipw2200
modprobe ipw2200 debug=0xFFFFFFFF

and then let the supplicant run until you get a disassociation event or
two, then kill it, then reply with the 'dmesg' output so we can see what
the driver thinks its doing.

Dan


> Thank you,
> 
> 	-vlado
> 	Vladimir Botka
> 
> [1]
> # cat /etc/wpa_supplicant/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> ctrl_interface_group=wheel
> update_config=1
> 
> network={
>         ssid="vlado-test-ap1"
>         wep_key0=097d8252a2434dec1bbc6a5125
>         wep_tx_keyidx=0
>         key_mgmt=NONE
>         auth_alg=SHARED
> }
> 
> [2]
>  # wpa_supplicant -ieth1 -c /etc/wpa_supplicant/wpa_supplicant.conf -Dwext -f /var/log/wpa_supplicant.log -dddt 
> ioctl[SIOCSIWENCODEEXT]: Invalid argument
> ioctl[SIOCSIWENCODEEXT]: Invalid argument
> 
> [3]
> 1280255277.855591: State: SCANNING -> ASSOCIATING
> 1280255277.855613: wpa_driver_wext_set_operstate: operstate 0->0 (DORMANT)
> 1280255277.855621: netlink: Operstate: linkmode=-1, operstate=5
> 1280255277.855637: wpa_driver_wext_associate
> 1280255277.855653: wpa_driver_wext_set_drop_unencrypted
> 1280255277.855668: wpa_driver_wext_set_psk
> 1280255277.856079: Association request to the driver failed
> 
> [4]
> 1280255278.399536: Wireless event: cmd=0x8b15 len=20
> 1280255278.399547: Wireless event: new AP: 00:00:00:00:00:00
> 1280255278.399560: Disassociation notification





More information about the Hostap mailing list