Re: RE: iwl3945 problem with 2.6.25-rc9

[Dan Williams <dcbw@redhat.com>]

On Mon, 2008-04-21 at 21:39 +0300, Tomas Winkler wrote:
> On Mon, Apr 21, 2008 at 3:14 AM, Dan Williams <dcbw@redhat.com> 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@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.
> 
> 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.

dan