Good morning,

I'm really glad, that mikrotik made and released CAPsManager. But I think, CAPsManager should support Roaming between networks, something like it has UBNT and UniFi.
Please, add this in new versions. I think, I'm not alone, who want this.


Regards
Blažej

Do you mean as you move from one AP to another if they have the same SSID + Security (which CAPsMAN manages) then it should auto switch to the new AP?

Because this already happens.

And is usually more-so governed by the client device rather than the AP.

If you mean another type of roaming, please explain it more clearly.

Do you mean as you move from one AP to another if they have the same SSID + Security (which CAPsMAN manages) then it should auto switch to the new AP?

Because this already happens.

And is usually more-so governed by the client device rather than the AP.

If you mean another type of roaming, please explain it more clearly.

Yep, that's already happening with almost any kind of APs available these days. However in this case a brief disconnect happens when client roams from one AP to another, which is a no-go for some applications like VoIP.

I believe blazej44800 asks for a so called seamless/zero-handoff roaming, in which case disconnects either do not happen at all, or (at least) are significantly shorter. It used to be only available in costly solutions (with ruckus being the most affordable among them), but now Ubiquity claims that starting from v3.1.x UniFi supports it as well.

There is one more problem with "seamless" wi-fi.
If phone connects to ap1, then phone owner moves to ap2, but phone is still connected to ap1, with bad signal.
Ubiquty use centralized managment to drop clients from far away aps.
It would be nice if capsman could do the same thing.

You already can disconnect client with bad signal but it will not ensure seamless roaming to next ap.

I understand the request and it is a good one, but just wanted to note, that you can already configure access list to disconnect client with bad signal, and the client will then reconnect to the nearest AP

The client will decide itself where to connect. And it will not be seamless. I experimented a bit with client disconnection in such cases and can tell that you can easily disconnect the client that does not have better connection option to choose. Mobiles are moving and even they are in good area they can have temporarily bad signal. To disconnect them in this case is really silly because a second after the signal is good again. So what now?

Vote for this too.
Really like Mikrotik products and it's sad that ubnt already implemented some alternative solution while we don't have one.
But at least I hope it's starting to appear and developing CAPsMAN is a really good step.

I also please let me agree with this opinion.
I'm glad I also and will be able to build a roaming environment utilizing the capabilities of CAPsMAN.

Best regards.

Hi,
I vote for this too!

With regards,
Kuba

Here need it too. CAPsMAN is a great feature but lacks of 802.11r or similar solution.
CAPsMAN+usermanager+ovpn+dhcp+server+hotspot are all-in-one machine great wifi controller that lacks "native" seamless roaming.

Hello,

I think we don´t need to worrie about seamless/zero-handoff, ubnt controler did not had on first versions, soo i think its a question of time for capsMan to have it

I understand the request and it is a good one, but just wanted to note, that you can already configure access list to disconnect client with bad signal, and the client will then reconnect to the nearest AP

That's not even close to the capability of a fully managed zero handoff roaming situation. Zero reauth, virtual bss per client moving from ap to ap.

The amount of misinformation out there is astonishing!

