On Mon, Apr 21, 2008 at 10:20 PM, Dan Williams <dcbw@xxxxxxxxxx> wrote: > > On Mon, 2008-04-21 at 21:39 +0300, Tomas Winkler wrote: > > 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. > > Probably a supplicant issue here, since wpa_supplicant doesn't cache > scan results over time (like NM does) and therefore when NM asks the > supplicant to associate, the supplicant has to scan _again_ to find the > network to associate with. You could probably reproduce by creating a > supplicant config file and trying to associate with wpa_supplicant and > scan_ssid=1 + ap_scan=1 like NM is doing. > > There's some consensus about fixing this upstream in wpa_supplicant, but > there's nobody working on it quite yet. > Thanks for info, will try > dan > > > -- 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
