# wireless init crashes machine :(

## KShots

OK, background:

lspci shows:

```
0000:00:09.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
```

Doing a little digging, that led me to install the madwifi-driver (net-wireless/madwifi-driver-0.1_pre20050420-r1).

lsmod shows that the modules are loaded:

```
ath_pci                53664  0

ath_rate_onoe           7112  1 ath_pci

ath_rate_amrr           7236  0

wlan_xauth              1408  0

wlan_wep                5888  0

wlan_tkip              10496  0

wlan_ccmp               6208  0

wlan_acl                3968  0

wlan                  107804  9 ath_pci,ath_rate_onoe,ath_rate_amrr,wlan_xauth,wlan_wep,wlan_tkip,wlan_ccmp,wlan_acl

ath_hal               147024  2 ath_pci
```

ifconfig -a shows ath0 existing:

```
ath0      Link encap:Ethernet  HWaddr 00:11:95:E6:80:C1

          BROADCAST MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:199

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:17 Memory:f8c00000-f8c10000
```

... and iwconfig shows the following:

```
eth0      no wireless extensions.

lo        no wireless extensions.

eth1      no wireless extensions.

sit0      no wireless extensions.

ath0      IEEE 802.11g  ESSID:"WARFARESDL"

          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:03:2F:2D:FD:DB

          Bit Rate:1 Mb/s   Tx-Power:50 dBm   Sensitivity=0/3

          Retry:off   RTS thr:off   Fragment thr:off

          Power Management:off

          Link Quality=0/94  Signal level=-95 dBm  Noise level=-95 dBm

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
```

You can probably tell at this point that I installed and configured wpa_supplicant. The important configuration options are as such:(/etc/wpa_supplicant.conf)

```
ctrl_interface=/var/run/wpa_supplicant

ctrl_interface_group=0

eapol_version=1

ap_scan=1

fast_reauth=1

# Shared WEP key connection (no WPA, no IEEE 802.1X)

network={

        ssid="WARFARESDL"

        key_mgmt=NONE

        wep_key0="*hidden*"

        wep_key1=0102030405

        wep_key2="1234567890123"

        wep_tx_keyidx=0

        priority=5

}
```

To keep things as uncomplicated as possible for my initial setup, I have only done shared WEP key connection with a single ASCII WEP key (key0).

Running /etc/init.d/net.ath0 start starts up wpa_supplicant... and then hard locks the machine. Any ideas?

----------

## KShots

Is there a more stable wireless driver than this madwifi thing? I'm starting to get the impression that it's not very well supported / designed. Is it possible to try to string this through the ndis-wrapper hack I've been reading about?

----------

## Chris W

I'm assuming you are using the ebuilds from Portage.    It is very important that wpa_supplicant is built against the headers from the version of madwifi you are using.   The 0.1_pre20050420-r1 and 0.1_pre20050809-r1 versions install headers in the correct place for the 0.4.4 version of wpa_supplicant to find.  As far as I'm aware the 0.3.9 version of wpa_supplicant uses a separate CVS snapshot that may not match your madwifi-driver.

----------

## KShots

I see... I'll give that a try.

Also, as a note, if you're dabbling with QT4, you'll find it difficult to install that version of wpa_supplicant with qt support. I temporarily symbolically linked all my qt3 binaries where qt4 would expect them to get around this (and I am currently in the process of reversing that). It's probably not necessary (you can simply disable the qt USE flag), but I'm kind of curious as to why qt is even involved.

EDIT: OK, I'm going to try starting it up again now... let you know how it turns out.

EDIT2: Well, this time it didn't lock up. I got this output:

```
rich@basilisk /usr/bin $ sudo /etc/init.d/net.ath0 start

 * Starting ath0

 *   Starting wpa_supplicant on ath0 ...

ioctl[SIOCSIWPMKSA]: Operation not supported                              [ ok ]

 *     timed out                                                          [ !! ]

rich@basilisk /usr/bin $
```

That tends to tell me that either my driver is out of date or that I am missing some obscure kernel module, yet I am relatively sure neither is the case.

EDIT3: The qt application that was being compiled was apparently something called wpa_gui. It appears that it doesn't do much until the wifi interface is up and running, however, so I'm not sure what to do with it.

----------

## KShots

OK, I appear to have larger problems.

The next two times I tried it, it crashed (hard). Had to hit the reset button.

This is very inconsistent - any chance that the madwifi-driver has problems with SMP? I am using this on a dual athlon MP.

Anyways, I had upgraded my wpa_supplicant to v. 0.4.4 (it was previously 0.3.9) and enabled the madwifi USE flag that had appeared when I tried to make that version. Just because it may be brought into play, I am using this kernel:

```
rich@basilisk ~ $ uname -a

Linux basilisk 2.6.12-gentoo-r10 #2 SMP Wed Sep 28 19:45:10 EDT 2005 i686 AMD Athlon(tm) MP 2000+ AuthenticAMD GNU/Linux
```

