We made a table with some clarifications, can you guys let me know if this clears up some confusion? I see that Documentation and YouTube video still leaves some questions unanswered. So let’s try it like this:
1 Like
at least for me this is fair enough
If any edge cases are missing in the table, let us know, and we will make the ULTIMATE guide for packages 
i think Youtube video does a good job clarifying most of the situation.
What happens is that it is a complicated turning point, not achievable on a video
is not only the wireless matter, the reduced storage memory on some generation of devices, new generation of wireless devices, new operating system, 802.11ax etc
we can expect some friction, but is a necesary step to get back on track the wireless development
The unfortunate position of the RB4011iGS+5HacQ2HnD w.r.t. WiFi support could be clarified better.
Shame. From YT and press notes I was under impression that it will be possible to have wifiwave, legacy CAPsMAN and use onboard wifi interface 
Shame? On contrary, a respect for MikroTik. They did exactly the opposite of planned obsolescence.
MikroTik brought new software to old 802.11ac ARM devices. Now you can have 802.11r/k/v seamless fast roaming, with one WiFi/WifiWave2 CAPsMAN, without a need to replace wAP ac or else devices.
Same here … the Situation for the RB4011iGS+5HacQ2HnD is not 100% clear for me 
br, Richard
Easy, like manual says RB4011iGS+5HacQ2HnD-IN (no support for the 2.4GHz interface). Installing the new driver will remove 2GHz, only 5GHz will work
plz dont forget the mipsbe with AC gear… also need some tunning in drivers!!!
mipsbe devices’ CPU is underpowered and hardly manages decent throughputs even with legacy wireless. New wave2/wifi is even more demanding on CPU (specially for memory).
But it is not in that table. It should be in that table, and also there should be a clear warning on the website.
Remember this is not some old obsolete product. This is a product you are selling today, with this promotional sales pitch:
RB4011 series - amazingly powerful routers with ten Gigabit ports, SFP+ 10Gbps interface and IPsec hardware acceleration for a great price!
The RB4011 uses a quad core Cortex A15 CPU, same as in our carrier grade RB1100AHx4 unit. The unit is equipped with 1GB of RAM, can provide PoE output on port #10 and comes with a compact and professional looking solid metal enclosure in matte black.
RB4011iGS+5HacQ2HnD-IN (WiFi model) is dual band, four chain unit with a supported data rate of up to 1733 Mbps in 5GHz. For legacy devices, the unit also has a dual chain 2GHz wireless card installed in miniPCI-e slot.
Nowhere it is mentioned that it in reality is a dead-end product where you have to select between the old WiFi drivers or not having the 2GHz support. That only surfaces once you have bought it and dive into the details of the manual.
But I have seen that before. I bought a CCR2004-16G-2S+ after reading on that same website that it has USB3, only to discover later that it comes without USB3. That false information has remained on the websites for months thereafter, and still is in the block diagram. Apparently correct information on the product website is not a very high priority.
(just as there still are no separate performance figures for v6 and v7, or even specification under which version tests were done)
Table is about specific products, it is said above each table. Products not in the table - not supported. Think about it that way. I don’t see RB133c either. What could it mean?
Perhaps the RB4011 deserves a footnote in the @normis table, given you lose 2.4Ghz with qcom-ac?
Similar with Audience, it needs a footnote too. e.g. it’s pitched as “meshable”, but that requires manual configuration with qcom-ac to wireless “mesh”.
According to the compatibility table RB4011 with wireless package in dual-capsman configuration internal WiFi interfaces with legacy drivers must work. But both internal wifi interfaces in cap mode can’t connect to legacy CAPsMAN. Have tried with shared network interface and with dedicated pseudo-lo bridge:
/caps-man manager interface
set [ find default=yes ] forbid=yes
add disabled=no interface=vlan9 - Shared to both CAPsMAN
add disabled=no interface=br-lo - Dedicated to “internal” 4011 CAPs
/interface wireless cap
set bridge=bridge caps-man-addresses=192.168.255.1 discovery-interfaces=br-lo enabled=yes interfaces=wlan1,wlan2
Logs show in any cases like that:
13:44:30 caps,debug CAP Connect->Select
13:44:30 caps,debug CAP did not find suitable CAPsMAN
13:44:30 caps,debug CAP Select->Sulking
13:44:34 ipsec,error payload missing: SA
13:44:35 caps,debug CAP Sulking->Discover
13:44:35 caps,debug CAP discovery target list:
13:44:35 caps,debug ::ffff:192.168.255.1:5246
13:44:38 caps,debug CAP discovery over, results:
13:44:38 caps,debug rt-core (::ffff:192.168.255.1:5246)
13:44:38 caps,debug CAP Discover->Select
13:44:38 caps,info CAP selected CAPsMAN rt-core (::ffff:192.168.255.1:5246)
13:44:38 caps,debug CAP Select->Connect
13:44:46 caps,info 44:AF:28:2D:A5:32@ap-3 reassociating
13:44:46 caps,debug 44:AF:28:2D:A5:32@ap-3 connected, signal strength -66
13:44:58 caps,info CAP connect to rt-core (::ffff:192.168.255.1:5246) failed: timeout
13:44:58 caps,info CAP failed to join rt-core (::ffff:192.168.255.1:5246)
Any “external” devices work with both CAPsMAN successfully.
One suggestion
Post what driver is needed on device page.
It will be easier
Suggestion: we the MikroTik user base, need an abstraction. You know the hardware. Let us learn the software. By mixing everything it is really getting confusing. I think a better approach is needed. A single abstraction layer that figures it all out for us. As users we just implement generic WiFi concepts.
So, one wifi menu for all hardware. One Capsman menu for all hardware. The software does the right thing.
Legacy wireless config is so much different in some places. So it would take an extra effort for MT developers to get an abstraction right. They would need to expose different config options depending on hardware and installed wireless/wifi package. Look at all these nv2/ and all the other massive wireless options (base rates, ampdu, etc ) in legacy driver and the much less, different and non-compatible QCOM driver options. Kind of silly in my eyes to move that in one config section. I am sure MT thought about it, but decided against.
Actually, I would love to have my “wAP ac/hAP ac” devices managed by the same CAPsMAN and have roaming support even at the price of the lower throughput and higher CPU/RAM utilization, if possible in any way. Most times, wifi is not used to the max, but it is important just to have a connection - messengers, e-mail, reading (yes, some of us don’t care about videos).
So, if possible in any way, please make mipsbe devices compatible with new CAPsMAN. It would be fine if you have to remove all the other unnecessary stuff from them, like VPNs (all of them), everything from Tools menu, just make them simple CAPs…
I know this won’t happen, but if you don’t ask…
I think the issue is that CAPsMAN is not really a management layer for an abstracted WiFi device, but just a tool to copy a block of configuration data from the local device to the managed devices. That is why you also need to install the WiFi drivers on the CAPsMAN management device, even when it is not running WiFi at all.
With the new drivers, the configuration block structure is completely different, and everything had to be replaced with a new version.
So there is no chance of the new version managing old devices. When that would have been practical, they could have done it already.
I am running a managed WiFi system from a similar company (the one named U*) and there it has been done differently. The management software manages devices of different generations and chip manufacturers. The configuration data is distributed as JSON files with generic parameters and their values. Each device receives its properly prepared JSON file (from the settings you made on the controller) and configures accordingly.
But the whole thing is much “heavier” than the MikroTik solution! The controller is a Java application that becomes larger all the time, I run it on a virtual machine with several GB of disk and main memory. That manufacturer originally supplied a small Raspberry Pi 1 like device that could run the controller, but over time it became more overburdened with it and it now no longer works, you need a new more powerful device (more memory, faster CPU).
The wireless APs also are much beefier than typical MikroTik units, with the associated price. MikroTik has clung to their 16MB flash while these APs had 256MB or 512MB flash for a long time. So lots more space for nifty data-conversion agents on both sides.
So no, I don’t think this is going to happen. Unless MikroTik makes that proposed “controller application” (which would be running on a powerful device) working at some time. See http://forum.mikrotik.com/t/mikrotik-devices-controller/158354/1
But I would not hold my breath…