unable to associate to AP using WEP with madwifi-ng

Output of athdebug and 80211debug

athstats and additional info

patch for handling of "iwconfig ath0 ap any" and "iwconfig ath0 ap off"

Nicely written problem report, this was easy to track down.

The problem was that madwifi was interpreting the "iwconfig ath0 ap any" command as an attempt to find an AP with MAC address ff:ff:ff:ff:ff:ff. This was contrary both to the documentation for the iwconfig command, and to good sense.

As a workaround, you can use "iwconfig ath0 ap off", which will do what you want it to do. Or you can apply this patch.

Signed-Off-By: Brian Eaton <eaton.lists@gmail.com>

Hi! Thanks for your help! Unfortunately using "iwconfig ath0 ap off" doesn't fix it. Even specifying the Mac-address of the AP as commented out in my original report doesn't work.

ath0      IEEE 802.11b  ESSID:"domanig"
          Mode:Managed  Frequency:2.437 GHz  Access Point: Not-Associated
          Bit Rate:1 Mb/s   Tx-Power:17 dBm   Sensitivity=0/3
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:9246-BF85-65E9-4DE6-089B-E70E-F6   Security mode:restricted
          Power Management:off
          Link Quality=42/94  Signal level=-53 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

(This is the output when using "iwconfig ath0 ap off".) The attachment "madwifi-debug.txt" above contains debugging output captured when using "iwconfig ath0 ap 00:02:2D:61:CC:94". Please tell me if I should provide additional info.

--leo

Interesting that this still doesn't work. I can't reproduce what you are seeing. There are a few odd things you could investigate.

Your scan appears to show two APs with the same address but different SSIDs. That's a little strange.

The madwifi debug output logs an assoc_resp packet from the AP that seems bad. The packet looks reasonable up through 82 84 0b 16, which indicates supported rates of 1, 2, 5.5 and 11 Mbit/sec, then the remaining 20 bytes don't look like anything ethereal recognizes as normal. If you add '+elemid' to your 80211debug command, I think madwifi will spit out errors saying the packet is too short. Actually, the packet is too long. It's like it had garbage tacked on the end.

If you can capture traffic of another driver successfully associating with this AP, I'd like to see it.

What he said; plus could we get a debug output with 80211debug set to:

+output +input +auth +assoc +dot1x +dot1xsm +state +crypto +scan +roam

?

new debugging info

How can I capture the traffic of another station associating? I tried to do it using

modprobe ath_pci autocreate=none
wlanconfig ath0 create wlandev wifi0 wlanmode monitor
iwpriv ath0 mode 2
iwconfig ath0 mode monitor channel 6
ifconfig ath0 up

... and capturing an association via ethereal (promiscous mode) but this shows only 3 broadcasted 'Probe Request's.

--leo

Yeah, I think you're hitting some poor information element handling. Could you try with the code from subversion?

I've upgraded to the current madwifi rpms from Axel Thimm (madwifi-0.9.0-23.rhfc5.at and friends) which unfortunately doesn't fix it.

I believe this must be rev.1594.

I couldn't find any more recent commit in the revision log that looks like a fix for my problem. Do you think upgrading those few revisions could be worth the trouble or is 0.9.0 recent enough?

Thanks,

--leo

I can sometimes, sort of, nearly reproduce this.

Sometimes my card is slower to associate with the AP than it should be. If I look in the logs produced from 80211debug +recv +recv_desc, I can see what looks like broken packets being received from the AP. When this happens, the driver ignores the packet, and eventually the association or the authentication times out.

Then the driver rescans, finds the same AP, and the process repeats. The timeout appears to be five seconds. Sometimes several attempts are necessary before the association succeeds.

Leo - what happens if you wait for 60 seconds after you run your association script? Does it work then? If so, maybe I am seeing the same problem you are seeing.

I'm going to do some more tests to try to pin down whether my AP is actually sending broken packets, or if madwifi is damaging the packets after reception.

The problem isn't the AP, it's either the card or the driver. I verified this by comparing the packets captured by another card with the packets madwifi logged to kern.log. The madwifi version of the packet has 4 extra bytes tacked on the end.

While figuring that out, I noticed some other strange behavior.

Occasionally the message "ath_rx_tasklet: short packet 14"

On tests when the association works immediately, a madwifi monitor mode vap is able to capture packets.

On tests when the association fails at first, a madwifi monitor mode vap fails to capture any packets.

I'll attach my test script in a minute.

Script to reproduce this problem, or something like it.

Fascinating. Maybe related to this issue? http://madwifi.org/ticket/617

My analysis of the captured data was way off base. I was misled by the format of the captured packets. The "+recv" debugging output was appending an extra 4 bytes to every frame, containing the frame checksum. The ethereal packet decoders were not expecting the frame checksum, and so reported a bogus packet. (I submitted a fix to madwifi a few days ago so that the frame checksums are not logged any longer.)

