On Thu, Feb 10, 2011 at 6:49 PM, Dan Williams <[email protected]> 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 _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
