Re: Scan fails to find wireless networks

Hi,

> > > at76c503.c: at76c503.c:2905 assertion dev->istate == INIT failed
> >
> > I'll look into this during the weekend.
>
> Thanks.

sorry, I'm still lacking time to spend on this issue.

> > There was a bug in the i/f to "iwlist wlanX scanning" (I guess you use
> > this for scanning) which let it report only a random subset of the whole
> > table. It's fixed in the cvs 0.12beta21.
>
> Yes, that's how I do the scan.  I've tried updating to this version but
> the behaviour doesn't seem to have improved at all.

Strange, it helped here with the same chipset/radio.

> > If you still miss some APs, increase the minimum channel time, i.e.
> > the device scans on a channel, before it hops to the next one:
> >
> > 	iwpriv wlan0 scan_times N 120
> >
> > with N = 30,40, ... (N=10 is the default). The 120 is the max. channel
> > time, increasing it let iwlist fail here.
>
> This also doesn't seem to make any difference, which is what initially
> led me to believe there might be a firmware issue.  Should I notice the
> scan taking any longer when I increase the minimum time?  What are the
> units these values are measured in?

No, the minimum time is the time the device listens to a channel even
without any response to it's ProbeReq. It stays there for MaxChannelTime,
if the channel got busy before MinChannelTime.

units of *ChannelTime: time units (TU) = 1024 us (if the firmware
interface was implemented acc. to 802.11-1999).
The unit of ProbeDelay is us.

> One thing that seems strange to me (with my lack of understanding of
> what's going on here) is that I consistently get a complete list of APs
> in the debug logs from the initial scan runs that happen on interface
> up.  It seems very odd then that calling `iwlist wlan0 scan' should not
> be able to repeat this data.  Are there two different kinds of scan
> going on here?

IMHO not, but we added international roaming as an option in beta18. Do
you use it (module param international_roaming=1)?

> Also, what does it mean when start_scan reports that
> channel = 10 ?  I would expect the scan to occur on every channel (and
> it seems that it does, picking up APs that aren't on channel 10).

It's the channel where the scan starts: 10,11,...,1,2,...,9

Please try to change this line (twice in at76c503.c):
    scan.probe_delay = cpu_to_le16(dev->monitor_scan_min_time * 1000);
into
    scan.probe_delay = cpu_to_le16(5000);

which will speed up sending the ProbeReq during active scan and leave more
time for the APs to answer before the device switches to the next channel.

/Jörg