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:

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

If any edge cases are missing in the table, let us know, and we will make the ULTIMATE guide for packages

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. 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.

If any edge cases are missing in the table, let us know, and we will make the ULTIMATE guide for packages

The unfortunate position of the RB4011iGS+5HacQ2HnD w.r.t. WiFi support could be clarified better.

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!!!!

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).

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

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.

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).

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 viewtopic.php?t=186352
But I would not hold my breath...

...
So there is no chance of the new version managing old devices. When that would have been practical, they could have done it already.
...
But I would not hold my breath...

They said that hap ac2 won't ever get WifiWave2, and there we have it, and it is working great. So maybe, just maybe, Mikrotik could give us another surprise and enable new Capsman on mipsbe devices, at least ones with enough memory (like mipsbe based wAP ac?).

Not holding my breath either

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

I checked the product page: https://mikrotik.com/product/rb4011igs_5hacq2hnd_in and the manuals there have no mention of this limitation. It would be fair to at least mention this on the product page.

It's a pity for all of us who bought this model as "powerful enough to be future-proof for at least a few years" and now it's declared obsolete

It's not obsolete at all.
It's your choice to use the wave2 package with its limitations or not.

The fact 2GHz radio is not usable anymore when you use wave2 drivers on RB4011 is already known for almost 2 years since 7.1 came out.

It would be great if you can help to split wifi-qcom-ac in 2 packages, only one IPQ4019 or QCA9984 driver ?

Due to hap ac2 has space limit while upgrade to this version with zerotier package space need another 117 kB more, log are said like that
This split may help to fixed this issue, as we can reduce size of package.
If it can solve space problem this must be great support.

Thank you very much

The fact 2GHz radio is not usable anymore when you use wave2 drivers on RB4011 is already known for almost 2 years since 7.1 came out.

It has been a problem for two years, yes. But there is no explanation why this problem even exists. In any other Linux system you can separately install drivers for each device without having such conflicts. When you have more than one driver that would support a certain chip, there would be a way to work around that by having the drivers detect their hardware in a certain sequence.
(so wifi-qcom would pickup the 5 GHz device and wireless would pickup the 2 GHz device, and find the 5 GHz device already supported by wifi-qcom so it would not bother with that)

I would have expected that now that you can have BOTH management menus available at the same time, you would be able to do this on a RB4011.

Let's not forget, ROS is, while based on it, not as flexible as Linux.

I think the base problem on RB4011 is effectively that there are 2 different chipsets used, one for each of the radio bands and somehow ROS is only able to use 1 driver: either legacy, either wave2. But not both.
However, that's pure speculation from my side.

It's a pity for all of us who bought this model as "powerful enough to be future-proof for at least a few years" and now it's declared obsolete

The device isn't obsolete, 2.4GHz Wifi is obsolete.

Certainly not !
2.4GHz spectrum is crowded (definitely !) but far from obsolete.

There are still appliances being brought to market today only having 2.4GHz capability.

Floppy disks are obsolete although I HAVE seen a setup some months ago where they still used 3.5" floppies ...nostalgic feelings !

I would have expected that now that you can have BOTH management menus available at the same time, you would be able to do this on a RB4011.

I assume their legacy wireless is not just a driver alone. possibly the legacy wireless has interaction with several system modules (routing/firewall) and makes it impossible to have new/legacy running same time.

The page shows that "New Capsman only controller" needs "routeros" only, while the video "https://www.youtube.com/watch?v=AkBIQxi-VKs" shows that "Package since 7.13" for "CAPsMAN for up to WiFi5 APs" is "routeos+wireless". Which one is correct?

Because you are quoting "new capsman ONLY", but video talks about old WiFi5 devices, which in the table is "running two capsmans at the same time" (old + new)

The page shows that "New Capsman only controller" needs "routeros" only, while the video "https://www.youtube.com/watch?v=AkBIQxi-VKs" shows that "Package since 7.13" for "CAPsMAN for up to WiFi5 APs" is "routeos+wireless". Which one is correct?