I looked at your packet captures again, this time stripping off the extra 4 bytes before asking ethereal to decode the packet. This is what tethereal shows:

IEEE 802.11
    Type/Subtype: Authentication (11)
    Frame Control: 0x00B0 (Normal)
        Version: 0
        Type: Management frame (0)
        Subtype: 11
        Flags: 0x0
            DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
            .... .0.. = More Fragments: This is the last fragment
            .... 0... = Retry: Frame is not being retransmitted
            ...0 .... = PWR MGT: STA will stay up
            ..0. .... = More Data: No data buffered
            .0.. .... = Protected flag: Data is not protected
            0... .... = Order flag: Not strictly ordered
    Duration: 258
    Destination address: PhilipsC_4c:a0:97 (00:05:4e:4c:a0:97)
    Source address: Agere_61:cc:94 (00:02:2d:61:cc:94)
    BSS Id: Agere_61:cc:94 (00:02:2d:61:cc:94)
    Fragment number: 0
    Sequence number: 2651
IEEE 802.11 wireless LAN management frame
    Fixed parameters (6 bytes)
        Authentication Algorithm: Unknown (20717)
        Authentication SEQ: 0x0004
        Status code: Authentication rejected because of challenge failure (0x000f)

I know you wrote that you have this working with madwifi-old, but is it possible that your script is specifying the wrong WEP key?

I just reverified that the WEP-key is correct. (I did also compare the "Encryption key" output by iwconfig to the wep-key on another box that is associated, it also matches the correct key.)

If you told me how to capture the packets, I could provide a dump of another station associating to the AP. (Using ethereal in monitor mode as described above didn't work.)

--leo

Your original capture steps were nearly correct, but you need to omit the "iwpriv ath0 mode 2" command:

modprobe ath_pci autocreate=none
wlanconfig ath0 create wlandev wifi0 wlanmode monitor
iwconfig ath0 mode monitor channel 6
ifconfig ath0 up

If you want to do the capture from the command line, you can use

tcpdump -i ath0 -s 0 -w ath0.cap

Kernel Log of configcapture.sh

I have exactly the same problem here. Driver is version 0.9.1 released as of today. My access point is a Draytek Vigor 2600G DSL Router. My Card is a no name Atheros AR5212 Mini PCI Card.

I've ran the provided configcapture.sh script. Unfortunatly the tcpdump of ath1 is empty. But not the kern.log, so I attached it.

An older pre-0.9 driver runs fine with the same configuration. Below is the output of this older driver version: ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) wlan: 0.8.6.0 (EXPERIMENTAL) ath_rate_sample: 1.2 ath_pci: 0.9.6.0 (EXPERIMENTAL) ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 11 ACPI: PCI Interrupt 0000:02:0a.0[A] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 1 1 Build date: Jan 21 2006 Debugging version (IEEE80211) ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbp s 48Mbps 54Mbps ath0: turboG rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: H/W encryption support: WEP AES AES_CCM TKIP ath0: mac 5.9 phy 4.3 radio 3.6 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons Debugging version (ATH) ath0: Atheros 5212: mem=0xff9e0000, irq=11 ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 1 1 PCI: Setting latency timer of device 0000:00:1f.5 to 64

I believe this must be rev.1594.

Kinda sucks; the changeset I was thinking of was r1595. I had to go look it up though.

Have you tried with a later version yet?

Tried r1686, with no success. The driver even recognizes the right frequency. It stops on the preferred ap frequency, but doesn't associate.

Is there any change in the symptoms of the problems?

No. But in some rare circumstances, the association works. Not reproducible though. I've tried and tried. It works until the next AP reboot or sometimes the next client reboot. Most of the time, the association just doesn't work.

Even if I try to disable my hidden cell here, the situation doesn't improve. Sorry.

@tom: In your case the problem seems to be with the ESSID matching. Could you provide the output of a scan for access points?

Scan of r1686

I've already attached the file kern.log from the 0.9.1 version. But here we go again with kern_16072006.log from the r1686 revision. Hope it helps.

I've had similar problems - card scanned for AP , found proper frequency , stopped on that for a while and then started scanning again. It seems that i have sorted that cases by turning diversity off and specifying rxantenna and txantenna. Try that, maybe it will help you.

Tried changing diversity, but no improvement. Still reception is good at any given time. If it would only associate.

I'm seeing the same with my Access Points. After debugging I came to the conclusion that the following is the reason for the problems: - when setting the WEP key using iwconfig, the key is stored and the privacy flag is set - the authentication behaviour is unchanged - my access point insists on shared-key auth, while the driver insists on open auth The result is a continued authentication failure. It seems to me there are two possible solutions: 1. change ieee80211_ioctl_siwencode (ieee80211_wireless.c) to set the authentication method. 2. change ieee80211_send_mgmt (ieee80211_output.c) to do shared key auth if the AP requests it depending on (vap->iv_flags & IEEE80211_F_PRIVACY) rather than vap->iv_bss->ni_authmode. I'll attach a patch that is working for me which does the first. If it is currently working this means the patch might break existing setups, so the second might be better as it alows for both.

