That does not really work… or: it does not work very well.
You will need a lot more tweaking and will have to live with short interruptions to get WiFi roaming this way.
But what is the station-roaming setting doing? Changing parameters in station mode to make that way of roaming work better?
That totally depends on the client. Some clients roam nicely, other clients do not roam at all.
Up until recently RouterOS did not support station roaming at all- it was sticking to a single AP until connection is completely lost, at which point it started to search for a new AP to connect to. Then initial support for the station mode roaming was added in 6.35 (wireless-rep package only)- RouterOS client started to do background search periodically, looking for a better AP (read more here). And now you can turn that feature on and off.
Yes, laptops have no problem - drivers in Windows allow to set roaming aggressiveness (I use high) and roaming preference of bandwidth or distance (I use bandwidth). But there is no setting in Android phones for example and they are not roaming well - sticking on the first AP in situation where they are moved very close to another AP.
In fact, I don’t know anything about Mikrotik AP controller - if it is making roaming better or not. That’s because I don’t use Mikrotik as APs - I simply use the same SSID and security on all the APs. Other brand controllers have some roaming functions, but I don’t use them either and don’t know what are they doing. If it is something more deep about roaming in Mikrotik systems written somewhere, please paste a link
First I did upgrades from 6.37.4 (bugfix) to 6.38.3 on CRS125 (switch with caps-man) hree hAPac in cap-mode and one RB750GR3 : no problems at all!
(Remark: all bridges have RSTP on!)
Then I upgraded the router. It’s an RB3011… After this it lost the connection to the CRS125.
RB3011: back to 6.37.4: fine as ever
RB3011: to 6.38.3: broken connection
RB3011: disable RSTP (set to none!) on the bridge containing the connection interface to the CRS125 and now it works!
From my experience, it totally depends on the Android device in use. It looks like different devices may have different WiFi-roaming-related settings even on the same Android version. Also, you can temporarily activate aggressive WiFi roaming in the Developer menu, but, unfortunately, that setting is getting reset on each reboot.
I did quite a lot of experiments while building a CAPsMAN-powered WiFi network about a year ago, and come up with the following conclusions:
Most Android phones roam rather nicely when roaming decision is made by the phone itself.
There are many Android phones which roam rather badly (causing lengthy disconnects) when being forcefully kicked off by an AP.
Reducing AP power usually leads to a significantly better roaming experience (this is a nice/gentle way to ask Android phone to roam earlier).
This is what I mean by “it does not really work”. Many other manufacturers have the same problems: dependance on client software and settings.
But with e.g. Aruba networks the wireless system ITSELF controls the roaming, detecting which AP the client is closest to and communication from there.
This is of course not possible with a collection of standalone WiFi AP’s running the same SSID, you need a co-operating system that does the roaming
at the radio level, not at the connection level.
Probably, that’s because it is the only thing that standards call “roaming”?
Technically, that is not a roaming (even though the outcome is the same), but rather a way to fool wireless client making it believe that it’s constantly talking to exactly the same AP, even though different radios are involved at different moments. That approach has its own drawbacks. And as it is always the case with wireless, it may or may not work as expected depending on the requirements and environment.
I had similar probs with RB2011. I was testing VLANs, bridges and VLANs in the switch chip on 6.38.1 and then 6.39rc33. Contacted support. Reply below.
We found the problem. RSTP currently does not work together with VLAN configurations on small 5 port Atheros switch chips. You will have to either disable RSTP or reconfigure VLANs with bridges if RSTP is necessary.
I am updated 2011UAS-2HnD from version 6.34.6 with wireless-cm2 package to 6.38.3.
And i have a problem - old android 2.3.5 phone Lenovo can’t connect through wifi, but in 6.34.6 it works good.
When I try to new connect with WDS i see in log:
wireless,info wlan1: WPS virtual button pushed
wireless,debug wlan1: 00:12:FE:AF:35:59 attempts to associate
wireless,info wlan1: WPS association from 00:12:FE:AF:35:59
wireless,debug wlan1: 00:12:FE:AF:35:59 not in local ACL, by default accept
wireless,info 00:12:FE:AF:35:59@wlan1: connected
wireless,info wlan1: WPS of 00:12:FE:AF:35:59 started, associated
wireless,debug wlan1: 00:12:FE:AF:35:59 attempts to associate
wireless,info 00:12:FE:AF:35:59@wlan1: reassociating
wireless,info wlan1: WPS of 00:12:FE:AF:35:59 interrupted
wireless,info 00:12:FE:AF:35:59@wlan1: disconnected, ok
wireless,info wlan1: WPS association from 00:12:FE:AF:35:59
wireless,debug wlan1: 00:12:FE:AF:35:59 not in local ACL, by default accept
wireless,info 00:12:FE:AF:35:59@wlan1: connected
wireless,info wlan1: WPS of 00:12:FE:AF:35:59 started, associated
wireless,debug wlan1: 00:12:FE:AF:35:59 attempts to associate
wireless,info 00:12:FE:AF:35:59@wlan1: reassociating
wireless,info wlan1: WPS of 00:12:FE:AF:35:59 interrupted
wireless,info 00:12:FE:AF:35:59@wlan1: disconnected, ok
wireless,info wlan1: WPS association from 00:12:FE:AF:35:59
wireless,debug wlan1: 00:12:FE:AF:35:59 not in local ACL, by default accept
wireless,info 00:12:FE:AF:35:59@wlan1: connected
wireless,info wlan1: WPS of 00:12:FE:AF:35:59 started, associated
wireless,debug wlan1: 00:12:FE:AF:35:59 attempts to associate
wireless,info 00:12:FE:AF:35:59@wlan1: reassociating
wireless,info wlan1: WPS of 00:12:FE:AF:35:59 interrupted
wireless,info 00:12:FE:AF:35:59@wlan1: disconnected, ok
At the same time android 4.4.4 phone connect well.
miharoot: that is a known problem that first occurred in 6.37 I think. you only notice it now because you skipped that version.
old devices sometimes don’t work with newer RouterOS, and it looks like this is not going to be fixed.
Either someone put up a new RADAR station in my neighborhood right after this update or there were undocumented changes in DFS behaviour for Germany. With previous firmwares it was no problem to stay on channel 116, with this release my hAP ac constantly detects RADAR and kicks my 5 GHz clients. Same goes for my wAP ac on the latest beta. Anyone else seeing this?
It even detected RADAR on 5260, never had any device detect anything on that channel here. German precipitation radar is around 5600. Went back to v6.38.2 and the DFS problems disappeared. So definitely some undocumented changes. @Mikrotik: Any clue what’s going on?
Edit: Sorry, I was on v6.38.1 actually, not .2 The .2 version is also problematic and was never available via autoupdate I believe.