For using the old CAPsMAN, the (additional) wireless package is required.

The new CAPsMAN is part of the routeros package, this new CAPsMAN version can be used for managing the wifi-qcom (all ax devices) and wifi-qcom-ac (supported ac devices) packages.

Because you are quoting "new capsman ONLY", but video talks about old WiFi5 devices, which in the table is "running two capsmans at the same time" (old + new)

In other words, a switch like CRS326-24G-2S+IN that acts as new capsman only just needs routeos 7.13 without package "wifi". On the other hand, an AP like RBwAPG-5HacD2HnD that supports new wifi just needs routeos 7.13 with package "wifi-qcom-ac". Is it correct?

Correct.

Correct.

There seems something wrong. I set AP managed by CAPs but CAPs can't find AP's wifi interface. Any advice? Thanks.

Read the table again

Read the table again

Yes, I read it again. My AP runs with routreos + wifi-qcom-ac and is waiting for capsman's control. My switch acts as new capsman with routeros but cannot find AP's wifi interface. Because the table does not mention the switch device but wifi device only, I am not sure whether my switch needs wifi-qcom-ac or I neglect something else.
Any hint would be appreciated.

If they are on the same network, the CAP's should be able to find the CAPsMAN.
Have you seen this part:
https://help.mikrotik.com/docs/display/ ... ionexample:

It requires an edit on the default CAPs mode.

Or as an alternative, share the config of both CAPsMAN and CAP:
Remove serial and any other private information en post the output in between code tags by using the </> button.

If they are on the same network, the CAP's should be able to find the CAPsMAN.
Have you seen this part:
https://help.mikrotik.com/docs/display/ ... ionexample:

It requires an edit on the default CAPs mode.

Or as an alternative, share the config of both CAPsMAN and CAP:

Code: Select all

/export file=anynameyoulike

Remove serial and any other private information en post the output in between code tags by using the </> button.

Eventually new caps works. Now the way to putting AP under new CAPMAN's control is the following 3 steps on AP. No1. WiFi--WiFi--CAP-Enable; No2. Configuration--create New WiFi Configuration--Configuration--Manager--capsman; No3. Apply configuration to WiFi interface.

According to the table RB4011iGS+5HacQ2HnD should run dual capsman using `routeros+wireless` package. Here viewtopic.php?t=202640 people are struggling to have it running. Looks like CAPsMANs are conflicting each-other. Can we get a clear statement if it stable and possible at all for the particular product?
Any hint for a proper setup? it should not come to a hint game.

It's not obsolete at all.
It's your choice to use the wave2 package with its limitations or not.

If all other currently sold top-tier devices support it and one model support is dropped for "new" drivers and if you want the feature that all others have, you have to use "legacy" drivers that will lack new functionality, then it is fully qualified for this label.

The fact 2GHz radio is not usable anymore when you use wave2 drivers on RB4011 is already known for almost 2 years since 7.1 came out.

Then why it is not stated in the product specifications? There might be rational reasons for this decision, no doubt, but I would think twice about buying this model under such circumstances.

"It is already known" means "if you dig long and deep enough into this forum, you'll eventually find it". I kinda relied on the fact, that old RB devices did not lose that much functionality when you want to use new features. Until now, I suppose Never mind, there is no point in complaining here. It's just a highly disappointing experience.

RB4011 comes with wireless functionality enabled out of the box. You can simply use it as it is. But Changing package to another one is optional and at your own risk. It is in the documentation that RB4011 is not compatible https://help.mikrotik.com/docs/display/ ... patibility

