Hi,

I have finally made all my modifications to the code, implemented different
selection algorithms, only to find that when NM starts, it only finds a few
of the AP in range.

I've been trying to find where in the nm code the first scan is requested
(nm_supplicant_interface_request_scan or request_wireless_scan), but those
functions are only called whithin their definition .c 's and not from the
NetworkManager.c file.

My question is, At NM start, does it request for a scan, or does it use old
data (from the last time it started)?

If so, how can I make it request for a scan and use such data in order to
select the best AP?

Thanks for any help you can provide.

Cheers,

2010/7/15 Franco Miceli <[email protected]>

> Thank you so much for your answers. We've requested that the driver gets
> changed, since we don't have the resources to do it ourselves. We have yet
> to test the version that comes with the F11 build, but are confident that
> this mater gets solved.
>
> Again, thanks for the feedback.
>
> Cheers.
>
> 2010/7/14 Dan Williams <[email protected]>
>
> On Thu, 2010-07-08 at 12:13 -0300, Franco Miceli wrote:
>> > Dan,
>> >
>> > Regarding the subject of autoconnection to a favourites list. The
>> > changes proposed by our team include not only changing the selection
>> > algorithm to the one you proposed, but also to change the way the
>> > strength is calculated.
>> >
>> > We've made tests on the XO's quality reports by the driver and have
>> > noticed that it has a bug where the tx_retries are never being reset.
>> > That's the reason for not choosing the Q that comes from the driver.
>> > In order to accomplish our goals in the autoconnection feature for the
>> > XO we've decided to choose a SNR type of measurement for the quality.
>> >
>> > As I've seen the method "wireless_qual_to_percent" is only used inside
>> > nm_device_wifi and in functions relating to updating and setting the
>> > value for the AP.
>> > Our goal is to modify as little as possible, while accomplishing our
>> > goals.
>> >
>> > I would really appreciate your feedback if you see any inconveniences
>> > in these changes.
>>
>> Probably not, but you could also try to fix the driver to reset the
>> failed TX retries when it disconnects to the AP.  Other than that, it's
>> probably an OK path to take.
>>
>> Dan
>>
>>
>> > Thank you so much for your answers.
>> >
>> > Cheers,
>> >
>> > 2010/6/5 Dan Williams <[email protected]>
>> >
>> >         On Thu, 2010-05-27 at 05:56 +0200, Frederik Nnaji wrote:
>> >         > On Tue, May 25, 2010 at 18:45, Franco Miceli
>> >         > <[email protected]> wrote:
>> >         >         Therefore we want to to make some changes to the NM
>> >         code in
>> >         >         order to take into consideration other factors such
>> >         as: SNR,
>> >         >         loss %, etc.
>> >         >
>> >         >
>> >         > will you considered working on a UI for manually selecting
>> >         and
>> >         > configuring a symbolic visual representation of known APs
>> >         currently
>> >         > within range/sight?
>> >         > This would also help with GeoLocation, since it could use
>> >         "strength"
>> >         > to approximate My position by the nearness of a known AP
>> >         currently
>> >         > within sight.
>> >
>> >
>> >         We've thought about strength for a while, but in the end it
>> >         doesn't work
>> >         very well.  There are simply too many things that can affect
>> >         AP signal
>> >         strength to use it as a reliable measure of where you are.
>> >          It's better
>> >         to use *more than one* AP and triangulate to get better
>> >         accuracy than
>> >         just 100m radius of one AP's known location.  Using only one
>> >         AP, if
>> >         somebody turns on a microwave or uses a 2.4GHz DECT phone,
>> >         suddenly it
>> >         looks like you're 30 meters farther away from the AP than you
>> >         were 10
>> >         seconds ago...
>> >
>> >         Dan
>> >
>> >
>> >
>> >
>> > --
>> > 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
[email protected]
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Reply via email to