Yes, having pondered on this - stability is #1 priority; can’t have people not been able to pay their bar bill! So I’ll send the USB modem back and seek one that works with v6.
Another idle question - what was the drive for v7? I get the impression that they’ve started again from ground zero if they are adding features back in? Was this to get a cleaner code base? As a one-time programmer, I can relate to that. Or was it to add some new super functionality? As RouterOS v6 seems to do more than I’ll ever want, I’d be interested if there is a must-have feature in v7.
Shift from an heavy customized kernel 3.3.5 to a new heavy customized kernel 5.6.3 (since 7.0beta7. The first beta was on 4.14.131).
The old kernel just can’t keep the new features/chipset… Look at wireguard for example.
Hopefully less heavy customized kernel. As the rumours go, wireless drivers in v6 were all in-house development. Seems like MT is going to use stock (wireless chip vendors’) drivers at least for wave2-capable wireless cards. But there are features (I’ve heard some advanced routing etc.) which rely on now-defunct part of kernel API and these have to be rewritten to use current kernel API.
Another huge thing seems to be the fact that stock kernels dropped support for Tilera platform a while ago. MT is eager to continue support for it (required for keeping CCR1xxx line alive) and I guess they’ll have to port kernel of choice to Tilera themselves …
Nicely stated charming Mudman, r00t should go back into the earth and hide (where roots belong) for being whiny and bringing a false argument to the table.
Ouch you hurt my CCRs feelings, but more importantly I can see how that added a whole layer of extra work for them to keep keep an additional fork up to date.
I don’t get the sense that most of the work and long delays in getting v7 ready don’t necessarily have as much to do with the kernel customizations, and have more to do with the rewrite of the routing engine. In ROS 6 and earlier, it seems like MikroTik had bet the bank on the route caching feature in the Linux kernel. They put route caching at the core of the entire routing engine and designed the routing protocols in such a way that the router would not even work without route caching. If you try turning off route caching in ROS 6 today, a lot of different things no longer work as expected. This dependency on the route caching feature wound up being a mistake in hindsight as route caching was removed in Linux kernel 3.6. This prevented upgrades to a newer Linux kernel until they rewrote the entire routing engine and redesigned and rewrote all routing protocols from scratch. This could not be done overnight, and the result was talk of a future v7 for years like it was a mythical unicorn.
If the older routing protocols and engine were not designed around route caching, we probably would be on a much more modern kernel already.
(Mind you, I don’t think they have ever out and out given this explanation, but the fact that ROS6 is basically running on the final kernel version that had route caching in place before it was removed, combined with the generally bad things that seem to happen if you try to disable route caching in ROS 6, strongly implies that this is the main reason we never had kernel updates in ROS 6.)
Why did they do this?
Route caching was originally supposed to be this great feature that would speed up routing table lookups drastically and make Linux a much more efficient router - that is why it was added into Linux in the first place. This relates to other similar technologies like Cisco’s CEF (Cisco Express Forwarding), and so it probably seemed like a great idea at the time, since route caching would be like MikroTik’s answer to Cisco CEF. However, studies done years afterwards showed that route caching did not actually measurably improve the efficiency of Linux as a router in real world scenarios, and created potential pitfalls if the route cache had incorrect/stale data and created an attack vector.
They should take one routing protocol at a time. Ospfv3 works in a particular release and gets broken in the next. Multiple revision in route filters got it not working since last two betas.
TL;DR: it is stable for simpler applications but not for mission-critical applications, it will take a while to get a stable-stable
IMHO to see what v7 is you need to look at the history
Looking at what they’re doing v7 is a huge leap forward internally but only some small bits are visible outside. I don’t know how old exactly ROS is (wiki says 1996?) but I distinctly remember ROS being shown to me when we were still hanging ethernet cables between apartment buildings attached to a metal wire using zip ties. That was the best ISP in the area with a blazing-fast 64kb/s connection. The point is ROS came a long way and I’m 100% sure, based on my experience in software development, it is chock-full of legacy code and many hacks.
The v7 line is most likely full of shims and adapters between old and new code. It works. As any legacy project however you cannot make it production-stable quickly. It may appear stable but as we all see in this forum it is not. While the features in v7 are nice and we asked for them for a long time, I wouldn’t call v7 development slow. While the public changelogs for v7 aren’t very long, I’m sure under the hood there’re plenty of things like “fixed communication between [internalModuleA] and [internalModuleB]” which we aren’t interested in. In one of the projects I worked for where we were faced with a similar problem (migrating a huge, multi-million lines, project into the 21-st century) changelogs with 1-2 lines with sometimes enigmatic “fixed processing of large unicode files” were internally attached to a collection of tickets with 50k+ LOC changed.
That being said some of the things which were added to v7 makes me think that ROS v7 is more a rebirth than a simple patch-around for couple of reasons:
1. Kernel updates
Recently they were able to bring the kernel to the most recent one quickly again (just in between betas). This means they’ve got a robust process to do so. This is huge. ROS got into the current state partially because of the outdated kernel version it was running.
2. 3rd tools integration
Everybody who’s in the MT world long enough knows the famous amazing OpenVPN implementation. OVPN is a very messy protocol with a very… convoluted… codebase (being polite). For years MT struggled (for whatever reason) to add e.g. OVPN-UDP. This was because they decided to roll their own OVPN daemon… they did the same with a lot of things (e.g. 802.11 stack).
With WireGuard they just… added it. They just integrated the mainstream library into the ROS.
3. Internal mindset shift?
Sort-of related to 2. - it seems to me like MT internally changed how they do things. They are willing to integrate things into the ecosystem instead of rewriting it. You can see it with WireGuard, Cake, FQ_Codel, and most notably wifiwave2. The last one is especially huge: they’re including binaries of drivers and wrapping them in their own layer. For now it’s immature but if corporate culture taught me anything this is a huge shift internally in the development policies and practices.
Thank you for comming to my TED talk 
The discussion in this thread is very interesting and informative. But I just want to add my “+1” to those interested in feature freeze and bug squashing as soon as practical.
CCRs are currently struggling with a full BGP table. Routes take forever to reach the forwarding plane. The very old and fondly remembered Cisco 7200s are much faster updating their tables and their design is 20 years old.
Also, a lot of stuff is configured differently on v7 so there will be a lot of time needed to get familiar and test everything, to add to the release date. So unless Mikrotik wants to drop out of BGP speakers, we need a v7 BGP speaker getting stable ASAP.
Thanks for that kiler129 - sounds all very logical to me.
Yes, that is a result of their previous business decisions.
You’ve picked up one of the most painful parts, but it should be ready before you start releasing products on it.
How the WG comes here? It is part of the kernel. They have to provide a configuration interface for it.
Probably. Nobody knows because they don’t say whether they want to leave the things and mindsets they inherited.
But anyway, you gave some light how big this work is, but it doesn’t justify the process how it is communicated. You’d be sure about they have plans, but they are not communicating them, which is a problem.
(BTW, better if you know more about the company history, also if you compare your writing to a TED talk, I’d suggest be more open to other points of view and integrate them even in a debating way)
Communication - often a problem and downfall of many companies. I love RouterOS and Miktotik kit but their product range sometimes confuses me. Like supporting Wi-Fi 5 (AC) but only having 100Mbps ethernet ports.
And Ubiquiti, for exalmple, has AirFiber 60-LR with 2Gbp/s link but only 1Gbp/s Copper ethernet…
I can kind of accept that one as it gives a lot of wiggle room of 2Gbps over the air but backbone of 1Gbps. How many people have the luxury of a 1Gbps internet connection 
But Wi-Fi 5 is now pretty much the base standard.
Radio link is simplex,
cable link is duplex,
2Gbp/s simplex = 1Gbp/s duplex
Oh, yes…
Are the radio links of all AirOS devices Simplex?