# >=2.6.34-gentoo-r1 + ath5k + wpa_supplicant = (solved)

## gr0x0rd

I've spent the last few hours trying to get my wireless interface up and running with kernel 2.6.34-gentoo-r1. I've had this card working fine with wpa_supplicant since 2.6.31-gentoo-r6, but after this kernel upgrade, it times out during bootup and is unable to bring up the carrier. Revert back to an earlier kernel version and it works fine. Some background:

lspci -v

```
07:01.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)

   Subsystem: D-Link System Inc Device 3a1b

   Flags: bus master, medium devsel, latency 168, IRQ 16

   Memory at fbef0000 (32-bit, non-prefetchable) [size=64K]

   Capabilities: [44] Power Management version 2

   Kernel driver in use: ath5k

   Kernel modules: ath5k

...
```

Spiffy.

ifconfig wlan0 up && ifconfig

```
wlan0     Link encap:Ethernet  HWaddr 00:17:9a:01:bd:c0  

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
```

Jolly good. So...

wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf

```
ioctl[SIOCSIWPMKSA]: Invalid argument

ioctl[SIOCSIWMODE]: Invalid argument

Could not configure driver to use managed mode

ioctl[SIOCGIWRANGE]: Invalid argument

ioctl[SIOCGIWMODE]: Invalid argument

ioctl[SIOCSIWAP]: Invalid argument

ioctl[SIOCSIWESSID]: Invalid argument

ioctl[SIOCSIWENCODEEXT]: Invalid argument

ioctl[SIOCSIWENCODEEXT]: Invalid argument

ioctl[SIOCSIWENCODEEXT]: Invalid argument

ioctl[SIOCSIWENCODEEXT]: Invalid argument

ioctl[SIOCSIWPMKSA]: Invalid argument

ioctl[SIOCGIWSCAN]: Invalid argument

ioctl[SIOCSIWSCAN]: Invalid argument

Failed to initiate AP scan.
```

God damnit!

iwlist wlan0 scan

```
wlan0     Interface doesn't support scanning.
```

Well ain't that a kick in the junk!

I've tried getting the card to take to the ath9k driver or module, and likewise with the basic ath driver or module, and no love there. I also tried nixing the module and trying using the in-kernel driver exclusively, but got the same result. So... think something changed with the ath5k driver since the last [working] kernel release?

ls -al /lib/modules/2.6.32-gentoo-r7/kernel/drivers/net/wireless/ath/ath5k/

```
-rw-r--r-- 1 root root 126845 Jun  2 13:57 ath5k.ko
```

ls -al /lib/modules/2.6.34-gentoo-r1/kernel/drivers/net/wireless/ath/ath5k/

```
-rw-r--r-- 1 root root 122031 Aug 19 16:00 ath5k.ko
```

Yep. Something different there all right.

 I also tried using a previous kernel module in the place of the current one, but the kernel is way too smart for that  :Smile:  Does anyone have any suggestions, other than wait for the next kernel version?

----------

## krinn

 *gr0x0rd wrote:*   

>  I also tried using a previous kernel module in the place of the current one, but the kernel is way too smart for that 

 

because of kernel module version. But if the module itself change, maybe it still didn't change how it interact with the kernel.

If it's the case you can build your own kernel source with a 2.6.34 and put ath5k from 2.6.32 in there, replacing the 2.6.34 sources.

This way your module will be build against the 2.6.34 with the same source as the 2.6.32.

As i said just upper, won't work if the interact with kernel change, in this case best case would be module showing unresolved symbols and worst kernel refuse to build  :Smile: 

But it should work, i don't think the sources are tagged for a specific kernel versions themselves, else nvidia-drivers and the like would have a real hard task to work with many kernel versions.

You can also build a vanilla 2.6.34 with CONFIG_MODVERSIONS=y, so you can try use the 2.6.32 module with the 2.6.34, you will still could fail with unresolved symbols because of the module but also unresolved symbols because of newer ones in the 2.6.34, less freaky, less chance it work

You will of course loose update from the 2.6.34 module, but i suppose you knew it already (still, can't kill you to check changelog to see what they update on it, it's a module for network, so minimum security check should be taken)

As usual, backup, blahblah...

----------

## gr0x0rd

That sounded so crazy I just had to try it. Backed up the /usr/src/linux/drivers/wireless directory, deleted all the .o and .ko files from the ath and ath5k folders, and overwrote all of the .c and .h files in those folders with source from the previous kernel version.

```
CC      drivers/net/wireless/ath/regd.o

drivers/net/wireless/ath/regd.c: In function 'ath_regd_init_wiphy':

drivers/net/wireless/ath/regd.c:453: error: 'struct wiphy' has no member named 'strict_regulatory'

drivers/net/wireless/ath/regd.c:461: error: 'struct wiphy' has no member named 'custom_regulatory'

drivers/net/wireless/ath/regd.c:462: error: 'struct wiphy' has no member named 'strict_regulatory'

make[4]: *** [drivers/net/wireless/ath/regd.o] Error 1

make[3]: *** [drivers/net/wireless/ath] Error 2

make[2]: *** [drivers/net/wireless] Error 2

make[1]: *** [drivers/net] Error 2

make: *** [drivers] Error 2
```

