> > wpa_supplicant cannot handle A-band channel #s. Thus, with the previous > > code, the FREQ+frequency was sent first, and the FREQ+channel was sent > > second. Sending the FREQ+channel second made the supplicant overwrite > > the value it already parsed from the FREQ+frequency for that BSSID. But > > since the supplicant can't handle A-band channel #s, you end up with 0. > > > > Reversing the order of these two makes it work, but it's a total hack. > > That may be what's needed right now though until everyone fixes their > > supplicant. There's overlap on A-band channels 7 - 12 (5035MHz -> > > 5060MHz) with B/G band channel #s. Obviously WEXT falls over here > > because the band isn't passed. > > > > But what's the best fix to the supplicant? It could just parse A-band > > channels and where the numbers overlap, assume B/G band. Or, it could > > be patched to prefer FREQ+frequency over FREQ+channel if it received > > both. That's probably the best solution. Fun. How about it we just make wpa supplicant ignore FREQ/channel completely if it uses FREQ/frequency anyway? > Actually we've also tried to removing FREQ+channel part and it has > worked. So wpa_supplicant won't get into this dilemma. Makes sense. > Patch that broke it is below so I guess the bug is in everything form > 2.6.25 and up. > ' > commit 8318d78a44d49ac1edf2bdec7299de3617c4232e > Author: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > Date: Thu Jan 24 19:38:38 2008 +0100 > > cfg80211 API for channels/bitrates, mac80211 and driver conversion > ' Yeah, sorry about that. Once more, bitten by the assumption wext was useful and people would implement it properly. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