First of all - roaming is always a client decision; When to roam, what AP to roam to, what band (2.4 or 5) to prefer.
The process is simple:
- All APs broadcast a beacon with their SSID
- Client connected to AP A will occasionally do a scan for other APs
- Client hears the beacon (actually a probe response, but let's keep it simple), showing the same SSID as the one it is already connected on
- Client notices that the signal strength of AP B is better, and that the SNR on AP C is better.
- Client chooses to start a roam to AP C (because the client's algorithm is coded to prefer a good SNR instead of a higher RSSI - this is called preemtive roaming)
- Client sends a Disassociation request frame to AP A and an Association request frame to AP C. Both APs accept.
- Client (and sometimes AP C) sends a gratuitous ARP and sometimes a DHCP Renew packet via AP C to inform upstream switches of its new location on the wired LAN.

As you can see, at no point is any AP doing anything to make the client roam.


What OP is talking about is Meru's Single Channel Architecture, which was copied by Ubiquiti with Zero Handoff. In simple terms, the AP dynamically creates a virtual access point for each associated client. The infrastructure (Meru controller) then moves this virtual access point to different APs depending on where it (controller) wants the client to be associated with. Essentially, it is fooling the client into thinking that there is no other AP, and therefore never actually roams. SCA/ZH have their advantages and disadvantages, but nowadays client devices have improved their roaming algorithms so much that the disadvantages far outweigh the advantages. Even Meru is moving away from that architecture.

802.11r/11k are standardised protocols which have been created to assist in client roaming. Note the use of the word assist, as it is still a client decision. 11r simply avoids the long trip to the RADIUS server whenever there is 802.1x authentication involved while 11k tells the client about neighbour APs so the client does not have to waste a lot of time scanning the air for new APs.

VoIP works fine even today on any standard WLAN, as long as it is set up properly and you use good VoIP handsets.

To see an example of a really bad roamer you don't need to go very far. a MikroTik wlan interface in Station mode will not scan or roam until it completely loses connectivity from the AP. This is called reactive roaming and no 'real' WiFi clients (phones, tablets, laptops) behave this badly.

nb: I say badly but the reality is that MT is designed as a fixed location PTP/PTMP endpoint so should never roam

First of all - roaming is always a client decision; When to roam, what AP to roam to, what band (2.4 or 5) to prefer.

FALSE
AP can kick a client if weak signal, max clients reached or member of load balancing group forcing roam.

nb: I say badly but the reality is that MT is designed as a fixed location PTP/PTMP endpoint so should never roam

FALSE
I have 44 radios (88 SSID's) connected to a single CCR1036 (capsman+usemanager) and i can have a perfect skype conversation between all SSID's roaming seamless in 2.4 and 5GHz.

I liked the term "reactive roaming" you have said before. I understand your concept and I'm sure there are better formulas to roam but mikrotik works very well and for a lot less money than any other solution .

Ap can kick. But then client decides autonomly where to try to connect.

First of all - roaming is always a client decision; When to roam, what AP to roam to, what band (2.4 or 5) to prefer.

FALSE
AP can kick a client if weak signal, max clients reached or member of load balancing group forcing roam.

And that is where the confusion begins. By kicking off the client (a deauth request), the AP is simply telling the client to disconnect from it. The client may decide to reconnect to the same AP or try another AP, based on it's association algorithms.

Careful using the term load-balancing. Most enterprise-grade vendors which have AP load balancing or band-balancing do their 'balancing' at the moment of association. Once a client is associated, LB/BB never kicks out forcefully as that will trigger an emergency/reactive roam.

Of course, since it's a client-driven process and there are no standards defined on the roaming algorithms, how quickly the emergency roam takes depends entirely on the clients.

nb: I say badly but the reality is that MT is designed as a fixed location PTP/PTMP endpoint so should never roam

FALSE
I have 44 radios (88 SSID's) connected to a single CCR1036 (capsman+usemanager) and i can have a perfect skype conversation between all SSID's roaming seamless in 2.4 and 5GHz.

Good for you, it just means your client devices are very good roamers.

Read my post again, I specify that using a MT device as a station results in poor roaming, because MikroTik is not designed to roam quickly and therefore has practically zero roaming processes. It simply waits until the signal is too low, disconnects, looks for new APs, and joins strongest signal.

Also, Skype is designed to work in the wild west internet, so has very good adaptive algorithms and would probably work well even if used over a MT in station mode. Try doing the same with SIP or an old console-based application or a MS Access database.

I liked the term "reactive roaming" you have said before. I understand your concept and I'm sure there are better formulas to roam but mikrotik works very well and for a lot less money than any other solution .

If it works well for your application, go for it. The point of this discussion is different. OP asked that "CAPsManager should support Roaming between networks" and a lot of misinformation ensued (including yours I'm afraid), so I wanted to set the record straight on how 802.11 WiFi works.

I'd be interested as well

Hi,

Controlling clients with access list prevents bad signal clients and low bandwidth.

The biggest difference with seamless roaming, multiple AP and unifi is the that clients see only 1 AP and 1 mac-address.
This prevent Apple device to constantly jump, register, disconnect over detected APs when in idle mode. This completely kills the bandwidth in a multi-AP environment...

Best Regards,
Julien

This prevent Apple device to constantly jump, register, disconnect over detected APs when in idle mode. This completely kills the bandwidth in a multi-AP environment...

Not really. Roaming is the way 802.11 is designed to work!. In fact, Apple devices tend to be the best behaved devices on a WiFi network and their roaming behaviour is well documented - http://support.apple.com/en-us/HT203068

Other manufacturers provide possibility to set the roaming threshold unlike apple. It has one fixed level at -70dbm. But anyway, mikrotik should have implemented 802.11k and 802.11r long time ago... I wonder when we will have it.

Disconnecting a client with a bad signal is not always the best solution: if the client moves closer to another AP then it may reconnect to the nearest one, but if the client moves far away from all APs, then he gets no service.

My two cents:
Maybe it could be made reliably with dedicated hardware: an AP composed by two radios, one normal and one that keeps scanning the frequencies and informs the CAPsMAN server about what each AP can sense, when CAPsMAN sees that a mac-address is received better on another managed AP, he can decide to try to disconnect/deauth the client from the previous AP.

This doesn't say anything about the position of the client. Maybe not scanning but sniffing the traffic could be helpful.

Reviving this one as more vendors are adding this now.

can Mikrotik add 802.11r, 802.11k and 802.11v to CAPsMan




https://support.apple.com/en-gb/HT202628

https://documentation.meraki.com/MR/WiF ... r_Overview

http://www.cisco.com/c/en/us/td/docs/wi ... r_010.html

http://www.engeniustech.com/resources/N ... asheet.pdf

Is there any new regarding the support of roaming in the way Ruckus do is (virtual ap in their terminology)?

the new wireless-rep package in 6.35rc has "Station Roaming support"

is working? if somebody has using, can we tell something about it?

how is the setup?

thanks

Pretty sure station roaming allows the MikroTik to roam when it is in station mode.... e.g. it does nothing if the mikrotik is acting as an access point.

Pretty sure station roaming allows the MikroTik to roam when it is in station mode.... e.g. it does nothing if the mikrotik is acting as an access point.

This is exactly what is it about.

Yes, I second the request to have a single channel/single-MAC architecture.
But we all should be aware that this technology will definitely need more horsepower hardware-wise to ensure all APs are sync.
Meru has dedicated ASICs in their APs, Extricom (with their Channel Blanket technology) have the processing power in their controllers.
I'm dealing with huge Extricom and Meru deployments almost every day and I must admit that I really love the way they work.
Especially when it comes to high density environments and multiplpe, non-interfering APs on the same channel with the same MAC address can communicate with multiple clients at multiple locations in the very same time slot - Extricom calls it "True Reuse" - I don't remember the Meru term for this.

To cut a long story short - all of us who want this feature should be 100% aware that we'll pay a lot more for the supporting hardware - especially when looking at the compeititors pricing...

Just my two cents,
-Chris

I understand the request and it is a good one, but just wanted to note, that you can already configure access list to disconnect client with bad signal, and the client will then reconnect to the nearest AP

If you actually understand the request: why do you sugest using the braindead (drop the client in the cold) ACL approach. A real wifi controller verifies that another AP is actually hearing the client and reception is better, then it will try use appropriate protocols for moving client if it supports it otherwise disconnect but then you know that the client is actually in range of another AP instead of leaving it out in the cold with no service at all instead of a low connection. 
These standards have emerged from the different proprietary technics (It would be lovley if Mikrotik would support them:  802.11k, 802.11v, and 802.11r

I agree,we need this.

+1 from me. Currently we have to use other vendors wifi

+1
Очень актуальный вопрос!!!
Спрос имеется огромный

+1

Controller based roaming would be fantastic

So, are we there yet? People tend to deploy expensive "proprietary" solutions only because of roaming support. We have few deployments that really need this, and there are problems with forceful disconnects from signal strength based access list entries.

+1

Please improve roaming.

Add actual standards 802.11r, 802.11k and 802.11v.. + controller based roaming would be great.+++

Please keep us informed in this issue ! Any comments from milkrotik ?! .. is it planed ? or is it no possible with current hardware ?

Oh, btw.

we need roaming.

It looks like Ubiquiti is developing 802.11rkv support for their unifi AC line. MikroTik should do the same to remain competitive.

Obviously someting was added in the latest 6.39 rc4 release...

Obviously someting was added in the latest 6.39 rc4 release...

No, this is station roaming, for MikroTik stations only (not phones, laptops, etc.)

Obviously someting was added in the latest 6.39 rc4 release...

No, this is station roaming, for MikroTik stations only (not phones, laptops, etc.)

I got all excited there for a second

+1
I would love 802.11r/k/v support.

I understand this topic is roaming, but I also get asked a lot about band steering on Capsman ? This would also be a nice feature to have ?


Sent from my iPhone using Tapatalk

Oh yes. I'm sure, everybody would love to have band steering.
Bu as there's no 802.11x standard for Band steering, I'm afraid it won't be implemented in CAPsMAN or w/l.
Every manufacturer implements it their own way and makes a big myth and secret around it.
For my perception a good start would be adjustable beacon rates per interface.
-Chris

Definitely 802.11r/k support is required for TRUE seamless wireless roaming. And nowadays MikroTik, beeing my favorite hardware solution, gives up its positions because it lacks these software features. No business will choose solution without true roaming support for the office with VoIP...

I olso need this future.
I have an RDP application witch must work without disconect when client moves between access points.
At this point, I must buy Ubiquity.

+1

Capsman is very useful to manage access points but it could do a bit more than configuration only.

802.11r,k,v is mandatory nowadays. Modern very widely available WIFI clients like Iphones and Samsung Galaxy phones (since S4) are compatible since years.

http://www.cisco.com/c/en/us/td/docs/wi ... guide.html

As well as entry level WIFI Access points available now with 802.11r support. For example Linksys RE7000 or Cisco WAP371.

http://www.linksys.com/us/support-artic ... Num=200528

http://www.cisco.com/c/en/us/products/w ... index.html

Compatibility list for Apple products :

https://support.apple.com/en-us/HT202628

I've seen inside 6.39 rc compatibility with background channel scan for Mikrotik station clients. This is a first step, but 802.11r,k,v should now be implemented in Capsmanager so that APs and Capsman can help compatible clients to roam optimally.

Is there a hardware compatibility problem, or a license problem to implement this ?

Some interesting technical details and roaming tests with a 802.11r setup :

http://revolutionwifi.blogspot.fr/2013/ ... ve-wi.html


Another big player in the computer world, if not the biggest one, support fast roaming (Microsoft Windows 10) :

https://msdn.microsoft.com/en-us/window ... nd-802-11r

And here an introduction to fast roaming protocols, 802.11r, 802.11k, 802.11v and what they do :

https://msdn.microsoft.com/en-us/window ... nd-802-11r

----------

802.11k (Neighbor Reports)

Wireless Access Points (APs) that support 802.11k are able to provide Neighbor Reports to devices running Windows 10. Neighbor Reports contain information about neighboring access points and allows the device to have a better understanding of its surroundings. Windows 10 takes advantage of this capability by shortening the list of channels that the device needs to scan before finding a neighboring AP to roam to.

802.11v (BSS Transition Management Frames)

APs that support 802.11v can now direct Windows 10 devices to roam to another AP that it deems will provide a better WLAN experience for the device. Windows 10 devices can now accept and respond to these Basic Service Set (BSS) Transition Management frames, leading to improved WLAN quality when connected to a network that supports 802.11v.

802.11r (Fast BSS Transition)

Fast BSS Transition reduces the time needed for a Windows 10 device to transition to an AP that supports 802.11r. This time reduction results from fewer frames being exchanged with the AP prior to data transfer. By decreasing the time before data transfer when the device roams from one AP to another, the connection quality is improved for latency sensitive applications, such as an active Skype call. Windows 10 supports Fast BSS Transitions over networks using 802.1X as the authentication method. Pre-Shared Key (PSK) and Open Networks are currently not supported.

With the combination of 802.11k, 802.11v, and 802.11r, Windows 10 takes advantage of established industry standards to improve the roaming experience for our users. VoIP applications can now take advantage of this improved roaming to deliver better call quality when users are not stationary.

-----------------

+1 - i think the prior posts (esp. the last 2 posts) make very clear how important this feature set has become now (802.11k and 802.11r ), and it def should be at or near the top of mikrotik's ROS list.

if it is/isnt, i really think we should at a min. get a offical reply from MT on the features timeline (or lack of), if possible.

over the past year / 18mo. i had 2 x large projects where we have had to use (and learn) a mt competitors product wifi product line, just so that we could implement true roaming (such that UDP and voip traffic can roam, was the job requirement at both sites, one was 70+ APs the other ~ 40 APs). We love (and always) use MT / ROS products, so this was not a direction we were happy to go in- but had no choice.

pls MT implement roaming (and also the ability to set the Beacon Interval in SSID broadcasts)

(or at a min. pls let us know your intentions on this feature)
thanks!

Two or three years ago 802.11k/v/r weren't really an must-have thing, they were nice but in reality most of devices were unable to properly use them. It's middle of the 2017 - now it's a must for any new deployments

Just wanted to say for everyone asking for roaming implementation like Ubiquiti has, did anyone actually tried it so far? I have several of this UniFI APs at one customer, and i tried zero hand off feature and made everything so much worse and unstable that i had to turn it off, it simple doesn't work as good as you would expect it..

Just wanted to say for everyone asking for roaming implementation like Ubiquiti has, did anyone actually tried it so far? I have several of this UniFI APs at one customer, and i tried zero hand off feature and made everything so much worse and unstable that i had to turn it off, it simple doesn't work as good as you would expect it..

Ubiquiti's "Zero Handoff" feature is different from what people here are asking for. It is effectively a "single channel" system like Meru/wiNG. Even Ubiquiti do not recommend it!

What people here are asking for is an equivalent to Ubiquiti's Fast-Roaming https://help.ubnt.com/hc/en-us/articles/115004662107

Just wanted to say for everyone asking for roaming implementation like Ubiquiti has, did anyone actually tried it so far? I have several of this UniFI APs at one customer, and i tried zero hand off feature and made everything so much worse and unstable that i had to turn it off, it simple doesn't work as good as you would expect it..

Ubiquiti's "Zero Handoff" feature is different from what people here are asking for. It is effectively a "single channel" system like Meru/wiNG. Even Ubiquiti do not recommend it!

What people here are asking for is an equivalent to Ubiquiti's Fast-Roaming https://help.ubnt.com/hc/en-us/articles/115004662107

Well yea its brand new thing introduced this year, i was just saying about zero handoff which was originally requested prior to 2017, im sure mikrotik will give us something similar to FastRoaming soon(i hope)

+1
I use mikrotik at home. And even I really need roaming support. Capsman ACL workarond works really terrible: it disconnects when I do not need it, and vice versa. Without ACL workaround clients dont switch APs when they should.

Some people argued here that this is client responsibility to swith AP. Yes, it is. But client logic relies on AP supported standards, like 802.11r/k.

So, I am waiting for substantial roaming implementation in Mikrotik. Otherwise entire Capsman development is just a waste.

+1
Why the Mikrotik not has the feature too?
incredible how late it is.

Some people argued here that this is client responsibility to swith AP. Yes, it is. But client logic relies on AP supported standards, like 802.11r/k.

Those standards are relatively recent/new and the number of client devices that are actually capable of using those is greatly exaggerated. Also they still do not allow the AP to dictate the client when and where to roam- that still is totally client's decision. The standards you are referring to just (potentially) make the roaming process faster/more efficient. But please note that clients that support (and can benefit from the use of) these standards are likely to be rather good roamers even on their own (i.e. without AP assistance).

What I'm trying to say is- do not expect any magic to happen once 802.11r and 802.11k are finally implemented (if ever). The 802.11r is believed to make a huge difference in the networks using WPA Enterprise. When using WPA Personal, however, the difference is usually hardly noticeable. Also take into account that enabling 802.11r usually breaks compatibility with the older clients that do not support 802.11r so you may end up living with two separate SSIDs- one for newer clients with 802.11r enables, and another one for older clients with 802.11r disabled.

Without ACL workaround clients dont switch APs when they should.

Try reducing the tx-power of your APs? That helps, really helps.

Try reducing the tx-power of your APs? That helps, really helps.

Sounds reasonable. I will definitely try. As I suppose AP Tx power should correlate with clients Tx power.
Would you recommended Tx power for me (I am a home user: iphone, android, laptops etc) for channels 1, 6, 11 and for 5G?
Thank you very much

Also they still do not allow the AP to dictate the client when and where to roam- that still is totally client's decision.

In my opinion only client should decide when it should roam. Not AP. Thats why I do not like ACL workaround, as I described in my first post.
But client logic depends on AP supported standards, signal strength, etc. We dont know, but we could discover clients behaviour via experiments. For example: https://habrahabr.ru/post/312948/

Those standards are relatively recent/new and the number of client devices that are actually capable of using those is greatly exaggerated.

Look around. What does people really want? Whey want to use WhatsApp/Viber/Skype/etc voice/video calls. They use iphone/ipad/android with latest firmware. Vast majority of these devices do support these standards (https://support.apple.com/en-gb/HT202628)

Even if implementation of these standards wont improve wifi roaming (as you described), I believe that Mikrotik SHOULD implement them in sake of marketing.
Really, people read articles, people use google, people consciously choose hardware for their SOHO wifi networks. And they definitely take into account 802.11r/k/etc standards.
So, without these standards entire Capsman development looks like a waste. Really.

For example OpenWRT supports 802.11r. I can not understand why this is a problem for Mikrotik.

Would you recommended Tx power for me (I am a home user: iphone, android, laptops etc) for channels 1, 6, 11 and for 5G?

I'm getting rather good results with 50mW output power, which means setting tx-power to 15dBm for 802.11ac-capable interfaces (where tx-power means total power) and 12dBm for double-chain (10dBm for triple-chain) non-802.11ac-capable interfaces (where tx-power means power per chain). You may also consider decreasing the tx-power for 2.4GHz interfaces even further to give 5GHz band some priority.

I use edimax wap1750 with 11r and 11k. 11r gives a FT on my SSID decode data using WiFi analyser android application = [WPA2-PSK+FT/WPA2-CCMP][ESS]

All clients - android phones and tablets - connect and roam except 1 laptop with old Intel WiFi. 11n I think. In that case it connects but falls asleep and needs to reconnect periodically. Solution was a second SSID without 11r. The laptop functions with 11k enabled but I leave that off. Simple!

Roaming is smooth. But still a client decision. This means a client may not switch until out of range of a AP then a brief 1 or 2 second delay while it connects to a nearby AP. This happens if the client moves quickly away. And also occurs if moving back and forth between AP frequently. In this case, the android phone gets lazy. It appears that it's roaming, once done, won't happen again for about 2 minutes.

11r is broadcast. If it's unsupported then the client has issues. 11k must be requested by the client and so shouldn't matter in a mixed environment. AFAIK.

Long post I know.

Mikrotik. Get 11r and 11k on your APs NOW!
It's brilliant.

Any equipment you buy today will support 11r and 11k. Anything in the last 2 years will too. Almost all iPhones supported these standards for several years.

These standards are supported in all modern WiFi chipsets. It's up to vendors to implement on top.

+++1, i hope MT have it (R K V)

+++1

+1
I would appriciate an official response on that important feature request from MikroTik team.
MikroTik team... are you there???

They are too busy to answer.
Hope implementing 802.11r/k

+1 for 802.11r, 802.11k, 802.11v support with Mikrotik. The implementation of this is really table stakes now for any controller/enterprise wireless option to be considered seriously.


I am making a money decision today not to use Mikrotik based on the lack of this feature.

+1.

+1

plus "band steering" and "airtime fairness".

Please, it's about time!

It would be nice in the meantime to have guidelines to optimize roaming with Capsman.

Till now i was rather pleased with the mikrotik routerboards, but right now here in germany the switch to voip is in progress, so my customers ask for WLAN-roaming, avoiding dual HP with simultanous DECT.
A lot of "better" smartphones come with the 802.11 r,k,v protocols for that, so my last two projects i dismounted the routerboard devices and substituted them with grandstream. Now, the handover runs much smoother. sorry for my lousy english, german is my mother - lang

Andreas Kemper

Today, I lost my project to implement Wifi network for 100 access points due to the fact that Mikrotik does not support 802.11r/k.

The project requirements for WiFi4EU are:

-supporting 2,4Ghz – 5Ghz ( same time)

-support IEEE 802.1x

support 802.11ac Wave I

support IEEE 802.11r

support IEEE 802.11k

support IEEE 802.11v

support 2x2 MIMO

support Hotspot 2.0

For Bulgaria only, vouchers earned EUR 1 695 000. But unfortunately Microtik does not meet the requirements. All my colleagues want and want to work with Mikrotik but unfortunately Microtik does not meet the requirements. Microtik It's time to wake up because other companies are ahead!

The project requirements for WiFi4EU are:
(..)
support IEEE 802.11r
(..)
But unfortunately Microtik does not meet the requirements.

We also wanted to participate in this project to extend our infrastructure. It seems, EU money will go to another company. Perhaps Mikrotik don't need this money?

The project requirements for WiFi4EU are:
(..)
support IEEE 802.11r
(..)
But unfortunately Microtik does not meet the requirements.

We also wanted to participate in this project to extend our infrastructure. It seems, EU money will go to another company. Perhaps Mikrotik don't need this money?

For Germany, Italy, Romania,France, Spain, the funds allocated for project WiFi4EU is 20 160 000 EURO. Mikrotik lost that money because they dont need this money. Another company example: ub*** ,cis***** etc. cover all requirements. MIkrotik why not wake up ?

The project requirements for WiFi4EU are:
(..)
support IEEE 802.11r
(..)
But unfortunately Microtik does not meet the requirements.

We also wanted to participate in this project to extend our infrastructure. It seems, EU money will go to another company. Perhaps Mikrotik don't need this money?

For Germany, Italy, Romania,France, Spain, the funds allocated for project WiFi4EU is 20 160 000 EURO. Mikrotik lost that money because they dont need this money. Another company example: ub*** ,cis***** etc. cover all requirements. MIkrotik why not wake up ?

Mikrotik is on Wireless one way road with old legacy kernel and own wireless driver with mostly basic hardware support....

++1

Since lately there is some developement in ROS6 features regarding long awaited features, I would like to bump this ones:

- dot11k/r/v based roaming / AP steering in CAPsManager
- dot11k/r/v based band steering (also without CAPsManager)
- option for airtime fairness

Also from other threads:
- support of wave2 (MU-MIMO, beamforming); viewtopic.php?t=145047
- tunable DTIM and beacon interval; viewtopic.php?t=116221
- stop broadcasting device model and ROS version with the beacon; viewtopic.php?t=133186
- support dot11d including country code; viewtopic.php?t=72840; viewtopic.php?t=144151

Since lately there is some developement in ROS6 features regarding long awaited features, I would like to bump this one.

- dot11k/r/v based roaming / AP steering in CAPsManager
- dot11k/r/v based band steering (also without CAPsManager)
- option for airtime fairness

Also from other threads:
- support of wave2 (MU-MIMO, beamforming); viewtopic.php?t=145047
- tunable DTIM and beacon interval; viewtopic.php?t=116221
- stop broadcasting device model and ROS version with the beacon; viewtopic.php?t=133186
- support dot11d including country code; viewtopic.php?t=72840; viewtopic.php?t=144151

Great news! In which version of ROS6? Is that only announcement of the development or some builds are available as of now?

Great news! In which version of ROS6? Is that only announcement of the development or some builds are available as of now?

Don't get me wrong! I was hopeful when dot1x and ike2 features were released in 6.45beta, that developement of often reqested features was sped up. So I brought up my favorites to give them some attention.

Don't get me wrong! I was hopeful when dot1x and ike2 features were released in 6.45beta, that developement of often reqested features was sped up. So I brought up my favorites to give them some attention.

Oh I see now. A hastily & hopeful interpretation of that by me, to the point that I upgraded multiple devices to v6.45.b62!!. So still waiting and hoping....at least some more attention might be drawn here reincarnating this wish list....

Reached this topic while looking for a solution to flaky roaming for Apple,Android, Microsoft and Linux-based devices in my house that relies on two Mikrotik RB's to achieve full-building coverage (linked by a RJ-45 cable).

I hope some form of technology can be engineered to help, if not fix this issue.
I understand that roaming is a client decision, but any way to hint the client that the closest/faster antenna is a better choice would be appreciated.

it is still this feature is not exist on Mikrotik CAPsMAN??
pls!! really?
i have 6.47 stable version of routerboard and still cannot found this functionality?
or i am wrong? can somebody help me