Re: Number of wireless scans before trying autoconnection

[Franco Miceli <fmiceli plan ceibal edu uy>]

Dan,

Thanks for your answer. I see what you say. You can request X number of scans without being sure that the firmware will execute them.

I understand that to do what I say, that would be mandatory. But in order to mitigate the problem of not seeing all AP in range at the start of the autoconnect feature, could one delay the autoconnect algorithm so that it would wait for several scans to be made?

I say this because I've seen that after just ten seconds of sugar being started, almost every AP is shown in the neighbour view (sort of an AP list). If we could delay the time where NM_autoconnect gets called at startup, I think this could be dealt with.

I appreciate any feedback you can provide on this topic.

Thanks once again for your answers.

Cheers,

2010/7/28 Dan Williams <dcbw redhat com>

On Fri, 2010-07-16 at 09:30 -0300, Franco Miceli wrote:
> So far, trying to get this problem solved, I have made a initscript
> that runs before NM. This script enables the wireless interface and
> performs a couple of scans (iwlist).
>
> Doing this (which performs as asked, finding almost all the networks
> in range), doesn't cause any effect on NM. NM still shows only a few
> of the available networks at startup.
>
> Is this something that can be dealt with at device autostart or
> something like that. I would really appreciate if anyone could point
> me at any direction, since I'm a bit lost inside the NM code. Maybe
> the function that starts the network interfaces, and/or where does NM
> take the scan results from at startup.

We should probably do more than on initial scan, but there's a big
problem...  WEXT does not really give us any information about scan
outcomes.  Sometimes the drivers and/or firmware will accept the scan
request and then cancel it later due to internal operations.  And if
that happens, WEXT doesn't have the ability to notify userspace that the
scan request failed.

nl80211/cfg80211 have the ability to make this somewhat better, but only
for drivers that have been ported to cfg80211.  Libertas (which the OLPC
XO-1 uses) is not yet full ported to cfg80211 in the 2.6.35 kernel.

So once we can use cfg80211, even then we need to  make sure the drivers
get fixed up to report internal scan cancellations to userspace.  Then
we need the supplicant to push that notification up to clients too.

Until then, we can't be sure whether any scan request we send to the
supplicant is actually successfully triggered or not, which  means we
don't know whether we need to try again.

Dan

> Thanks in advance for any answers anyone can provide.
>
> Cheers
>
> 2010/7/13 Franco Miceli <fmiceli plan ceibal edu uy>
>         Hi,
>
>         I have the following question: how many scans does NM wait
>         until it calls the autoconnect (real_get_best_autoconnection)
>         feature?
>
>         I ask this because the card the hardware I am currently
>         testing (OLPC XO-1) has doesn't report all the wireless AP in
>         range immediately.
>         That's why I want to either add a waiting period or something
>         like that in order to hold on so that all the AP in range are
>         available for choosing.
>
>         In order to do so, I need to know where in the source code I
>         can find the line/s where the autoconnection gets called.
>
>         If anyone knows where to look for I would really appreciate
>         your feedback.
>
>         Thanks for your answers.
>
>          Cheers
>
>
>
> --
> Ing. Franco Miceli
> CITS - Plan Ceibal - Investigación & Desarrollo
> Av. Italia 6201 - Montevideo, Uruguay
> CP: 11500
> Tel: (598 2) 601 5773 int.: 2227

> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

-- 
Ing. Franco Miceli
CITS - Plan Ceibal - Investigación & Desarrollo
Av. Italia 6201 - Montevideo, Uruguay
CP: 11500
Tel: (598 2) 601 5773 int.: 2227