It is mentioned deep down in the documentation, but NOT on the product specification sheet, where this of course belongs.
Just like there is: Note: Passive DAC (MikroTik S+DA0001/S+DA0003) are not supported. on the product page, there should also be: Note: the new WiFi drivers are not supported.
Even when you decide to keep using it as-is, updating past 7.12.1 causes issues.
Because you added another WiFi menu and moved menus around, winbox does not correctly save/restore window information anymore.
Please give us the option to upgrade software on RB4011 and keep everything as it is, including not introducing code for wireless devices that is not supported on this model.
(i.e. move WiFi menu into the qcom-ac packages, where it belongs)

Like I said, the product comes preinstalled with a working wireless package and there is no reason to change it to anotherone. If YOU decided to do this, it's in the manual, but it is not an advertised feature for this model. Does a BMW come with a specification note that engine from diesel to gasoline can't be changed?

Do you even READ what is written?
Again: when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.
This takes up space on the device (a real problem on e.g. the hAP ac2!!!) and also it causes winbox to fail saving sessions.
Reported before.
So to be clear again: this happens when NOT opting to install the new driver.

when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.

It's not unusable, it is required for managing ax devices via capsman.

Normis wrote that the new driver is not supported on the RB4011. So it is unusable.
When there is some specific use for it, move it into an optional package so those that need it can install that.
While those that do not need it can continue to use their device as it was sold.

Normis wrote that the new driver is not supported on the RB4011. So it is unusable.

Capsman for managing qcom-ac/qcom devices is possible even without installing any qcom-* package at all. So basically any ROS-device 7.13+ can be capsman for devices that are using new drivers.

So not unusable - but bloat for many users.

Do you even READ what is written?
Again: when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.
This takes up space on the device (a real problem on e.g. the hAP ac2!!!) and also it causes winbox to fail saving sessions.
Reported before.
So to be clear again: this happens when NOT opting to install the new driver.

Agree, maybe it's not so extra space but as useless WiFi section appearing, there is no need to display section for package that is not installed. Also in iOS mobile app wireless section is missing even when wireless package is installed (WiFi is there as useless section).

Well, on the hAP ac2 the extra space is a real issue, because despite being advertised as "16MB flash" in reality it has only 15.3MB flash, and the code for ARM is also bigger than for MIPSBE. So a hAP ac2 with 7.13 (with wireless package) is filled to the brim and fails once you configure a lot of features or maybe had it originally running v6 (so the v6 config is still on the device).
My hAP ac2 running 7.12.1 and configured only as a WiFi AP in bridge mode already has only 1MB of space left.
I don't understand why the base config code for WiFi is in the routeros package, while the wireless package again has its own base config code for the classic driver... the config code for the new drivers should be in qcom-ac* or in a wifi package, so that you will not install it when using the classic drivers.

the config code for the new drivers should be in qcom-ac* or in a wifi package, so that you will not install it when using the classic drivers.

The configuration and common parts should belong to a separate package called something like "qcom-common" or alike. So one can still install/have the capsman for qcom-ac/qcom on e.g. RB5009 - but without the wifi device drivers that would be completely useless on a RB5009. Would be even worse, when the config-code would be part of qcom-ac/qcom packages.

Again: when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.
This takes up space on the device (a real problem on e.g. the hAP ac2!!!)

WiFi menu is usable to manage CAPsMAN. You can ignore it, just like you can ignore BGP menu, SNMP menu and others.

And so the RB4011 issus is most problematic on hAP ac2 ?

Again: when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.
This takes up space on the device (a real problem on e.g. the hAP ac2!!!)

WiFi menu is usable to manage CAPsMAN. You can ignore it, just like you can ignore BGP menu, SNMP menu and others.

Unfortunately, no. I have a winbox session open to my devices all the time and I have saved the windows/tabs/columns I want to be open as a session.
With the new situation there are 2 different wireless windows and winbox confuses them (just like the user).
When I close winbox with the old-style wireless window open on the RB4011 or hAP ac2, and then re-open it again, it does open the new WIFi window instead of the old one, it opens the wrong tab as well (I normally have it on "registration").
Then when I close that window and re-open the original wireless window, all my saved column selections and widths are gone.

