Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams <dcbw@redhat.com>]

On Sun, 2008-04-20 at 23:39 +0300, Tomas Winkler wrote:
> On Sat, Apr 19, 2008 at 11:32 AM, Johannes Berg
> <johannes@sipsolutions.net> 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.

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.

> >
> >  > 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.

Dan

> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html