Firstly, I’d rather mikrotik concentrate on what they do really well with the hardware and software on the routerboards rather than try and “open up” the platform. I don’t think it needs it and it would just create a support headache for them. If you want an OpenWRT box then buy one and not a mikrotik router.
Also creating the drivers in house means that they can get the best from the hardware and have control of the whole unit. Otherwise they’d be at the mercy of third parties to update drivers if problems/exploits are found and that has the potential to not to happen for other than the new hardware. I want the knowledge that if an exploit/issue is found then I can put the latest RouterOS (once the fix is confirmed in it from the changelogs) onto any routerboard I own and the problem is fixed and not waiting on a third party to provide a driver update as well at some unknown point in the future.
I believe you are referring to Single Channel Architecture from what was called ‘Meru’ now Fortinet. That is a whole new ball game and is not controlling roaming between APs. The difference with SCA is that there is NO roaming on the part of the client as there is only one BSSID and therefore with only one BSSID the client has no need to roam as they believe they are always connected to the same device. Fortinet SCA also introduced virtual cells, where they allow multiple BSSIDs on multiple channels, in which case even with this system, the client decides when to roam between virtual cells. Not the AP or the controller, the client.
Shame that sales departments sell products not engineers.
The client devices make the decision to roam on every meshed network product, not the AP, regardless of what the marketing guys want you to believe. The only decision an AP, or a Meshed set of APs can ever do is inform the client with data about the environment that the client may not have been able to determine for itself. E.g. how many clients are connected to an AP, how occupied an AP is, what other APs there are nearby and all of that data can then be passed to the client via additional standards such as 802.11k/r/v. Once the client has received that data, IT then decides where to roam to.
To put it another way, the AP can suggest ideas to the connected device, inform the client about what the best thing is to do. But if the client wants to act stupid and do something different, that’s up the client device. The AP cannot force it where to roam to. Regardless of the clever wording used by their marketing department to suggest or claim otherwise.
There’s been a lot of technical logics been discussing, it seems like MikroTik is doing the right way, but the only result is : BAD.
As an end users, we only care about the result, no matter how high end or how deep you can go for to explain it, we just care about the result. If MikroTik is the only AP manufacturer in the world, I will believe what you explain to us, but when there are a lot of manufacturers out there, and many of them doing it well, I can’t convince myself to believe it.
You are right, an old printer or 11bgn IOT device will not roam and also some chaps with old phones. But you don;t care as they don’t need to move really.
But 90% of your customers that move from one AP or extender to another one are mobile phones/tablets and those are the ones complain that they
are no connected or have glitches etc.
Phones/tablets are since couple of years perfectly able to support all the new standards to switch/change.
My point is, I like to have ROS, the swiss knife for Wireless which can do all Wifi applications with one device and one SW.
But we come to a point where I want more performance and functions for indoor use cases, and I will never us an RB4011 for instance as an outdoor PtP device.
Instead of that I would like to have some additional things that would allow to optimise further indoor networks on devices such as RB4011.
In the absence of that, I do use tuned Wifi access lists, but its pretty much a set up per each device, per location to be assigned to one or another. This does not scale at all and needs a lot of testing to work.
If you’ve capsman setup correctly then devices should roam seamlessly between AP’s. That’s my, and others, experience of it. If devices aren’t roaming properly then it’s worth trying a survey of the area and looking at power levels on your AP’s along with access lists.
improving wifi roaming requires solid skill´s and experience on design, configuration and trouble-shooting of the wireless network, and it must be tested against client devices to spot client device bugs or limitations
you cannot get good roaming only taking in count which AP you buy
for example i have seen some android devices who roam nice and others who dont
for example i have seen some windows laptops who roam nice and others who dont
for example i have seen some wireless NIC on a laptop who roam nice with one version of driver and with another version of driver dont roam at all
in wifi networks client device always is a major part of the equation
There are several manufacturers who offer this option. The key point is the use of a single BSSID across APs, making the client move from one AP to the other without any participation and without it even knowing about it. Thus it also cannot go wrong based on client behavior or limitations (like not supporting newer protocols).
The limitation of course is that such a single-BSSID network can only live on a single channel, and so it limits the available bandwidth when compared to a network of a single SSID across multiple APs with different channels in use.
But as you write, you could still make a config with the same SSID on different channels each with a BSSID, the client would have to decide to roam between them but it would not affect performance assuming that the quality of the channels is the same. Maybe in an environment where some channels have interference from neighbors and others have not, it would be a problem that clients stick on the interfered channels, but the admin (or the controller software) could just turn those channels off and thus force everyone to the working channel(s).
Of course to implement such a system there have to be changes in the drivers and upper layer software, and there is a need for a “controller” to manage the actual connections (although one of the APs could take this function). It will also help when the configuration is done professionally, with measurements of the covered area of each AP and entering this data in a map understood by the controller. It may not be the market that MikroTik is interested in (also seeing that their top-of-the-line ceiling AP is a $69 unit with 2 chains only on each band).
It could also be that this system is somehow patented and needs to be licensed. I see that another wellknown AP manufacturer in the slightly higher market segment does not offer it either, probably for a reason.
Yeah, but as was written before this can also backfire on you, especially when you have no complete coverage of the entire building.
We had another installation where there was some feature configured to auto-add every device to a blacklist for 1 minute every 4 hours, to force everyone to roam should they have moved after initial connection.
As there was only coverage from 1 AP in certain spots, this effectively kicked off everyone in those spots in the middle of the working day.
Not a big issue when the network is only used for browsing, but in our case there were RDP and Citrix sessions that were interrupted etc.
from the moment of the design in which the location of the ap is defined you must take into account these adjustments to improve or force roaming without punishing the coverage
if the initial design did not contemplate that, a configuration will not solve it
Well, I’m just telling my feeling after comparing to the cheapest TP-Link mesh kit with k/v/r supported system, it makes my hAP AC2 + cAP AC looks like an idiot. Maximum download speed, roaming performance, handling multi clients, stability, all lost.
A person here said MikroTik don’t use chipset stock driver due to better maintenance and no need to ask for mercy if any problem from the driver, end up we are now asking for mercy for MikroTik to add those highly demanded features like k/v/r and band steering.
If you only use MikroTik solution, you see no problem, until you try another solution from other vendor, you will know what we are talking about.
One man complaint, maybe mistake; many complaints, must be a reason.
Anyone who has attended or watched one of Ron’s panels on WiFi realizes he is a very trustworthy source for information and advice. I would heed his words.
What I do see repeatedly mentioned is 802.11k/r/v, which as of now (to my knowledge) is completely absent from RouterOS.
I pray the Mikrotik guys bump that up on the priority roadmap. It’s really important. When I hear “Mikrotik” brought up it’s almost always followed by “wireless”. I’d wager the majority of Mikrotik device sales are wireless in nature. The 802.11k/r/v standards are one of the highlight misses of Mikrotik devices.
This would be a GREAT Christmas 2019 holiday present to your customers!
Edit: Realizing that maybe the standards are unknown to some… so a quick elaboration:
802.11k = “Neighbor Reports”
802.11r = “Fast BSS Transition”
802.11v = “BSS Transition Management Frames”
…all intended to assist in roaming in CAP environments. As Ron said, it provides extended data to clients to assist with AP decisions/transitions and generally make them more accurate and smooth.
Seamless roaming is mostly related to network design like: proper Tx power level, proper frequency and channel width, activated datarates, activated chains, activated technologies and adjusted rest parameters available on MT ROS. Also distance between CAPs should be adjusted. Interference from outside - other WiFis and non WiFi interference should be considered.
WiFi seamless roaming itself requires a huge level of expertise. At least CWNA level.
Technologies like 802.11k can speed up roaming for fast moving client.
802.11v -can help select less congested AP (if available near).
802.11r- can help speed up roaming if you are using EAP authentication.
With proper RF design and settings on MT Capsman → all MT wireless hardware (which supports b/g/n/ or a/n/ac) I tested can do seamless Roaming for voice and video like skype, viber, whatsup, etc. No ping losses etc.
No feel of call or moving picture disruption. In case CAPs are positioned with more than -70dBm distance between each other (Tx power for CAPs should not exceed clients Tx power level) than some video disruptions may be noticed, but not voice.
In case you start high data throughput tests between client and AP - the seamless roaming can become problematic, as there becomes less time for the client to scan for other APs to roam to.
Of course It would be nice if MT team additionally implements (at least experimental 802.11k) with enable/disable option per SSID for mobile clients(which support it) to do less channel scanning during movement from one AP to another.
True, I did make sure I have about -70dBm for both APs in the handover area, by the time i wrote this post MT had a hard time to handover my client and eventually dropped connection after 10 pings, but with recent firmware it seems getting better as it will handover better and no crazy ping drop like before, and the log file is now showing “registered to other device in network” just like CAPsMAN do, it was used to be like “disconnected, extensive data loss”, I think MT has done some fixes on handover, good job MT!
To Nest. The VAP (virtual AP) of Fortinet comes with “some” control by the wireless controller in the roaming decision of the client. The wireless controller (e.g. Fortigate) steers the FortiAP in the way they respond to the request for joining by a client. It is still the client who decides, but the client is tricked in the number of options it has. This is a professional system, that can be rolled out in a conference centre or other business. https://help.fortinet.com/fos60hlp/60/Content/FortiOS/fortigate-wireless/client-load-balance.htm?Highlight=wifi%20roaming : “the wireless controller selects the least busy access point that is closest to the new client and this access point is the one that responds to the client and the one that the client joins”.
In my current implementations which are not “high density” deployments, rather on a large campus, and not for business, there is no need for this feature. (FortiAP is very expensive compared to MKT) Actually other lower cost systems, besides enforcing airtime fairness, use RSSI absolute and relative values to kick out weak clients (who take too much airtime anyway) to force them to “recalculate” their AP selection. After the short blacklist timeout, they might come back.