I do not consider that "you can just ignore it". It is a loss of function.

And so the RB4011 issus is most problematic on hAP ac2 ?

The hAP ac2 (which I also have) is most affected by the lack of storage, the RB4011 of course is not.
But the problem mentioned above occurs on both models!

Again: when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.
This takes up space on the device (a real problem on e.g. the hAP ac2!!!)

WiFi menu is usable to manage CAPsMAN. You can ignore it, just like you can ignore BGP menu, SNMP menu and others.

And so the RB4011 issus is most problematic on hAP ac2 ?

The whole idea behind, is that a number of customers want NOT to ignore it, but rather USE it managing both old CAPs and internal wifi and AX CAPs.
TLDR: it does not work. Please pay more attention in testing the solution i.e. "Dual capsman" or do not announce it, if it is not stable.
The "feature" is really nice for transition but please educate either publishing the HOW-TO or any documentation for proper setup since it is problematic.

What about 60GHZ product like Wap 60G?

If i upgrade to 7.13+ i see both Wifi and wireless, i takes more space on the device and it doesnt let me install our branding packages anymore due to space

as far as i can see, i cant uninstall the Wifi part, and if i uninstall the wireless part, it frees up space but i lose the W60 interfaces...

What is the sollution here?


for now the only thing i could do is downgrade with a lot of hassle to 7.12.1 and install the branding

after that, i cant upgrade to 7.13+ because space is an issue


FYI, my branding package is 893kB

What is the sollution here?

The solution is to stay at 7.12.1 and pray that MT will manage to get space problems under control.

Yes, I hope that MikroTik consider to promote 7.12.1 to "long-term" and apply possible security fixes in the future.
The 7.13+ versions have those issues and it looks like it is going to take time to iron them out, in the meantime "we" want to have a version we can keep running in production situations.

What is the sollution here?

The solution is to stay at 7.12.1 and pray that MT will manage to get space problems under control.

Jip, that is what im going to do as for now.
To bad they implement things not designed for the device it will run on. like wifiwave2 wifi menu on 60GHz devices..... i dont see the point in hat one


FYI, i have the same issue on hap ac2 devices.

The solution is to stay at 7.12.1 and pray that MT will manage to get space problems under control.

Jip, that is what im going to do as for now.
To bad they implement things not designed for the device it will run on. like wifiwave2 wifi menu on 60GHz devices..... i dont see the point in hat one

Right or wrong. Their logic is any device can an be a Wi-Fi controller, even if it does not have 802.11 hardware.

One option is you can use webfig to create a skin to remove the Wi-Fi menu and assign the skin to your user account. Skins also apply to winbox too, even though you have to create/edit them in webfig.

+1 For a long term stable Vers 7.12.1 variant!

+1 For a long term stable Vers 7.12.1 variant!

+1

Mentioned long term in release topic viewtopic.php?t=202423#p1042578 but no response... Maybe it should be replied to this viewtopic.php?t=201378#p1035120

Do you even READ what is written?
Again: when an RB4011 (or any device) is upgraded from 7.12.1 to 7.13, an unusable WiFi menu is added.
This takes up space on the device (a real problem on e.g. the hAP ac2!!!) and also it causes winbox to fail saving sessions.
Reported before.
So to be clear again: this happens when NOT opting to install the new driver.

Agree, maybe it's not so extra space but as useless WiFi section appearing, there is no need to display section for package that is not installed. Also in iOS mobile app wireless section is missing even when wireless package is installed (WiFi is there as useless section).

Same here with missing wireless tab in the mobile app, I have both CAPsMAN versions running on the RB750Gr3, but only wifi is visible in the mobile app, also old CAPsMAN devices are missing from the interfaces. Any clue?

only wifi is visible in the mobile app, also old CAPsMAN devices are missing from the interfaces. Any clue?

There have been complaints about the iOS mobile app in another thread, see...
viewtopic.php?t=203149

