On Fri, Feb 03, 2017 at 09:49:21AM +0100, Martin Pieuchot wrote: > On 02/02/17(Thu) 22:14, Stefan Sperling wrote: > > Note that rates get fixed up again after association is confirmed, > > via ieee80211_recv_assoc_resp() -> ieee80211_setup_rates(). > > Which is why 11b clients were already working fine in spite of sending > > a bogus rateset in the association request. > > Does that mean this second correction is now unnecessary?
Not sure about that. Technically, nobody is allowed to flip-flop on what they support. But it happens due to bugs such as this one. I hae seen evidence of other devices having similar bugs, e.g. Nintendo 3DS clients send a garbage SSID and rateset in a first probe request: SSID parameter set: K%mUL5MD:HWISMM2?E`|Yvt/bFIhp.cb Supported Rates 1(B), 2(B), 5.5(B), 6, 9, 11(B), 12, 18, [Mbit/sec] Extended Supported Rates 24, 36, 48, 54, [Mbit/sec] And then change their mind in the next one: SSID parameter set: stsp.name Supported Rates 1(B), 2(B), 5.5(B), 11(B), [Mbit/sec] Always using the most recently received information from the peer is probably the best thing to do.