Patch for 0.9.2 to set auth scheme depending on privacy status

Just found out (too late) about iwpriv to set the authmode (shame on me). Sadly I couldn't find it when I was using google to research my "can't connect with WEP enabled" problem. After all, it was PEBKAC for me, though other cards don't need it and apparently switch automatically. Anyway, with the bad documentation of your regular AP, how would you be supposed to know that you have to enable shared key auth? A kernel message pointing to this might be helpful for people like me.

Patches to MadWifi are welcome ;-)

Hi, I just googled for solution of this problem, I compiled version 0.9.2 and the same as leo unable to athentificate AP. So I tried to use last patch (0.9.2.iwconfig-wep.patch) but it seems to be the same. In case of need you can contact me on icq 66792780 or skype name "piranhaman"

Sorry it was my mistake, I had wpa_supplicant installed but it was stopped... After starting everything seems to work, great!

Tom: The reason that your attempts are failing is that the driver is receiving an authentication sequence packet with invalid data (specifically an invalud algorithm number). Can you confirm with a packet capture that this is the actual data on the air, rather than the data being corrupted in hardware or in the driver?

Sorry, that was @leo.

How do I confirm with a packet capture that this is the actual data on the air? Any help for configuring that?

BTW, I have this problem with two different AR5212 based cards. One is from D-Link with an 5db ext antenna and the other is a laptop mini pci card. The trace comes from the mini pci card, although the symptoms are the same on both cards.

Hi! Sorry for the late reply... I've tried to capture a (successful) association of another box on air using the following commands:

modprobe ath_pci autocreate=none
wlanconfig ath0 create wlandev wifi0 wlanmode monitor
# doesn't work: iwconfig ath0 mode monitor channel 6
iwconfig ath0 channel 6
iwpriv ath0 mode 2
ifconfig ath0 up

... but unfortunately tcpdump doesn't show any packets while associating with the other box.

It looks like the commands ...

iwconfig ath0 channel 6
iwpriv ath0 mode 2

... don't have any effect, iwconfig shows that the card is still scanning all channels.

Any hints?

Hi,

I'm having a similar problem, I and thought I'd offer some info on my case (in hopes of fixing it quickly).

When I try to connect to the certain APs I log the message saying "[ath0:00:01:f4:74:f7:cc] discard assoc_resp frame, ie too short", which states the problem plain and simple - AP agrees to associate but driver thinks the frame is too short. This is probably the driver's issue, although it could be non-compliance to the standards by the certain APs (I don't know wifi standards too well). In either case it'd be nice to have it fixed (or worked around). Same card works fine under Windows.

I have a full debug output if you want it. I have the packet capture too. However, for some strange reason it didn't capture any packets to/from that particular AP. This is probably my screw up though, I was doing it pretty fast and carelessly, and only noticed that when writing this, so I'll try again later and see what happens.

I was running latest stable release of madwifi on 2.6.17 kernel. svn modules didn't load (was complaining about unresolved symbols).

Hope that helps. Contact me if you need anything else.

Thanks.

I'm running madwifi-ng-r1784-20061027 and I see the same problem.

I applied the patch, and it didn't make a difference.
I enabled the athdebug and ieee802debug.
The last message from ath0: is 'ieee80211_scan_assoc_success',
after that, the only debug messages are beacons from the AP.

Hi,

after some time debugging this, I've came up with a solution for me. I'm currently using version r2169 from the devel snapshots. Associating with my Draytek Vigor 2600G Router, failed because the madwifi is unable to handle the Element Payloads IEEE80211_ELEMID_HOP_PARAMS = 8 and IEEE80211_ELEMID_HOP_TABLE = 9. When receiving a Type 8 Frame, it recognizes it as too short and discards it.

I've changed the driver, to handle such Frames like the AGERE Elements by adding:

if ((*frm == IEEE80211_ELEMID_AGERE1) ||
   (*frm == IEEE80211_ELEMID_AGERE2) ||
+  (*frm == IEEE80211_ELEMID_HOP_PARAMS)) {
    frm = efrm;
    continue;
}

This works at least for me. But it's a hack. Can anyone come up with a better solution?

Hi,

I had similar problem with my notebook (Acer 5103WLMi) with Atheros 5005 compatible chip and router Draytek Vigor 2600Ge. It wasn't able to associate with router's AP. I think problem is with packet length, so i applied modified patch from Ticket #428 (len-check.diff): I made this changes: - while (frm < efrm) { - IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1]); + while (frm < efrm && frm[1] < efrm - frm) { and - (frm > efrm) - return; in all occurrences in file net80211/ieee80211_input.c.

Now it works perfectly, always associating with my AP and with no delays! :)

sorry for bad formatting; I made this changes:

- while (frm < efrm) {
-  IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1]);
+ while (frm < efrm && frm[1] < efrm - frm) {
and
- (frm > efrm)
-  return;