Thread: [Madwifi-devel] driver suggestion about trouble associating with certain aps using madwifi
Status: Beta
Brought to you by:
otaku
From: David C W. <da...@da...> - 2003-08-11 17:54:07
|
Devel, I'm having trouble associating with certain aps using the madwifi driver, and have a suggestion. Madwifi drops malformed 802.11 packets. Some standard aps (eg. broadcom-based linksys_wrt54g) do not publish their supported rates correctly. Therefore, the madwifi driver cannot associate with these aps. The windows atheros drivers are not as strict in their checking, and allow associations to these aps. Here's the problem, which applies to broadcom-based aps such as the linksys_wrt54g. According to the 802.11g spec, the maximum number of rates allowed in the Supported Rates element is 8 rates. Any additional rates must be added to the Extended Supported Rates element. The linksys_wrt54g returns all rates in the Supported Rates element, instead of adding the rates to the Extended Supported Rates element when there are more than 8. Should someone change madwifi to accept the malformed association response packets? The windows atheros drivers sure do. Btw, i think it would be a simple fix of just removing the check. ***CORRECT linux madwifi driver associating with a correctly behaving ap Tag Number: 1 (Supported Rates) Tag length: 8 Tag interpretation: Supported rates: 1.0(B) 2.0(B) 5.5(B) 6.0(B) 9.0(B) 11.0(B) 12.0(B) 18.0(B) [Mbit/sec] Tag Number: 50 (Extended Supported Rates) Tag length: 4 Tag interpretation: Supported rates: 24.0(B) 36.0(B) 48.0(B) 54.0(B) [Mbit/sec] ***INCORRECT linux madwifi driver associating with an incorrectly behaving ap Tag Number: 1 (Supported Rates) Tag length: 12 Tag interpretation: Supported rates: 1.0(B) 2.0(B) 5.5(B) 11.0(B) 6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 [Mbit/sec] TAKEN FROM 11g SPEC 7.3.2.2 Supported Rates element The Supported Rates element specifies up to eight rates in the Operational-Rate-Set parameter, as described in the MLME_Join.request and MLME_Start.request primitives. The information field is encoded as 1 to 8 octets, where each octet describes a single Supported Rate. If the number of rates in the Operational Rate Set exceeds eight, then an Extended Supported Rate element shall be generated to specify the remaining supported rates. The use of the Extended Supported Rates element is optional otherwise. Within Beacon, Probe Response, Association Response, and Reassociation Response management frames, each Supported Rate belonging to the BSS basic rate set is encoded as an octet with the MSB (bit 7) set to 1 and bits 6 through 0 are set to the appropriate value from the valid range column of the DATA_RATE row of the table in 10.4.4.2 (e.g., a 1 Mbit/s rate belonging to the BSS basic rate set is encoded as X'82'). Rates not belonging to the BSS basic rate set are encoded with the MSB set to 0 and bits 6 through 0 are set to the appropriate value from the valid range column of the DATA_RATE row of the table in 10.4.4.2 (e.g., a 2 Mbit/s rate not belonging to the BSS basic rate set is encoded as X'04'). The MSB of each Supported Rate octet in other management frame types is ignored by receiving STAs. -dave dave at davidwang dot com |
From: Sam L. <sa...@er...> - 2003-08-11 18:22:34
|
> I'm having trouble associating with certain aps using the madwifi > driver, and > have a suggestion. > > Madwifi drops malformed 802.11 packets. Some standard aps (eg. > broadcom-based > linksys_wrt54g) do not publish their supported rates correctly. > Therefore, > the madwifi driver cannot associate with these aps. The windows > atheros > drivers are not as strict in their checking, and allow associations to > these > aps. > > Here's the problem, which applies to broadcom-based aps such as the > linksys_wrt54g. According to the 802.11g spec, the maximum number of > rates > allowed in the Supported Rates element is 8 rates. Any additional > rates > must be added to the Extended Supported Rates element. The > linksys_wrt54g > returns all rates in the Supported Rates element, instead of adding > the > rates to the Extended Supported Rates element when there are more than > 8. > > Should someone change madwifi to accept the malformed association > response > packets? The windows atheros drivers sure do. Btw, i think it would > be a > simple fix of just removing the check. > Apple 11g AP's do the same (or used to). The code used to accept up to 12 rates (in violation of the spec). Looks like I put it back to 8 when I did the extended rate set stuff. Send a patch... Sam |