Re: Which AP is chosen when several are found for the same SSID?



Thanks for the info ... I just have one more question, see inline.

On Thu, Oct 2, 2008 at 3:18 PM, Dan Williams <dcbw redhat com> wrote:
On Wed, 2008-10-01 at 19:14 -0400, Jose Aliste wrote:
> Hi all,
>
> I want to ask the question in the subject:
> Which AP is chosen when several are found for the same SSID?
> I ask this because I see three AP from mi wireless network at my
> office. Two of them are "802.11G" AP are the other one is only
> "802.11B" the signal for the slow one is better(it is nearer) and NM
> always connects to it. However, I would like to NM to connect to one
> of the others because even with less signal the connection is
> better( 33mb/s against the 11mb/s of  a b connection!).

At this moment, this is left up to the driver and the supplicant.  The
supplicant will apparently choose the AP with the best signal strength
(since the scan results for the same SSID are sorted by signal
strength), but the driver can also choose to roam from AP to AP based on
other criteria.
 

> So, how can I tell NM to use the AP I need ?

You can try to set the BSSID in the connection editor to lock it onto
one of the APs, but the driver has the discretion to ignore that and
roam to an AP it thinks is better.  We don't yet have the facility to
lock to 802.11g at _any_ level of the stack, not just NetworkManager.

I am using NM 0.6 in Hardy and If I do as you or aaron said(keeping in th bssid only the address of the ap I want), but it does not work.
However, If I go with manual config and I set the  AP by using the  wireless-ap option in the /etc/network/interfaces  then everything works... Would I be more lucky in NM 0.7, I mean does NM 0.7 try to force the AP? Btw wpa_supplicant is used even if I am not using WPA?

Thanks

José

 
You could try setting the data rate, but that doesn't always do what you
want since you can only set it to one value, and the card would be
unable to rate-scale based on signal quality of the locked AP.

In short, can't really be done, but this is only partly NM's fault.
There's a lot more work in the stack from drivers, to WEXT, to
wpa_supplicant to make sure this works the way you want it.

Dan





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]