Dan, I repeat my last mail since there was an error in the sending process:
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 = (ActivateData *) 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.
2010/7/29 Franco Miceli <fmic...@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 = (ActivateData *) 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 <d...@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 <d...@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 <fmic...@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
>
--
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
