On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote: > > 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. > > The driver should _certainly_ be enforcing regulatory domains. Even if > userspace requests a scan of a channel that is not available in the > regulatory domain, the driver needs to be rejecting the scan request in > situations where the firmware would reject it. The problem is only in software scanning as the radio is tuned not through the scanning code. We need to fix this as passive channels are concern. > If the firmware triggers an assertion, that definitely indicates a bug > in the driver, where the driver is not properly gating options sent to > the firmware. Only in the most exceptional circumstances should the > firmware actually crash. Firmware might be crashed any time but wrong driver behavior. It's not designed to be robust towards 'friendly driver' it supposed to be defensive in way that it guarantees that it won't violated FCC. > > > > > > > > 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) > > More like 1 or 2 minutes; though the scanning algorithm in NM 0.7 does > need to be optimized somewhat. Cards that advertise > 14 channels are > assumed to take a prohibitively long time to scan while connected > (madwifi was the largest offender here), and therefore NM will not > request scans for a/b/g devices while connected, but will collect and > use background scan results. > Actually in place with 70 and more APs I was never able to associate with NM, only manual configuration works. At my home place actually it works 100% but I have like 4 APs in surrounding. I'm working with stock NM in latest F8. 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
