Re: Network Manager reason codes



On Thu, Feb 10, 2011 at 6:49 PM, Dan Williams <dcbw redhat com> wrote:

>> Is there a way to get NM to always choose the one with the strongest
>> signal at the time of making the initial connection?
>
> Not at this time, but it's reasonable to pick the highest signal
> strength AP if there are two connections for the same SSID but different
> BSSIDs.

I would love this to actually happen!  But it seems not to with the
version I have (NetworkManager-0.8.1-10.git20100831.fc14)
In fact in this case I find it exceptionally difficult to get a
connection with the near strong one if it previously had connected to
the weaker one.
If I remove all previously stored connections to this ssid and start
again then it does connect to the strong near one and it can be locked
to the bssid of course.

> We shouldn't be using strongest signal in general though, because that
> often doesn't do what users want in cases where there are multiple
> networks the user periodically connects to.
>
> Here's a case: you've connected to your neighbors wifi before when your
> ISP goes down.  But almost all of the time you want to connect to your
> own wifi.  But in the 2nd floor room your wifi is weaker than your
> neighbors.  If the "strongest" signal were preferred, NM would connect
> to your neighbors wifi instead of your own.

That is of course fine - but there are use cases where the two APs are
both in one's own home - and both have the same ssid.... and that
presents a problem - at least for me.

> Plus, signal strength is wildly variable and it's only useful to compare
> signal strengths when the difference is large (say, 25+%).  Deciding to
> connect to a wifi network that's 5% or 10% better than some other
> network is making a choice based on faulty information.

True but if the near one is about 100% and the far one is about 25%
and both have the same ssid and are on the same network then it seems
odd to connect to the 25% signal as a preference irrespective of the
historical connection to the bssid corresponding to the weaker signal.

I suppose what I am saying is that all of the logic you present is
fine but there should perhaps be an exception if the system sees two
signals on different channels with the same ssid with very different
signal levels.... it is this specific instance where maybe an
additional selection criterion is used by NM?

>
> Thus "most recently used" generally provides better, more understandable
> behavior.  If you boot your laptop at home, you'll connect to your home
> network because that's the most recent network you used that NM can see.
> Instead of having NM appear to prefer some network randomly over another
> just because it has 10% better signal strength, even though you almost
> never connect to that network.

If you then take it to work presumably it won't then try to connect to
the home (non-existent network at that stage) andwait before
connecting to the work one will it?

> There are clearly some optimizations we can do, including keeping around
> a connect-count, to determine what networks you use more often, and
> perhaps in combination with the "most recently used" information, make a
> better choice.
>
>> What is the internal NM decision if one then moves from from near the
>> first AP to the other one so that the signal that was weak initially
>> then later becomes the stronger signal?
>
> NM doesn't make this decision at all.  wpa_supplicant and the kernel
> drivers make the decision to roam between APs in the same BSS depending
> on signal strength, error rates, etc.  If you do not lock the connection
> to a specific BSSID, then the roaming decisions are all made in the
> driver and the supplicant.

OK - and what does the supplicant/driver do in the instance that you
have two APs on different channels with the same ssid and initially
the first is at 100% with the second hovering around 20 -40% and then
move to a position where that reverses?  If there is a really solid
difference in signal and despite variations over some range one
maintains a significant difference over a period of minutes would that
make a difference to the decision logic?

> wpa_supplicant 0.6.x and earlier have known problems here, and may
> gratuitously roam between APs of similar signal strength.
> wpa_supplicant 0.7.x and later are smarter about when to roam, and will
> only roam between APs when the current AP is much worse than a candidate
> AP, and will also perform background scanning when the current AP's
> strength gets too low.

I guess then that this answers the intended behaviour in my previous
paragraph - and presume this remains the same logic for bersion 0.8.x
?

-- 
mike c


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