I have the following modules currently loaded:

```
rich@basilisk ~ $ lsmod

Module                  Size  Used by

snd_seq_midi            6816  0

snd_emu10k1_synth       6912  0

snd_emux_synth         35264  1 snd_emu10k1_synth

snd_seq_virmidi         6272  1 snd_emux_synth

snd_seq_midi_emul       6656  1 snd_emux_synth

snd_pcm_oss            47712  0

snd_mixer_oss          17152  1 snd_pcm_oss

snd_seq_oss            32576  0

snd_seq_midi_event      6464  3 snd_seq_midi,snd_seq_virmidi,snd_seq_oss

snd_seq                51152  8 snd_seq_midi,snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_oss,snd_seq_midi_event

snd_emu10k1           112068  2 snd_emu10k1_synth

snd_rawmidi            20704  3 snd_seq_midi,snd_seq_virmidi,snd_emu10k1

snd_seq_device          7116  7 snd_seq_midi,snd_emu10k1_synth,snd_emux_synth,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi

snd_ac97_codec         78648  1 snd_emu10k1

snd_pcm                82500  4 snd_pcm_oss,snd_emu10k1,snd_ac97_codec

snd_timer              21124  3 snd_seq,snd_emu10k1,snd_pcm

snd_page_alloc          7684  2 snd_emu10k1,snd_pcm

snd_util_mem            3456  2 snd_emux_synth,snd_emu10k1

snd_hwdep               7328  2 snd_emux_synth,snd_emu10k1

snd                    47588  14 snd_emux_synth,snd_seq_virmidi,snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_emu10k1,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer,snd_hwdep

soundcore               7520  1 snd

ath_pci                53664  0

ath_rate_onoe           7112  1 ath_pci

ath_rate_amrr           7236  0

wlan_xauth              1408  0

wlan_wep                5888  0

wlan_tkip              10496  0

wlan_ccmp               6208  0

wlan_acl                3968  0

wlan                  107804  9 ath_pci,ath_rate_onoe,ath_rate_amrr,wlan_xauth,wlan_wep,wlan_tkip,wlan_ccmp,wlan_acl

ath_hal               147024  2 ath_pci

fglrx                 241948  9
```

Don't know what other information that may be helpful I could provide. Hope someone has a clue, I sure don't  :Sad: 

----------

## Chris W

 *Quote:*   

> ioctl[SIOCSIWPMKSA]: Operation not supported  

 This is normal, non-fatal, but nonetheless annoying.

Which madwifi-driver version are you using?

A couple of things I did that you might like to try:

Delete any two of the ath_rate_* modules in /lib/modules/2.6.13-gentoo-r3/net and run modules-update.  They each provide the same symbols and you can only use one at a time anyway.  I use ath_rate_sample successfully.

Load only ath_pci and let it autoload everything else.

The SMP issue is not something I can answer from personal experience.  There are references to SMP in the mailing list, some seem to get further than you.  You might like to search the Madwifi users mailing list:

http://news.gmane.org/gmane.linux.drivers.madwifi.user

----------

## KShots

 *Chris W wrote:*   

>  *Quote:*   ioctl[SIOCSIWPMKSA]: Operation not supported   This is normal, non-fatal, but nonetheless annoying.

 Understood - I won't let that distract me, then. *Chris W wrote:*   

> Which madwifi-driver version are you using?

 net-wireless/madwifi-driver-0.1_pre20050420-r1 *Chris W wrote:*   

> A couple of things I did that you might like to try:
> 
> Delete any two of the ath_rate_* modules in /lib/modules/2.6.13-gentoo-r3/net and run modules-update.  They each provide the same symbols and you can only use one at a time anyway.  I use ath_rate_sample successfully.
> 
> Load only ath_pci and let it autoload everything else.
> ...

 Hmm... I'll try the 2nd option first and see what happens (less drastic a change). Otherwise I'll try the first. *Chris W wrote:*   

> The SMP issue is not something I can answer from personal experience.  There are references to SMP in the mailing list, some seem to get further than you.  You might like to search the Madwifi users mailing list:
> 
> http://news.gmane.org/gmane.linux.drivers.madwifi.user

 I'll give that a look-over as well. If that turns out to be the problem, I may just be SOL until it's resolved (if anyone makes it a priority). Thanks for you help so far!

EDIT: Looking at that link, I see many SMP issues being a problem with compiling a little over a year ago. I don't see anything more recent, but that does not mean that there is not still an issue. Again, I'll try the above first. If that fails, I'll try and compile a non-SMP kernel (non-default of course - I'm just trying to isolate the problem) and try that. If that's the case, then my wireless support will just have to wait until SMP support comes along.

----------

## KShots

