Driver did not support SIOCSIWENCODEEXT
 

Hi.

I am trying to set up wpa encryption, and wpa_supplicant appears to set up, spits the line in the subject, and politely but firmly goes away.

I have the b43 driver which is supposedly wext compatible. I modified the stuff in wpa_supplicant docs for my system (broadcom 4312) and ran wpa_supplicant -dw -i wlan0 -Dwext -c /etc/wpa_supplicant.conf > wpa_debug 2>&1 to trap the output and investigate. dhcp times out waiting for an offer. I can ping the router, even enter setup on, but not get past it as far as my modem.

Is this a bug? Is there a workaround? I'm using
network={
scan_ssid=0
ssid=m-_essid"
proto=WPA
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40
psk="My_key"
#psk=MY-Key_according_to_wpa_passphrase
}

If I comment the short key it doesn't associate.

My kernel is 2.6.29.1 with the patch for 2.6.29.2. Without encryption, all is fine. I'm probably doing something wrong, but what?

Put your essid inside double quotes. Your file may not be parsed properly. You are missing the opening quote.

Don't use whitespace in your ssid. At least not in the first character.

If you use network-manager, your system may create a wpa_supplicant.conf on the fly from network settings such as /etc/sysconfig/networking/ifcfg-wlan0. If that is the case, either use your distro's network device configuration tool, or edit the file.
There may be a commented skeleton file, and a "man ifcfg" manpage.

You can monitor the association process using the wpa_cli program.
wpa_cli -p <path/to/wpa_supplicant/socket> -i wlan0

On my laptop "sudo /usr/sbin/wpa_supplicant -p /var/run/wpa_supplicant/ -i wlan0"

Thanks for the reply. The SSID was a typo in my post. But it was duplicated in the config file, and I removed one instance.




I have been running Slamd64, which doesn't have network manager. I tried beyond all sense to make network manager from source for Slamd64, but you need too many stupid libraries. But I also have a Fedora 9 installation - mainly for yum and the multimedia stuff. That has network manager, and after copying in the wpa_supplicant.conf file from Slamd64, that actually got online and am sending you this reply by wifi. I have very much the same kernel in both systems - 2.6.29.1. That kind of verifies the driver. In Fedora, however, I have always needed to start X to get online. Slamd64 does it through the rc scripts.

Slamd64 actually associates, but doesn't succeed with the 4 way handshaking and the output is confusing. I was using running wpa_supplicant in debug and then running the rc script. They seemed to nuzzle up to each other, shake hands extensively, then I saw that error, and they politely but firmly parted after that. I really wanted to know that the driver was or was not the issue, and You have me proving that to myself :-/. I will try that wpa_cli and see what is actually bellyaching.

A bit further along, but no joy in slamd64. I tried to do a comparison between systems but ended up needing nerve tablets :-/. Fedora has wpa-supplicant-0.6x which is a major switch from slamd64's 0.5x version.
wpa_cli did not seem to give enough information. So I used wpa_supplicant -dddw -iwlan0 -Dwext -c/etc/wpa_supplicant.conf > file 2>&1. I get

lines 1-3:
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 4 value 0x0 - ioctl[SIOCGIWSCAN]: Resource temporarily unavailable
ioctl[SIOCSIWMODE]: Device or resource busy

Up around line 190 this section looks bad
State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE
RX EAPOL from 00:22:b0:90:0b:4b
RX EAPOL - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 00 0d 34 78 ea 11 0a 70 ef 1e 95 e5 2f ba 4c e8 e8 c
3 37 f9 26 26 a4 79 39 8e 90 27 8f 6b 0e 97 94 10 37 f9 26 26 a4 79 39 8e 90 27 8f 6b 0e 97 94 17 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 67 55 a7 4d 0d 05 5f 48 2c 3a 45 7b 11 04 8d 69 00 20 ea 56 4c 5d 87 75 ce 4e 78 4c ac a6 da aa 30 93 dc ed e4 8a 19 b5 ef f2 29 ed b5 69 a8 a7 88 82
IEEE 802.1X RX: version=1 type=3 length=127
EAPOL-Key type=254
key_info 0x391 (ver=1 keyidx=1 rsvd=0 Group Ack MIC Secure)
key_length=32 key_data_length=32
replay_counter - hexdump(len=8): 00 00 00 00 00 00 00 0d
key_nonce - hexdump(len=32): 34 78 ea 11 0a 70 ef 1e 95 e5 2f ba 4c e8 e8 c3 37 f9 26 26 a4 79 39 8e 90 27 8f 6b 0e 97 94 10
key_iv - hexdump(len=16): 37 f9 26 26 a4 79 39 8e 90 27 8f 6b 0e 97 94 17
key_rsc - hexdump(len=8): 43 00 00 00 00 00 00 00
key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00
key_mic - hexdump(len=16): 67 55 a7 4d 0d 05 5f 48 2c 3a 45 7b 11 04 8d 69
WPA: RX EAPOL-Key - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 00 0d 34 78 ea 11 0a 70 ef 1e 95 e5 2f ba 4c e8 e8 c3 37 f9 26 26 a4 79 39 8e 90 27 8f 6b 0e 97 94 10 37 f9 26 26 a4 79 39 8e 90 27 8f 6b 0e 97l2_packet_receive - recvfrom: Network is down
l2_packet_receive - recvfrom: Network is down
l2_packet_receive - recvfrom: Network is down
ioctl[SIOCSIWENCODEEXT]: No such file or directory
ioctl[SIOCSIWAUTH]: Operation not supported

