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 <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
