Re: Number of wireless scans before trying autoconnection
- From: Dan Williams <dcbw redhat com>
- To: Franco Miceli <fmiceli plan ceibal edu uy>
- Cc: Martin Langhoff <martin langhoff gmail com>, networkmanager-list gnome org
- Subject: Re: Number of wireless scans before trying autoconnection
- Date: Wed, 28 Jul 2010 15:01:49 -0700
On Wed, 2010-07-28 at 09:32 -0300, Franco Miceli wrote:
> 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?
Yes, this could be done. If you'd like to do a patch for this there are
a few ways you could go about it.
Since we don't get reliable scan indications, we should just do two
back-to-back scans on startup. The problem is trying to figure out when
they are *done*. That requires both a 10 second timeout after
requesting the scan and a 2-second backoff timer that gets reschedule
for two more seconds each time a scan result comes in while the 10
second timeout timer is active. If either of the 10-second timeout or
the 2-second backoff timer fire, then we increment a 'guint32 num_scans'
variable in NMDeviceWifiPrivate.
Then, reduce SCAN_INTERVAL_MIN to 11 (so it doesn't overlap with the
10-second backoff timer).
Next, put a check in real_get_best_auto_connection() to return NULL if
num_scans < 2 (so we do 2 scans before allowing autoconnect).
Finally, we need a way to tell NMPolicy to retrigger autoconnect
checking, which probably means another signal on NMDeviceInterface
called "recheck-autoactivate" that gets emitted when num_scans changes
to 2. The Policy listens to this variable and calls
schedule_activate_check() when the signal is emitted.
> 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.
> 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
> > 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
> > 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
> > 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
> problem... WEXT does not really give us any information about
> 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
> 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
> 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.
> > 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
> > feature?
> > I ask this because the card the hardware I am
> > 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
> > 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
> > If anyone knows where to look for I would really
> > 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
] [Thread Prev