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 #868 (new task)

Opened 16 years ago

problem with association of some devices - Trendnet TEW510APB all similar

Reported by: strasak@bubakov.net Assigned to:
Priority: trivial Milestone:
Component: madwifi: 802.11 stack Version:
Keywords: association, trendnet Cc:
Patch is attached: 0 Pending:

Description

Ppl, i have problem with Trendnet TEW 510APB and devices, which are based on same OEM design - Tonze AW6660 and etc. - it is crap anyway but we have bought it some time ago and don't want to simply trash it - when both radios on these devices are in AP mode, boxes - pcs,WRAPs and stuff - equiped with madwifi associate with it nicely and all works as it should. But, when we put one radio on that device into managed mode, madwifi will not let it associate, writing following thing into syslog - if 80211debug +assoc +auth is enabled :

Sep  8 17:32:44 At_Tair kernel: ath2: [00:0e:8e:7b:2e:0a] recv auth frame with a
lgorithm 0 seq 1
Sep  8 17:32:44 At_Tair kernel: ath2: [00:0e:8e:7b:2e:0a] station authenticated
(open)
Sep  8 17:32:44 At_Tair kernel: ath2: [00:0e:8e:7b:2e:0a] deny assoc request, ca
pability mismatch 0x100
Sep  8 17:32:44 At_Tair kernel: ath2: [00:0e:8e:7b:2e:0a] station with aid 0 lea
ves (refcnt 4)

So i have been greping madwifi sources and found check , which causes it and thus this problem vanishes when i comment out the following section from ieee80211_input.c

/* 802.11 spec says to ignore station's privacy bit */
3035 	                if ((capinfo & IEEE80211_CAPINFO_ESS) == 0) {
3036 	                        IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_ANY, wh->i_addr2,
3037 	                                "deny %s request, capability mismatch 0x%x",
3038 	                                reassoc ? "reassoc" : "assoc", capinfo);
3039 	                        IEEE80211_SEND_MGMT(ni, resp, IEEE80211_STATUS_CAPINFO);
3040 	                        ieee80211_node_leave(ni);
3041 	                        vap->iv_stats.is_rx_assoc_capmismatch++;
3042 	                        return;

Till now, commenting this out haven't cause any harm in testing nor in normal load on our backbone links, where i used drivers compiled without this check on both sides of link. But, i know it is not proper solution, the check is there for some reason, althrought commenting it out didn't break anything here it is perfectly possible that it would break something somewhere. There is more stuff like that, so what about to enclose this and all stuff like that which in future will occure into some #ifndef statement - aka for example #ifndef RELAXED_CHECKING, i mean, to find some system solution of exeptional cases caused by some sort of not properly working and not fixable - tried various firmwares here without sucess - hardware. Well, system solution if exeptional cases souds really weird, but you probably know what i mean.