On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > Second the 3954 and 4965 my uCode may crash intentionally if you send > > probe requests on a passive channel.according EEPROM. > > I really wonder what sort of error handling strategy that is, even if > it's done for regulatory compliance purposes I don't see a need to crash > the whole card. Especially considering that the userspace MLME in > wpa_supplicant will scan by itself (yes, it scans in userspace, whether > or not you may like that), of course it would be made comply with > regulatory settings but that makes it hard to develop. It should not scan on not supported channel in any conditions. EEPROM and reg.c has to be combined. > > > I personally wish to not make SW scanning possible at all for that reason. > > That is not going to happen since you can always "scan" by sending probe > requests manually. Probe request before association is a must, no argue about it. > > At last iwlwifi HW scanning can handle up to 4 essids for direct scan > > but currently wireless tools interface cannot utilize this. > > Does anybody actually *want* that? I personally dislike the behaviour of > scanning for all previously known SSIDs actively when hidden SSIDs are > so uncommon, I see it as an information disclosure vulnerability. Sure you want that. User space applications handles number of preferred SSIDs, let's call them profiles. It's desired that you do direct scan for those SSIDss for faster connection. Currently it takes 20 minutes for NM to connect to network I want in crowded air. (I'm exaggerating now I don't have real number... but it's something like that) It's not just for hidden ssids. Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
