7.13 wireless package split question

+1 For a long term stable Vers 7.12.1 variant!

+1

Mentioned long term in release topic http://forum.mikrotik.com/t/v7-13-5-stable-is-released/171923/1 but no response… Maybe it should be replied to this http://forum.mikrotik.com/t/os-7-long-term/171049/1

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?

There have been complaints about the iOS mobile app in another thread, see…
http://forum.mikrotik.com/t/wireless-info-does-not-show-in-the-ios-app/172534/1

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.

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

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:
http://forum.mikrotik.com/t/v7-11-2-stable-is-released/168778/1
On 7.13.3 still exist that line…

Update 9 in http://forum.mikrotik.com/t/the-abc-of-capsman-v2-with-updates/173423/1

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

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.

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:

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.

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)

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?

Sorry I’m very new forgive me if this chart explains it, but if i go to the suppot & downloads page under the model to me which seems very generalized to mikrotik software and not the device i’m using. How do I know that my device can use the latest software? Do i need to download both the routeros-7.15.1-mipsbe.npk and the wireless-7.15.1-mipsbe.npk, and then also i seen certain device have a boot that needs to be updated too..does that need to be updated everytime a new software is released? Also what are the steps i need to take to backup everything to prepare for the software upgrade, seem that the backup option is just for the configuration and nothing eles? Im surprised that someone hasn’t made a sticky about the backup process for beginers already!