GNOME Bugzilla – Bug 641006
NetworkManager won't prioritise strongest of two APs with same ssid
Last modified: 2011-07-01 09:27:31 UTC
NetworkManager always connects to the previously connected Access Point instead of associating with the strongest signal where more than one AP is available with the same ssid. This is the case not only for home use with possibly two access points, but also in the enterprise environment where often 6 or more access points with the same ssid and encryption are distributed around a large building in order to make wireless access seamless for wireless users. This has been a problem for previous versions of NetworkManager also and exists still for my current version NetworkManager-0.8.1-10.git20100831.fc14.i686 which I run from Fedora F14 in a laptop. It seems that the connection logic is to access the previously connected access point if it is available even if a stronger one is present. I have tried defining two connections within NetworkManager with different connection "name"s - but placing the hardware address in the bssid field for the two separate APs (the APs are running on different channels). However the connection still "sticks" with the previous connected AP even if the alternate is considerably stronger, and it seems not currently possible to tell NetworkManager to transfer to the nearer strong signal (and presumably all packets are identified to the receiving Access Point by MAC address anyway ) so that it should in principle be possible to have the connection logic changed to account for a strength of signal based priority instead of the current system. Allowing roaming must be possible since this is how cellphone roaming has been done for many years.
I have the same need, have tried the same solutions and experienced the same failure. This is a major problem for me.
You're talking about roaming between multiple APs in the same SSID, which actually isn't anything NM handles, *except* when you lock a connection to a BSSID. If you set up a connection to an SSID, but leave the "BSSID" field empty, then all the roaming behavior is up to wpa_supplicant and the kernel drivers. The supplicant has the decision about which specific AP to associate with, and which AP to roam to when signals change. So if you don't create two connections and lock each to a BSSID, what's the behavior you experience? If the wrong AP is chosen, that indicates a problem in the supplicant or kernel drivers. Newer versions of wpa_supplicant should help the roaming issue as they have support for "background scanning" which ensures that the scan list is up-to-date and that roaming decisions are made with better information. wpa_supplicant 0.6.x does not have this capability.
After seeing your last comment perhaps the problem I am getting with poor roaming behaviour (even when two connections are locked to BSSID) is because the version in F14 is wpa_supplicant-0.6.8-10.fc14.i686 so is rather out of date!
So I think we can close this bug a NOTGNOME. Please reopen if this is not the case.