and down near line 276RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
RTM_NEWLINK: operstate=1 ifi_flags=0x1002 ()
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
CTRL-EVENT-TERMINATING - signal 2 received
Removing interface wlan0
State: COMPLETED -> DISCONNECTED
wpa_driver_wext_set_operstate: operstate 1->0 (DORMANT)
WEXT: Operstate: linkmode=-1, operstate=5
wpa_driver_wext_deauthenticate
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
Driver did not support SIOCSIWENCODEEXT
EAPOL: External notification - portEnabled=0
EAPOL: SUPP_PAE entering state DISCONNECTED


Now I wasn't handing out any signal 2 and really don't understand what is going wrong. As soon as I tried to configure Fedora manually, wifi vanished altogether, but that's nearly the rule there. Network Manager evidently calls wpa_supplicant with a command line as long as your arm. Anyhow, I want to use Slamd64.

googling that SIOCSIWENCODEEXT leads me all over the place. "You shouldn't be getting that error" seems a typical response :-/.

The only things I got from Googling for SIOCSIWENCODEEXT is that it has been in the code for a long time (as in you shouldn't have problems with using it, not that that helps you), that WPA-PSK+TKIP relies on it (I don't know if testing any non-TKIP scheme is feasible) and a few posts about problems with certain wpa_supplicant versions. Sorry I can't be of more help. Did you by any chance try their mailing list?

Thanks.

I came away from google thinking everyone got out of this by updating, or using the hostap driver. So I updated: Update slackware type package tools to handle their .txz format. Update wpa_supplicant (version 0.6.9 vs 0.5.1). Find libnl.so because something was bellyaching about it in startup messages. Now when I call wpa_supplicant it throws up a list of commands - what I am allowed to say. I say that, and it still seems to fart about and do nothing. But it doesn't like running from a script.

NOW, booting up throws up the list of wpa_supplicant commands, followed by an infinite error loop as something can't find the socket and complains... and complains... and complains... and complains :-/.

I'm going to find that (Probably a permissions thing or else something stupid like a changed option) and then if I can't get on, I will post _with_ passphrases. Once I'm sorted, I can change them again.

Yes, probably something (relatively) simple (often hard to spot ;-p). Check the Changelog and review your commandline args? Else if nothing works you could post wpa_.* error output but please use BB code tags for readability.

I'm far enough along to realise I'm stuck :-(.
I am trying this in one terminal:
wpa_supplicant -dW -Dwext -iwlan0 -c /etc/wpa_supplicant.conf > debug_wlan0 2>&1

It sits there waiting for activity on wlan0. I then run
/etc/rc.inet1 restart to restart all the network stuff. wpa_supplicant is promptly killed, but I restart it. It goes through the standard meaningless setup errors which always existed, and then throws up a page of wpa_supplicant commands, starts dhcp, broadcasts a request, never sees the ack, and times out with no chat. debug_wlan0 is empty :-o, which tells me it's not picking up wlan0, despite the fact that rc.inet1 checks to see if it is running before calling it.

So much for updating my way out of it. I will regress and try later

One last hack: remove wpa_supplicant (all versions) & reinstall one version (each one, in turn).

I am getting no sense. If I put in the right options it goes wrong. If I start the new wpa_supplicant in advance it doesn't find wlan0. With the old wpa_supplicant, I can get this output in a console with wpa_supplicant-0.5.1 in the foreground. wpa_supplicant-0.6.9 returns an empty file.

bash-3.1$ cat /tmp/debug_wlan0
ioctl[SIOCSIWMODE]: Device or resource busy
ioctl[SIOCSIWAUTH]: Operation not supported
WEXT auth param 4 value 0x0 - bash-3.1$

Slackware's scripts have
1. rc.inet1 a master network script
1a. rc.wireless.conf - settings for all nics

2. rc.wireless a wireless script
2a. rc.wireless.conf

3. /etc/wpa_supplicant.conf

rc.wireless and rc.inet1.conf both set the same variables but things are done this way, they explain, so you can have a number of different wireless nics doing different things. Frankly, I don't believe them. But I'm too near signing myself into a home for the bewildered to worry about it any more. Thanks for your help, Unspawn

I'm sorry I couldn't have been of more help.

Thanks, Unspawn, but you were more help than you realise. Your remark about some stupid thing in the scripts set me thinking. So I moved aside rc.wireless, rc.wireless.conf, rc.inet1 & rc.inet1.conf and reinstalled. rc.wireless.conf is actually a misnomer, as the info in rc.inet1.conf overwrites it. Once I realised that, I could forget rc.wireless & rc.wireless.conf. So I redid everything, down to opening hexedit on a program and taking a fresh chunk of hex as the password.
I diffed the scripts later. rc.wireless.conf had changed, and apparently I had hacked rc.wireless in some previous battle with wifi. Now hexedit on a program is not perfect as password generation, but it's good enough. Anyhow, encryption came up first time, and I can finally obey the first rule of repairing technology: "If it works _don't_fix_it!"

Having said that, there is a debug option which gives you data when it's running the rc scripts manually, and it does complain
/etc/rc.d/rc.inet1: wlan0 information: 'Fill with your own settings...'
Error for wireless request "Set Nickname" (8B1C) :
SET failed on device wlan0 ; Operation not supported.
Error for wireless request "Set NWID" (8B02) :
SET failed on device wlan0 ; Operation not supported.

(The above always appear, and in fedora as well but the thing works with those errors)
wlan0 no private ioctls.

wlan0 no private ioctls.

wlan0 no private ioctls.

Polling for DHCP server on interface wlan0:
Broadcasting DHCP_DISCOVER (And they argue lengthily over dhcp)

I think if I find it I'll turn debug OFF :-D.