Bummer! They added debugging support in the new version and I guess there are just too many changes to get it to compile without going through the code itself. That sounds like work, and I'd rather have a beer.  :Smile: 

Thanks for the suggestion though! Loved the approach! I thought I'd try enabling the debug support to see if I could get anything. Here are the relevant items in dmesg:

```
[    3.895811] ath5k 0000:07:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16

[    3.895837] ath5k 0000:07:01.0: registered as 'phy0'

[    4.487041] ath: EEPROM regdomain: 0x10

[    4.487042] ath: EEPROM indicates we should expect a direct regpair map

[    4.487044] ath: Country alpha2 being used: CO

[    4.487045] ath: Regpair used: 0x10

[    4.487509] ath5k phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45)

[   69.454389] Modules linked in: cifs fuse coretemp adt7475 hwmon_vid i2c_dev vboxnetadp vboxnetflt vboxdrv nvidia(P) i2c_i801 ath5k
```

----------

## paulusbrand

I had a lot of problems with the 2.6.34 version too. I have a 5001 card in my eeepc. Try the 2.6.35 kernel, works without any problem for me. I didn't compile as module, but that probably doesn't make a difference.

----------

## kwesadilo

I have the same problem as you with an AR5212 card. However, this is my first Gentoo install, and the last time I had it working properly (excluding live CDs) was with Ubuntu 9.10, probably kernel version 2.6.32. I just clicked a box telling it to use ath5k, so I don't have much useful information about the working setup.

I was able to connect to an unsecured wireless network using the net-wireless/iw package. I want to use a WPA2 network, so I need wpa_supplicant, but when I use wpa_supplicant, I get the same ioctl garbage as you. I was able to get a slightly less horrifying failure indication from wpa_supplicant by forcing it to use the nl80211 driver, as in wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf. More details are available at the thread I created.

Hopefully, this information, if you have not already seen it, will nudge you in the right direction. Then, I can ride in your wake when you reach cruising speed.

----------

## gr0x0rd

kwesadilo said: *Quote:*   

> slightly less horrifying failure indication

 Dude that is frickin hilarious.  :Smile: 

Unmasked 2.6.35-r1 and emerged it... did a make oldconfig and the kernel couldnt mount my root filesystem! The linux gods definitely don't wan't me using this wireless card anymore, that's for sure. Will try 2.6.35 later today if I have time.

----------

## paulusbrand

Oldconfig doesnt work between 2.6.34 and 2.6.35. You have to select your sata drivers in 2.6.35.

----------

## gr0x0rd

Thanks- gotta love those little kernel upgrade nuances...

Anyway, up and running with 2.6.35-r1, and the driver behaves in the exact same way. Using some of the info in kwesadilo's thread, I was able to connect to a WEP network using iw after changing my router settings. Sadly, I can't leave it that way though.

So, it looks like the issue is between the new ath5k driver and WPA-supplicant... changing thread title to reflect this.

OK! We have a solution! 

kwesadilo said: *Quote:*   

> I changed my kernel config so that Networking->Wireless->cfg80211 wireless extensions compatibility (CFG_80211_WEXT) was enabled. ... I also enabled Wireless extensions sysfs files below it in case that was useful.

 

That did it for me, as soon as I enabled that in my kernel, wpa_supplicant fired right up with the ath5k driver. Thanks dude!

----------

## gr0x0rd

* thread update! *

After updating to kernel 2.6.34-r6 using one of Pappy's kernel seeds, I couldn't get the ath5k components in the atheros wireless tree portion of the config to show up until I enabled  <*>   Generic IEEE 802.11 Networking Stack (mac80211) in the Networking Support -> Wireless section!

----------

## Lupusceleri

Oh yeah, bumping this baby.

Specifying -Dnl80211 instead of -Dwext did the trick for me on a rt61pci based card.

For some reason they must have changed stuff with the drivers last kernel release, because I seem to recall it working fine on 2.6.34...

Now I tried the CFG_80211_WEXT=y trick, and this enabled me to use -Dwext instead of -Dnl80211. I'm going to be editing the rt61pci wiki article to reflect the funny ninjachange, perhaps you guys could do the same for your cards?  :Smile: 

PS: gr0x0rd, that chicken cracks me up.

----------

## chithanh

Actually nl80211 is the replacement for wireless extensions and should be used where possible. net-wireless/iw supports nl80211 (net-wireless/wireless-tools doesn't). However, there are a few issues with Gentoo net script still.

----------

