Re: Network Manager reason codes

On Thu, 2011-02-10 at 16:05 +0000, mike cloaked wrote:
> On Thu, Feb 10, 2011 at 1:52 PM, Jirka Klimes <jklimes redhat com> wrote:
> > On Thursday 10 of February 2011 14:20:12 Byte Soup wrote:
> >> Hi All,
> >>
> >> I was wondering about the reason codes Im seeing in my /var/log/syslog, for
> >> example:
> >>
> >> Feb 10 13:15:57 Homer NetworkManager: <info>  (eth1): supplicant connection
> >> state:  associating -> disconnected
> >> Feb 10 13:15:59 Homer NetworkManager: <info>  (eth1): supplicant connection
> >> state:  disconnected -> scanning
> >> Feb 10 13:16:11 Homer NetworkManager: <info>  (eth1): supplicant connection
> >> state:  scanning -> disconnected
> >> Feb 10 13:16:13 Homer NetworkManager: <info>  (eth1): device state change:
> >> 8 -> 3 (reason 11)
> >> Feb 10 13:16:13 Homer NetworkManager: <info>  (eth1): deactivating device
> >> (reason: 11).
> >>
> >> Is there a reference for the reason codes? Also Im working in a location
> >> where there are a number of different access points for the same network.
> >> Can I configure network manager to just associated to one MAC address,
> >> because it seems to be hopping from one to another and then subsequently my
> >> VPN connection drops
> >>
> >> Thanks
> >>
> >> -Mark
> >
> > You can find the reason codes in
> >
> >
> > If you want to use just one AP, you can "lock" a connection to it via BSSID
> > field in nm-connection-editor.
> >
> > right-click on nm-applet -> "Edit Connections..." ->click to "Wireless tab" ->
> > find your connection -> click "Edit..." -> on "Wireless tab" add MAC address of
> > your AP to BSSID edit field and save the connection.
> If there are two different connections defined in NM with the same
> ssid and encryption but each with different BSSID values (i.e. because
> there are two APs
> in different parts of a building for example), how does NM determine
> which of the two to associate with on initial connection?

The connection is a candidate for activation if the SSID is seen in the
scan list, and if it's BSSD-locked, the BSSID must also be seen in the
scan list.  Then, of the connections that are candidates, the one that
was most recently connected to is chosen.

> 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

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.

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.

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.

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.

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.


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