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 #353 (closed defect: fixed)

Opened 16 years ago

Last modified 15 years ago

Checks in 1409+ make association with orinoco AP/OR impossible

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


Since 1409 I cannot connect to an Orinoco Outdoor Router (802.11b).

iwlist scans will show the network and wlanconfig will say the ap is a member, but iwconfig will show no AP (00:00:00:00:00:00)

I can connect if I comment out 'IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1]);' at line 2254, but it's quite unstable.

Monitoring with 80211debug +elemid I got the following repeating (notice the almost identical MAC/BSSID):
[ath11:06:15:6d:10:1b:57] discard unhandled information element, id 32, len 1
[ath11:00:15:6d:10:1b:57] discard unhandled information element, id 32, len 1

I also got this at one time, not sure what the difference was:
[ath11:06:15:6d:10:1b:57] discard beacon frame, for off-channel 1
[ath11:00:15:6d:10:1b:57] discard unhandled information element, id 32, len 1


orinoco-assoc-dump.pcap (5.1 kB) - added by on 02/02/06 01:50:44.
pcap file of association with orinoco AP using 1408
debug-info.txt (9.4 kB) - added by on 02/03/06 17:00:14.
debug info while trying to associate
log-clipped.txt (25.4 kB) - added by on 02/03/06 18:39:45.
results of athdebug +recv for svens
debug.txt (21.9 kB) - added by on 02/06/06 17:57:56.
more debugging info with +recv

Change History

02/01/06 07:58:29 changed by anonymous

  • patch_attached changed.

the 'discard unhandled information element' line is pretty normal, no need to worry. Do you have any lines like 'bad x len y' in the log?

02/02/06 01:50:44 changed by

  • attachment orinoco-assoc-dump.pcap added.

pcap file of association with orinoco AP using 1408

02/02/06 01:52:12 changed by

Perhaps worth noting the bssid/MAC that madwifi-ng is using is not the MAC of the VAP that's supposed to connect to NMO ssid.

02/02/06 01:56:39 changed by

My stupidity - it's the right bssid/mac. Looked at wrong line. :)

02/03/06 05:46:25 changed by mrenzmann

  • version set to trunk.

@Reporter: seen the question in the first comment to your ticket (the one from anonymous, which I think in fact was svens)?

02/03/06 06:36:42 changed by

No, that was pretty much all I got. Any other flags I should try with 80211debug besides +elemid?

02/03/06 16:59:41 changed by

Here's what I got with the below debugging on as instructed:
root@wubuntu:~# athdebug -i wifi1 +beacon +beacon_proc +fatal
dev.wifi1.debug: 0x0 => 0x80008080<beacon,beacon_proc,fatal>
root@wubuntu:~# 80211debug -i ath11 +assoc +elemid
net.ath11.debug: 0x0 => 0x2800000<elemid,assoc>
root@wubuntu:~# iwconfig ath11 essid NMO

The following clip starts right about where I issued the essid to force a new
reassoc request, 00:60:1d:f7:45:65 is the AP I'm trying to join:

02/03/06 17:00:14 changed by

  • attachment debug-info.txt added.

debug info while trying to associate

02/03/06 17:51:46 changed by svens

can you try association again with `athdebug +recv'? This should give us the packet dump.

02/03/06 18:39:45 changed by

  • attachment log-clipped.txt added.

results of athdebug +recv for svens

02/06/06 17:57:56 changed by

  • attachment debug.txt added.

more debugging info with +recv

02/24/06 23:36:48 changed by

I have the same problem, here's some info:

I looked though to the part of the code that was added in when parsing the ASSOC_RESP and REASSOC_RESP.

It seems that my Orinoco AP (AP-2000, not sure what jason had) is creating bad ASSOC_RESP frames. Going through the element id calculations, it actually provides two elements, one for the supported rates (id 1), and another element id 129, which isn't listed in the ieee80211.h file, but a google search turned up as saying agere wanted it for its private use.

This isn't the problem, the problem is there's 1 more byte after all the subtractions, which in turn, makes the while loop (line 3035, ieee80211_input.c) go again and the IEEE80211_VERIFY_LENGTH drops the packet.

02/27/06 04:00:15 changed by michisteiner at

This problem seems to be related to the problem discussed in Ticket 428 ...?

02/28/06 22:41:51 changed by

I just checked with an updated firmware of my orinoco ap-2000, and it sends "good" length packets now.

Maybe you should try updating firmware if possible, or bug the manufacturer for one.

02/28/06 22:55:51 changed by

I'm going to update all my findings in ticket

06/23/06 15:06:18 changed by

It seems the included patch with #698 has indeed fixed my problems.

07/17/07 15:07:52 changed by mtaylor

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