OK, that's a no go. First, I tried using just ath_pci (and it autoloaded the rest). Then I tried to go to a non-SMP kernel... actually, that didn't work either, to my mixed relief and despair. It appears I may be having a slightly more mundane problem - perhaps I missed something very basic, but I don't know what that may be as of yet.

Both changes had the same results I was experiencing earlier - either an ioctl not supported timeout or a hard lockup. Usually, the first time would give the ioctl timeout, and if I tried again, it would always give a hard lockup.

----------

## Chris W

While I didn't have lock-up problems with that version of Madwifi I did have issues with the rate control throttling back to zero about 5 seconds after I started transfering any data.  Rather substantial changes have been made in the code-base since April.  I'm now using a CVS snapshot from 14 September (ebuild derived directly from 0.1_pre20050809-r1) with gentoo-sources-2.6.13-r3 but it was previously fine on 2.6.12-r10.  Perhaps that's worth a try for you.

I'm assuming that these crashes are the driver alone, and not some serious mismatch between it and e.g. wpa_supplicant or hostapd.

----------

## KShots

Hmm... I've got a reference at least now.

I managed to successfully install the same card type using the madwifi driver on my laptop (I'm typing through that now). It doesn't like the OpenSSL libraries in the wpa_supplicant.conf file, but simply removing them causes it to just "work." I think my next step is to duplicate the configs (exactly) to my desktop and see what happens (maybe this is all over a typo).

EDIT: One thing bothers me... I seem to be getting a (reported) 11Mb/s using this driver. Is that accurate? It should be running at 108 Mb/s. Here's what iwconfig says:

```
rich@beastie ~ $ /sbin/iwconfig

lo        no wireless extensions.

eth0      no wireless extensions.

Warning: Driver for device ath0 has been compiled with version 18

of Wireless Extension, while this program supports up to version 17.

Some things may be broken...

ath0      IEEE 802.11g  ESSID:"WARFARESDL"

          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:03:2F:2D:FD:DB

          Bit Rate:11 Mb/s   Tx-Power:50 dBm   Sensitivity=0/3

          Retry:off   RTS thr:off   Fragment thr:off

          Power Management:off

          Link Quality=30/94  Signal level=-65 dBm  Noise level=-95 dBm

          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0

          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
```

...Also, note the warning. Is that likely to cause me some problems?

----------

## Chris W

 *KShots wrote:*   

> EDIT: One thing bothers me... I seem to be getting a (reported) 11Mb/s using this driver. Is that accurate? It should be running at 108 Mb/s. 

 

The driver defaults to 802.11b rather than 802.11g (or the 108Mbps non-standard).  You put the card into 11g mode with something like:

```
iwpriv_ath0="mode 3"
```

 in /etc/conf.d/net.  The iwpriv parameters for turbo mode are: 

```
# iwpriv ath0 turbo 1
```

  Unfortunately, AFIAK you cannot have two iwpriv_if lines in the configuration file and an array variable doesn't work either (someone correct me if I'm wrong).  You could explicitly set turbo mode in /etc/conf.d/local.start.

The latest ~x86 version of wireless-tools knows about the later wireless extensions and should see make the warning go away.

----------

## KShots

 *Chris W wrote:*   

>  *KShots wrote:*   EDIT: One thing bothers me... I seem to be getting a (reported) 11Mb/s using this driver. Is that accurate? It should be running at 108 Mb/s.  
> 
> The driver defaults to 802.11b rather than 802.11g (or the 108Mbps non-standard).  You put the card into 11g mode with something like:
> 
> ```
> ...

 Cool - that worked. I was able to boost it up to about 38Mb/s - I suspect the rest of the 54 Mb/s is lost in the noise. *Chris W wrote:*   

> The iwpriv parameters for turbo mode are: 
> 
> ```
> # iwpriv ath0 turbo 1
> ```
> ...

 That line didn't work for me:

```
rich@beastie ~ $ sudo iwpriv ath0 turbo 1

Interface doesn't accept private ioctl...

turbo (8BE0): No such device or address
```

Seems odd to me... *Chris W wrote:*   

> The latest ~x86 version of wireless-tools knows about the later wireless extensions and should see make the warning go away.

 Gotcha. That solved the warning. Thanks for your help so far. Btw, whatever's going on with my desktop was not fixed by matching the configs. It's really driving me nuts, but I can run a wire from my router to there... I was just hoping to get rid of a tripping hazard.

----------

## Chris W

I've found that my Madwifi cards in 802.11g  mode report 36Mbps when they are idle, but that rises when traffic is present.

The Madwifi drivers have supported turbo mode for quite some time but maybe not the version you are using.  Is 

```
ath0      get_turbo:0
```

 listed in the output of 

```
# iwpriv -a
```

?  You could try the latest unstable driver from Portage.  Some had issues with that version, but I didn't, so YMMV.  I don't know how useful it will be if you cannot achieve 54Mbps in standard 11g mode.

----------

