Re: Number of wireless scans before trying autoconnection

[Franco Miceli <fmiceli plan ceibal edu uy>]

Dan,

If I undersand correctly, what you say is that we "count" the times the signal SCAN_RESULTS gets emitted. Please correct me if I'm wrong.

Also you mention to request two back to back scans at startup. My question on this is:

- Is the method auto_activate_device (gpointer user_data) the one in charge of initially activating all interfaces?

- If so, is it here where you say we should use the method request_wireless_scan twice in order to get two scans scheduled?

You say to reduce the constant SCAN_INTERVAL_MIN to 11, In any case the 
initial value of that constant is 0 so I think you mean to increase it, 
right?

If the start code for an interface is within auto_activate_device, I 
don't see where the initial scans are being requested. What I understand
 NM does, is a lot of processes executed in parallel, some of them (or 
most) triggered by different signals. What I mean by this is since I 
don't see any scan request on auto_activate_device -and I think that here
 is where the wireless iface gets activated- I'm assuming that the scan 
requests are made by another process running in parallel.

If this is the case, I thought one could -within auto_activate_device- 
wait and count the times the SCAN_RESULTS signal gets emitted, and after
 X emissions, pass through to get_best_auto_connection.

A pseudocode for this would be something like this:


auto_activate_device (gpointer user_data)
{
    ActivateData *data = "" *) user_data;
    NMPolicy *policy;
            g_slist_free (iter);
..........
       }
        iter = next;
    }

WHILE SCAN-COUNT < X DO {} /*SCAN-COUNT gets updated in the callback function of the emitted SCAN_RESULT signal*/

    best_connection = nm_device_get_best_auto_connection (data->device, connections, &specific_object);
..........

 out:
    /* Remove this call's handler ID */
    policy->pending_activation_checks = g_slist_remove (policy->pending_activation_checks, data);
    g_object_unref (data->device);
    g_free (data);

    return FALSE;
}

Then in the callback function to the scan_results:

supplicant_iface_scan_results_cb (NMSupplicantInterface *iface,
                                  guint32 num_results,
                                  NMDeviceWifi *self)
{
    priv = getPrivate(self);
    priv->SCAN-COUNT++;/*Defined previously within NMDeviceWIFI*/
    if (num_results == 0) {
        /* ensure that old APs get culled, which otherwise only
         * happens when there are actual scan results to process.
         */
        cull_scan_list (self);
    }
}
----------------------------------------------------------------------------------------------------------


What do you think about this? Am I getting it all wrong?

Thank you very much.

Cheers

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

On Wed, 2010-07-28 at 09:32 -0300, Franco Miceli wrote:
> 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?

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.

Dan

> 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

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