Please note: This project is no longer active. The website is kept online for historic purposes only.
If you´re looking for a Linux driver for your Atheros WLAN device, you should continue here .

Ticket #454 (closed defect: worksforme)

Opened 13 years ago

Last modified 12 years ago

WEP association problems

Reported by: anonymous Assigned to:
Priority: major Milestone:
Component: madwifi: other Version: trunk
Keywords: Cc:
Patch is attached: 0 Pending:


I started having problems associating to WEP-protected networks.

The symptoms are that wpa_supplicant starts the scanning process, but the card never properly associates to the network. If I run iwconfig repeatedly, I can see that the network gets found on one of the frequencies and the appropriate WEP key is displayed for a moment, but the card just keeps on scanning.

Another symptom is that the card sometimes deassociates and I have to restart wpa_supplicant. This has never happened in the past.

These problems did not exist in madwifi-ng that I compiled on Jan 23 (I don't know how to check the version number), so this is a definite regression for me. In fact, I switched back to these old drivers, because they worked so much better.

These issues do exist in 1454 and 1457. They do not exist in the Jan 23 version.

Change History

03/08/06 16:39:38 changed by

I should have added more details. The card reports as:

ath_hal: (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413, DFS) wlan: (Atheros/multi-bss) ath_rate_sample: 1.2 ath_pci: (Atheros/multi-bss) ACPI: PCI Interrupt 0000:01:0d.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11 wifi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP wifi0: mac 5.6 phy 4.1 radio 3.6 wifi0: Use hw queue 1 for WME_AC_BE traffic wifi0: Use hw queue 0 for WME_AC_BK traffic wifi0: Use hw queue 2 for WME_AC_VI traffic wifi0: Use hw queue 3 for WME_AC_VO traffic wifi0: Use hw queue 8 for CAB traffic wifi0: Use hw queue 9 for beacons wifi0: Atheros 5212: mem=0xd0210000, irq=11

This is using Linux and wpa_supplicant built from the hostap CVS.

03/09/06 21:58:01 changed by

Maybe related to:

Try that patch there ?

03/10/06 10:17:25 changed by

I will try the patch. However, please note that my problems are different: first, it is a REGRESSION, because code from january works just fine. Second, it's not that I can't connect at all -- I can, it just takes several tries and the connection is sometimes dropped later on.

04/19/06 06:58:26 changed by bell_kin

you can find out versions from "madwifi-ng/.svn/entries" please log the associate packets: it is hard to find out the reason, without knowing what actually happened.

04/24/06 03:08:09 changed by

One thing you could try is the wireless extensions API instead of the madwifi API. Information on how to do that may be found here:

08/19/06 19:42:53 changed by

Final update. I traced it down to an issue with uninitialized hardware. There is something wrong with madwifi in that it doesn't properly initialize/reset all hardware. I would get the above problem, and then it would suddenly go away for months, only to come back again later. No amount of software tweaking seemed to have any influence on it, neither did powering down, rebooting, etc.

Having had this problem for many months and having changed kernels, madwifi versions, wpa_supplicant versions, and other tools, I am certain that madwifi drivers are at fault.

About two months ago I switched to using ndiswrapper and Windows drivers and I haven't had a single glitch ever since. All my issues with madwifi went away.

08/21/06 07:24:49 changed by mrenzmann

@jan: It would be great if you could give a more detailed description about your findings. It would help us to investigate this problem to provide a solution for this issue. Thanks in advance.

07/17/07 15:22:29 changed by mtaylor

  • status changed from new to closed.
  • resolution set to worksforme.

This ticket has not been updated in over six months and is being marked as "works for me" automatically.

If the ticket is still applies to the head revision of trunk, please re-open the ticket and provide any additional details needed and progress on the problem to date. Thanks.