On top of top wlanX not showing up in the Advanced menus. Even without CAPsMAN running, it does NOT let you set the wireless SSID or password from the Home Screen, which is the end-user way of changing them using the app.

In the end I don't understand this package-approach at all.

Just build a main-package for each ARM device!

So we don't have to mess around with wifi packages and confuse users.

Device: D53G-5HacD2HnD
- Main package with Legacy Wireless
- Main package with Qcom drivers

No package manager overhead. No other overhead. No confusion. Easy to switch between "editions". Just drop the according NPK and reboot. done. No need to mess around with wireless package and - do I need wifi-wcom-ac or do I need wifi-qcom? And where is all my free space gone????

Yes, a bit more RAM usage for larger npk (Qcom ax+ac), but it I think all devices should be able to handle that, it will be more cleaner process for upgrade. Upgrade process should be able to detect which drivers you need for device and install them.

So we don't have to mess around with wifi packages and confuse users.

If you just follow /system/package/upgrade... theoretically, all should work fine & if not, it's a bug IMO. It's only when you want to use the "new drivers" on an old device that take messing with packages. But foisting the wifi-qcom-ac drivers would be a bad idea in same cases since not all features map perfectly... so could break an upgrade in some case (beyond just disk space).

But packages are avoidable. And the issue is disk space. Most folks don't need TR069, calea, etc... but some do. And monolithic package with all features possible won't fit in 16MB flash devices... So issue comes up say you TR069 to setup a zerotier-enabled IoT gateway but don't need BGP/OSPF & other wacky combo since Mikrotik are used in a lot application outside someone home.

Suggestion is to have 2 packages, Legacy and Qcom, not forcing new Qcom drivers. Qcom bundle can contain ax+ac drivers and upgrade process can install drivers only needed for device, device will not have both ax and ac drivers on flash storage if upgrade process is a bit "smarter".

Personally, all care about is the packages I used before still fit. The "how" is kinda less important – but moving to "more monolithic" doesn't seem like the right direction, but maybe.

One benefit with the wireless/qcom being seperate in 7.13+, is it allows wi-fi to be remove if it's not needed in an install...

Now... still think it's just lousy UX using files to manage packages... when the extra-package are well-known & there are multiple GUIs to configure RouterOS for some "checkbox" for features(/packages).

The recent MT newsletter suggests there still releasing 16MB flash units – which is "good news" IMO since there committing to managing in 16MB.

Problem is that npk install script is dumb copy all files process from package to ROS fs location, when having all Qcom drivers in single package it will need to first check device peripherals and copy only needed driver files (it will be the same at the end like installing ac or ax separately), in this case user will not be bothered to check if he needs ax or ac drivers, even it is not so complicated but for some it seems it is.

is dumb

If I worked at MikroTik as a programmer the problem would have already been solved, in fact, it probably would never have been created,
because I would have done everything in a more logical way:
you only download the drivers (and optional features) you need based on the model, without downloading and installing too many things.

If I had been the hardware manager then I would have put 1GiB chips everywhere, rather than continuing to use chips from paleolithic.

I'm sorry to all of you, but I am neither one of their programmers, nor their hardware manager.

The problem is that MT (especially Normis position on that) declines "more granular" package splits so we can reduce flash-usage as much as possible.

Every few days a new forum topic is created where a confused user is puzzled by 7.13. It is very unclear for the regular user to understand this "split" and the difference between "wireless" and "wifi". Not mentioning the topics recently about the free flash space and users cant fit zerotier package anymore and so on.

So what I proposed:

Keep running systems untouched. The default "MAIN PACKAGE" should have remained the same as it was until 7.12. A MAIN PACKAGE with LEGACY WIRELESS. Continuing to work as before. Same flash size usage. Same ALL.

