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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list