Then introduce a "per device" built "MAIN PACKAGE". So everyone who wants wave2 is now able to OPT-IN and use the "device specific" MAIN PACKAGE instead. It would contain the new QCOM drives for the specific device and necessary other stuff. Not more, not less. I am pretty sure this approach would result in a very tight/optimized MAIN PACKAGE and we could regain a notable amount of space on all the ARM 16MB platforms.

@infabo
We have no guarantee that the staff who PROGRAM RouterOS will ignore our comments.
Probably our reports and proposals on the forum are not even passed on to the programmers,
just because those of the staff who read the forum do not consider them worthy of note.

Like this:
viewtopic.php?t=198641#p1022672
On 7.13.3 still exist that line...

   

Update 9 in viewtopic.php?p=1054314#p1054314

This raises questions of business continuity.
Moving from /interface/wireless ("wireless") to /interface/wifi ("wifi-qcom" and "wifi-qcom-ac") may cause service interrruption.

If you have a mixed bag of devices, some 802.11ac other 802.11ax, then you need wifi-qcom on the CAPsMAN, wifi-qcom on the 802.11ax CAPs and wifi-qcom-ac on the 802.11ac CAPs. Since CAPsMAN does not manage packages in CAPs, you have to do it yourself.

Assuming your devices have "wireless" installed, what happens if you install "wifi-qcom"?
We already know that "wireless" will be automatically disabled.
Are the /interface/wireless settings automatically ported to /interface/wifi to prevent service interruption?

Users would have preferred to have everything in "wireless".

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:

split2.jpg

Can you split base package even more? Please make VPN functionality as separate optional package. Media/DLNA separated package. Possibly even more so we can install it without problem on hAP ac2 without problem with disk size. Thank you.

Well, on the hAP ac2 the extra space is a real issue, because despite being advertised as "16MB flash" in reality it has only 15.3MB flash, and the code for ARM is also bigger than for MIPSBE. So a hAP ac2 with 7.13 (with wireless package) is filled to the brim and fails once you configure a lot of features or maybe had it originally running v6 (so the v6 config is still on the device).

Yup, same "space" issue here.
I was running 7.13 (routeros+wireless package) and barely had enough room to create a backup (running config) file to the flash drive.
RouterOS + wireless package and 1 backup-ed config file left me with 1% free space (14.9MB of 15.3MB used).

I was hoping 7.14 would have a little more space left, but it turns out that upgrading to 7.14 bricked my hAP ac2's altogether.
After many failed tries with Netinstall (confirmed bug), I finally managed to get 7.13 back on both devices.
See:
viewtopic.php?t=205614

Mikrotik support suggests upgrading to 7.14.1, but those packages are exactly the same size as 7.14. So I don't think this will solve the space issue.

So basically, installing the wifi-qcom-ac package on the hAP ac2 isn't even an option, because it's even bigger than the older wireless package.
wireless: 2.64 MB
wifi-qcom-ac: 2.85 MB
Which leaves no room for a config backup file.

I was running 7.13 (routeros+wireless package) and barely had enough room to create a backup (running config) file to the flash drive.

Well, you are not supposed to create a backup to the flash drive!
In those 16MB devices the Files section points to a RAM disk and flash is a subdirectory of that (where space on flash is mounted).
You should make your backup in the root directory and then download the file to another device.
That is required anyway to be able to recover it when the device crashes.
(make both a /system/backup/save and a /export show-sensitive)

Well, you are not supposed to create a backup to the flash drive!
In those 16MB devices the Files section points to a RAM disk and flash is a subdirectory of that (where space on flash is mounted).
You should make your backup in the root directory and then download the file to another device.

Not sure what you mean by this.

I always log into my routers with Winbox, then go to Files and hit the "Backup" option.
I enter the filename and voila... the config backup file is created.
I then download the file to my local machine from within the same Files menu

So if this is not the way to create a backup, why is this option there?

And regardless of where I store this file, it will take up space from the 16MB.
Whether it's on the RAM disk, or in a sub-directory (flash) on the same disk.
Or am I missing something here?