I've bought a Huawei e3372h-320 USB LTE modem which doesn't work with v6.48.2 - known problem reported several times on here. Solutions are a) send it back, b) switch it to stick mode and c) use RouterOS v7. It indeed works fine with RouterOS v7 and at first glance, everything I need it to do seems to work. Switching to stick mode feels like a step backwards.

Couple of questions on v7 - when is the planned launch date of the non-beta version and would I be mad to consider installing it in production?

It will be used at a wedding venue where they want a failover for their payment card readers - they are going cash-only when they are allowed to re-open in the UK. Their leased line connection is very reliable but it would be even worse if the router failed so they couldn't take payments.

Ohh there is a (d) - use some rather sketchy looking alternative firmware for the E3372h. I love a challenge but this really does need to work :-)

Very wrong question...

The 7.12 long-term are expected on 2041:
viewtopic.php?f=2&t=149907&p=856818&hil ... rm#p856818

2041!!!

2041!!!

I'ts a joke that "is'a a joke"

Couple of questions on v7 - when is the planned launch date of the non-beta version and would I be mad to consider installing it in production?

Forget. It's still alpha quality, even not beta. However, it works quite stable for some basic things. But advanced RouterOS features do not work at all.

Yes sadly RouterOS progress is painfully slow and Mikrotik is becoming a joke.

I love the hardware but if they will not get the focus and start with clear RouterOS roadmap we will have to change the vendor.

I want "Ubiquiti" processors with "Cambium" radios, "RF Elements" antennas and MikroTik RouterOS.

Cambium and Ubiquiti software for me su...

RouterOS is perennial beta, but if are accepted as-is, work.

Rather a depressing series of posts. My background has never really been on the network side although I was quite adept at Juniper firewalls. So I've never got seriously involved in high-end Cisco kit leaving that to my network specialist. Is Cisco or anyone else as programmable as RouterOS? I know most of the Ubiquiti kit I've used isn't anything special configuration wise.

If RouterOS did fade away, I think the world would have lost a bit of a shining star. But then again, not the first time the "best" hasn't won in the long run :-(

If RouterOS did fade away, I think the world would have lost a bit of a shining star. But then again, not the first time the "best" hasn't won in the long run :-(

I wouldn't be too worried about that. I have a fairly complex setup at home and aside from a few things RouterOS v7 is stable enough for me at home - it only recently became stable enough with the beta5 release. Previously I would try to run it and I would get spontaneous reboots every day or sometimes more often. I think we are likely to see a first "stable" release early next year, at the rate things have been going. There isn't actually that much more they have to do - the biggest missing piece was MPLS which was added in the latest beta. Now they just have to tackle the remaining bugs or features not fully implemented.

That said, like the others, I would not suggest using v7beta in any mission critical situation. So for your particular use case, I would recommend playing it safe and using RouterOS v6 if you can.

It's been 2 months since last v7 beta... if anything, development is slowing down... sad to see this.

It's been 2 months since last v7 beta... if anything, development is slowing down... sad to see this.

Look at the time between the previous betas:

7.1beta1->7.1beta2: 1 month
7.1beta2->7.1beta3: over 3 months
7.1beta3->7.1beta4: 2 months
7.1beta4->7.1beta5: 1.5 months

As of this post, it has been less than two months since the 7.1beta5 release. The time between betas has been fluctuating, no evidence that development has been slowing down. The important thing is what features they have been adding in the new betas in that amount of time, which is actually quite a bit.

If RouterOS did fade away, I think the world would have lost a bit of a shining star. But then again, not the first time the "best" hasn't won in the long run :-(

I wouldn't be too worried about that. I have a fairly complex setup at home and aside from a few things RouterOS v7 is stable enough for me at home - it only recently became stable enough with the beta5 release. Previously I would try to run it and I would get spontaneous reboots every day or sometimes more often. I think we are likely to see a first "stable" release early next year, at the rate things have been going. There isn't actually that much more they have to do - the biggest missing piece was MPLS which was added in the latest beta. Now they just have to tackle the remaining bugs or features not fully implemented.

That said, like the others, I would not suggest using v7beta in any mission critical situation. So for your particular use case, I would recommend playing it safe and using RouterOS v6 if you can.

More features are missing like IGMP-proxy

More features are missing like IGMP-proxy

Which is not something I would consider a major feature. At the moment they mostly have to finish filling in the blanks - all of the minor features, or fixing bugs with the major features.

More features are missing like IGMP-proxy

Which is not something I would consider a major feature. At the moment they mostly have to finish filling in the blanks - all of the minor features, or fixing bugs with the major features.

Well, for people like me who need this to be able to use the router to watch tv over a fiber connnection ( using a separate vlan ) it is a real showstopper.

There are two things that are not great with ROSv7:

1. stability and functionality which is already available in v6. This is the important one and should definitely be worked on first to roll out v7 (sort of a stable release). It will form a good base for further development which was increasingly troublesome in v6 due to it's aged base
2. new features (such as IGMP proxy or wave2 wifi) which are important to some users and should be developed eventually. However new features are not IMHO as important as things mentioned in previous bullet.

I certainly hope MT devs are focusing on bullet #1 because any new features without stable base are completely useless to most users.

I certainly hope MT devs are focusing on bullet #1 because any new features without stable base are completely useless to most users.

Yes, this is the same thing that I was pointing out to others. Everybody was asking for new features right away like ipsec VTI and other such things. I do want to see new features, and appreciate the new features like wireguard and VXLAN but the sooner that ROS v7 stabilizes the sooner that we can all benefit from the new kernel.

I do think MikroTik is focusing on #1 but there is a vocal minority of users who seem to want MikroTik to instead be focusing on adding every new kitchen sink feature before the first stable release.

I certainly hope MT devs are focusing on bullet #1 because any new features without stable base are completely useless to most users.

Yes, this is the same thing that I was pointing out to others. Everybody was asking for new features right away like ipsec VTI and other such things. I do want to see new features, and appreciate the new features like wireguard and VXLAN but the sooner that ROS v7 stabilizes the sooner that we can all benefit from the new kernel.

I do think MikroTik is focusing on #1 but there is a vocal minority of users who seem to want MikroTik to instead be focusing on adding every new kitchen sink feature before the first stable release.

I can agree with this regarding new features, but IGMP-proxy is a feature that allready was in ROS, maybe not a core function so the focus should be on core functionality and stability and then on already existing features and only then on totally new stuff.

I can agree with this regarding new features, but IGMP-proxy is a feature that allready was in ROS, maybe not a core function so the focus should be on core functionality and stability and then on already existing features and only then on totally new stuff.

I can't see igmp-proxy taking anywhere near as long as MPLS to implement on ROS 7. I strongly suspect, aside from fixing bugs in MPLS/OSPF/BGP, that those are the sorts of features that are likely to be tackled next.

Ohh there is a (d) - use some rather sketchy looking alternative firmware for the E3372h. I love a challenge but this really does need to work :-)

Have a look at my recent post about getting LTE failover working in a Chateau. You could adapt it for your LTE module. Recursive routing doesn't work like the Olden Days in ROS7, yet. I needed it to be robust so that it works reliably at a hotel and the staff don't get a in flap when the WAN goes down and they can still do email and bookings and VoIP calls over LTE.

That said, like the others, I would not suggest using v7beta in any mission critical situation. So for your particular use case, I would recommend playing it safe and using RouterOS v6 if you can.

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.

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?

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.

Shift from an heavy customized kernel 3.3.5 to a new heavy customized kernel 5.6.3

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

It's been 2 months since last v7 beta... if anything, development is slowing down... sad to see this.

Look at the time between the previous betas:

7.1beta1->7.1beta2: 1 month
7.1beta2->7.1beta3: over 3 months
7.1beta3->7.1beta4: 2 months
7.1beta4->7.1beta5: 1.5 months

As of this post, it has been less than two months since the 7.1beta5 release. The time between betas has been fluctuating, no evidence that development has been slowing down. The important thing is what features they have been adding in the new betas in that amount of time, which is actually quite a bit.

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.

Shift from an heavy customized kernel 3.3.5 to a new heavy customized kernel 5.6.3

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

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

If the older routing protocols and engine were not designed around route caching, we probably would be on a much more modern kernel already.

Why did they do this?

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.

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.

Yes, that is a result of their previous business decisions.

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.

You've picked up one of the most painful parts, but it should be ready before you start releasing products on it.

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.

How the WG comes here? It is part of the kernel. They have to provide a configuration interface for it.

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.

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.

And Ubiquiti, for exalmple, has AirFiber 60-LR with 2Gbp/s link but only 1Gbp/s Copper ethernet...

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?

My 2 cents ;)
If it is true that v7 should not be used in production, why then do have a chateau that cannot be downgraded to v6?

My 2 cents ;)
If it is true that v7 should not be used in production, why then do have a chateau that cannot be downgraded to v6?

Chateau cannot run on RouterOS v6. It is shipped with v7.0.X (stable), which is different than 7.1betaX (development). Historically, RouterOS is released per platform (x86, arm, mips, tile, etc.). Unfortunately, there is no stable per-platform ROS v7 available yet. So the decision has been made to stabilize per-device v7 firmware. RouterOS v7.0.X has the same release procedure as the current stable v6 (6.48.X), but it is limited to specific devices only. Some "v7 beta features" like routing filters have "sneaked" into the release, but that's a different story. By the way, some other vendors do per-device firmware since day one.

Regarding v7.1beta, I think the appearance of "beta" in the name is confusing. There are two different release channels: Testing (currently, v6.49) and Development (v7.1), both having "beta" in the name. However, the Testing channel is way more stable than the Development. The term "beta" from traditional software engineering fits more to the Testing channel. If we had renamed releases in the Development channel to v7.1dev6, it would cause less confusion.

One step forward in learning, one step back - what is Chateau???

Are the radio links of all AirOS devices Simplex?

Now I'm on office and check this...

1Gbps full duplex, radio-link 2Gbps half duplex

Chateau cannot run on RouterOS v6. It is shipped with v7.0.X (stable), which is different than 7.1betaX (development). Historically, RouterOS is released per platform (x86, arm, mips, tile, etc.). Unfortunately, there is no stable per-platform ROS v7 available yet. So the decision has been made to stabilize per-device v7 firmware. RouterOS v7.0.X has the same release procedure as the current stable v6 (6.48.X), but it is limited to specific devices only. Some "v7 beta features" like routing filters have "sneaked" into the release, but that's a different story. By the way, some other vendors do per-device firmware since day one.

It's very interesting. Where to download stable 7.0.x version for Chateau? If it is stable, does it mean SUP-37062 issue is not exists in this version?

If we had renamed releases in the Development channel to v7.1dev6, it would cause less confusion.

A very welcome decision.

Chateau cannot run on RouterOS v6. It is shipped with v7.0.X (stable), which is different than 7.1betaX (development). Historically, RouterOS is released per platform

Sorry, but what are the properties that define a "stable" state? Also, I need to correct your statement, it arrived with v7.0beta6 firmware. I mean, it was fantastic to be a doorstop, but I expect a bit more from a new device with Mikrotik name.

Regarding v7.1beta, I think the appearance of "beta" in the name is confusing. There are two different release channels: Testing (currently, v6.49) and Development (v7.1), both having "beta" in the name. However, the Testing channel is way more stable than the Development. The term "beta" from traditional software engineering fits more to the Testing channel. If we had renamed releases in the Development channel to v7.1dev6, it would cause less confusion.

What does it mean? You mentioned above 7.0beta6 was stable, it means (for me), it implements all expected features and stable enough to have minimal support request. But even the whole thing far from the "beta" status, I don't even call 7.0beta6 as "beta". Furthermore, 7.1beta6 seems to be an alpha release which doesn't even have over the planning phase. So, back to the question, if you rename 7.1beta6 7.1dev6, does it change the fact you released a device without working essential functions and one year after the release you name the initial firmware "stable"?

My 2 cents ;)
If it is true that v7 should not be used in production, why then do have a chateau that cannot be downgraded to v6?

Chateau cannot run on RouterOS v6. It is shipped with v7.0.X (stable), which is different than 7.1betaX (development). Historically, RouterOS is released per platform (x86, arm, mips, tile, etc.). Unfortunately, there is no stable per-platform ROS v7 available yet. So the decision has been made to stabilize per-device v7 firmware. RouterOS v7.0.X has the same release procedure as the current stable v6 (6.48.X), but it is limited to specific devices only. Some "v7 beta features" like routing filters have "sneaked" into the release, but that's a different story. By the way, some other vendors do per-device firmware since day one.

Regarding v7.1beta, I think the appearance of "beta" in the name is confusing. There are two different release channels: Testing (currently, v6.49) and Development (v7.1), both having "beta" in the name. However, the Testing channel is way more stable than the Development. The term "beta" from traditional software engineering fits more to the Testing channel. If we had renamed releases in the Development channel to v7.1dev6, it would cause less confusion.

Thanks for that, where can I find V7.0 for the chateau to reflash?

When can I get the v7.0.x stable for the chateau? the 3 I just received didn't have a stable but a beta :S

The big issue with mikrotik is that they know that they break many features in each release. I they simply mention what's notworking and known to them it would be of great help.

If we know something is not working, it is written in the changelog as a warning. We don't intentionally break anyone's devices by hiding stuff like that

If we know something is not working, it is written in the changelog as a warning. We don't intentionally break anyone's devices by hiding stuff like that

Why did you bring this up? I do not believe we have an idiot here who thinks you work against yourselves, our problem mainly:
- you have a product without stable firmware
- there are multiple problems with the actual version, but these are understandable on a development path, but without knowing where are we at in the development or more like when do you plan to consider the actual status feature complete a bit problematic.
- for above reasons, nobody knows when it is worth to try a new version if the person not intended to test only want to use the device

I believe a simple statement about when do you expect the 7.x milestones in your actual view could normalize this situation, it also can be changeable, but it would give information for your customers how you think about 7.x actual state and when do you expect to release as GA. /of course, it is only my opinion/

I am replying to the poster above, who said, we are hiding known issues intentionally

And Ubiquiti, for exalmple, has AirFiber 60-LR with 2Gbp/s link but only 1Gbp/s Copper ethernet...

This is actually a good thing for the most part. You ideally want your air transmission rate to be higher than your actual ethernet throughput rate to allow for a more consistent experience when the conditions worsen and to cater for things like silent re-transmission
That data rate is never attainable in the first place (always some loss) however if you have to retransmit ~10% of your frames you can do so very quickly and seamlessly. That way a ~1gbit/s transfer doesn't even notice that retransmissions have occured, it continues on nicely at the full speed as it can retransmit and 'catch up' before the frame buffer empties
However if you implement a 2.5gbit/s chip and lets say you did get 2gbit/s of throughput. Periodic retransmission would see your speed briefly dip and your latency increase

You could always artificially reduce the speed to achieve the same result, however the simple reality is 2.5gbit/s adds quite a bit to the cost at the manufacturing layer, which is passed on to the consumer at a much higher price. It just isn't worth it if you are buying 200x of them and can only really use a small boost in speed ~10% of the time at a significant price premium

This thread should be closed. It does not longer discuss "v7 launch date"
MT never have a fixed "launch date". It will be released when they think it stable enough, sometime in future.

This thread should be closed. It does not longer discuss "v7 launch date"
MT never have a fixed "launch date". It will be released when they think it stable enough, sometime in future.

Don't quite understand, a few people are offing this topic (like you), but 2 days ago, MT officially announced 7.0.x as stable, you don't even follow the topic, but you want to close it. What is your real problem?

Did you get a date?

PS no need to quote the whole post above you,

but 2 days ago, MT officially announced 7.0.x as stable, you don't even follow the topic, but you want to close it. What is your real problem?

Version 7.0.x as stable only for the Chateau not for any other device in the MikroTik portfolio .... plus this was not an OFFICAL release statement JUST a FYI.

IMO, its still a long way to go for all other models that may be capable of running v7.... I suspect it will be stable for all other CAPABLE devices end of this year or spring of 2022.

IMO, its still a long way to go for all other models that may be capable of running v7.... I suspect it will be stable for all other CAPABLE devices end of this year or spring of 2022.

I do wonder how much heavy lifting remains to be done on V7, and how much left is just cosmetic/config interface... They sure are working hard on it - every changelog shows work done at a very low level, and this is both hard and slow going.

Too bad we don't have a chart with milestones, or something like this, so we could have a better idea...

MikroTik want work without milestone.
Why must be obliged to work like some others expect?

The things are ready when done. Stop.
Too much pressure do not give anything good.
If that delude your aspectation, simply do not have one.

If we know something is not working, it is written in the changelog as a warning. We don't intentionally break anyone's devices by hiding stuff like that

You got me wrong. I guess you guys tested filter before releasing 7.1beta 5 no where it was mentioned that filters are not working. After opening support ticket I was informed that filters were not working and it was known by support. It would be fixed in next release. So why was it not mentioned in the changelog.

Because someone open ticket and just make notice of this, and after that staff know it and act for solve the problem.

Let's clarify rumors.

MikroTik

1. A forum post of a MikroTik staff member should NOT be considered an official announcement unless it is an original post in the Announcements.
2. MikroTik is quite a big company, so even its employees may not see the full picture. For instance, I specialize in switching&routing, but I have no idea what's going in the Wireless area.
3. From time to time, I'm revealing some non-classified insider information to keep users up to date with the recent development process. I think it is fair to provide more information to forum users due to their higher interest in MikroTik products, especially beta testers. However, I'm not obligated to do that. It is my free will, and the more I see "few-word quotes cut out of the context", the less I want to continue.

Chateau

1. At the moment of writing, the latest stable RouterOS release for Chateau is v7.0.3, and this firmware is considered stable for Chateau-only!
2. There is no stable v7 firmware for other devices yet. Theoretically, nobody prevents users from installing v7.0.3 on other MikroTik devices, such as CRS317, but then forget about stability.
3. "Stable" does not mean "bug-free". Sad but true. "Stable" means the quality of the firmware is good enough to be used in a production environment.
4. 7.0beta6 is, as you may guess, beta. It does not match the "7.0.x" pattern anyway.
5. Early batches of Chateau LTE12 came with 7.0beta6 firmware preinstalled. I apologize because I did not know that when writing my previous post. The latest batches come out of the factory with v7.0.3 preinstalled.
6. The reason for producing Chateau LTE12 with 7.0beta6 firmware was simple - the stable version was not ready at the moment of the initial flashing on the factory. The idea was to flash the beta firmware and later, when devices get shipped to the customers, update it with the stable version. Unfortunately, it did not work. Our update system does not support device model filtering. In other words, there is no option to mark the firmware in the update channel as "Chateau-only". If we publish v7.0.3 into the stable channel, all devices subscribed to that channel will try to update, including v6 devices. We are working on the solution.
7. As a workaround, Chateau LTE12 users who have 7.0beta6 preinstalled and do not want to use the latest public beta (7.1beta6) can create a support ticket, and we will provide you v7.0.3 firmware for manual install.

Stable v7.1 Roadmap
Currently, the showstopper for stabilizing v7 is /routing. in particular, routing protocols and filters. Once the routing stuff is done, we will go into the stabilization phase and aim for v7 release candidates.

For those "software engineering experts" that are going to say "stop all other features and throw all resources on routing", I bring the "9 pregnant women cannot produce 1 baby in a month" quote again. At this late phase of development, bringing additional resources is counter-productive. Initially, new developers just introduced to the project may bring more bugs than fixes. But we need more fixes than bugs. Don't worry - we have very skilled and talented developers working on the routing right now; they just need more time. All features are already implemented and require polishing.

Meanwhile, what about the other MikroTik developers? They are working on other features. That's why you are getting additional fancy features (Wireguard, L3HW, MLAG, etc.) even though the core is not finished yet. Once the routing is done, there will be a feature freeze and 100% effort put on stabilization.

Thanks for your post.

Now if only all communication from Mikrotik was this logical and resonable. <3
You should be promoted, I haven't seen this sensible output here in years.

Let's clarify rumors.
...

Noice - did not know of 7.0.3 for Chateau. What is included in that release or is it a "tagged" version of some existing 7.0 beta?

Stable v7.1 Roadmap
Currently, the showstopper for stabilizing v7 is /routing. in particular, routing protocols and filters. Once the routing stuff is done, we will go into the stabilization phase and aim for v7 release candidates.

That's interesting. I've never used any of the /routing packages since I only use RouterOS for home use.

Anyone care to comment if that means the 7.1 beta might well be "stable" enough for me with my RB4001, CRS328 and 4x cAP AC?

Anyone care to comment if that means the 7.1 beta might well be "stable" enough for me with my RB4001, CRS328 and 4x cAP AC?

I wouldn't recommend it yet for most people, unless you are an enthusiast. I am running it at home on my RB4011 and audience and hap AC with no major issues. There are a few minor issues I can live with - it is not possible to reboot the router without it kernel panicking, so I have to unplug the power physically and plug it back in instead. Also, there is a very slow memory leak on the 4011 so that it will run out of memory and reboot after about every 35 days of operation. Also, IPv6 is broken every bootup until I log into the router to disable IPv6 and then re-enable it, after which it starts working. Aside from that, it is stable enough for me to use, but I would not recommend it to most general end users yet.

@raimondsp
I requested 7.0.3 from Mikrotik support but I was told that there is no stable release for v7 nor such version 7.0.3.

Infabo, please tell me the ticket number of this request. I will investigate.

Is not better to put on download area the 7.0.3 for Chateau LTE12?
Not all user know that is possible to have 7.0.3 contacting support...
The user still have the 7.0beta6 or install for (yours) error the 7.1beta6...

Let's clarify rumors.

Raimonds,

Thank you and keep going !

I really appreciate your guidance here. I understand it is not simple to be "the man in the middle".
You provide lot of good info in your posts.
It's maybe not what some would like to hear, but at least myself I now understand the issues better
(and the problem in which Mikrotik is with Chateau/V7 release process).

Rextended, our download page is automated, we have no ability to manually add something there. If version is not released in all channels, we can only give it out manually.

I can put it here too. This is 7.0.3 for Chateau only: https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1

Thanks, you are really gently as every time...

Do not upgrade Chateau from 7.1beta4 to 7.0.3. It will not boot after upgrade. I will investigate it a bit later.

Let's clarify rumors.

Bravo!

Thank you for the "no bullshit" status update Raimonds.

I can put it here too. This is 7.0.3 for Chateau only: https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1

We should put a big disclaimer next to it:
DO NOT INSTALL v7.0.3 ON ANYTHING BUT CHATEAU!
But I doubt it will solve people's inability to read.

My experience of downgrading form 7.1beta4 to 7.0.3:
- I uploaded 7.0.3 firmware and rebooted.
- My configuration flushed.
- But I am able to connect via Neighbours tab.

Probably, above procedure was my mistake (I don't really know why my config was flushed). After:

- I uploaded 7.0.3 firmware again, went to System -> Packages and press "Downgrade".
- Reboot.
- The firmware downgraded.
- Connected to the router via Neighbours tab again, went to System -> RouterBOARD and press "Upgrade".
- Reboot again.

Then:
- Went to "Files" -> "Upload..." and restored from backup of 7.1beta4. My configuration was restored. I did not test it in details, maybe it's wrong to restore config of 7.1betaX to 7.0.3, you better ask Support Team if this is acceptable solution to restore a config.

As writed thousand times:
backup are for same-device & same-software

If you must change Software, backup is for restore old software if new have some problem.

For EXPORT the configuration between versions or between machines, EXPORT the configuration with /export file=actualconfig, save to PC,
install (netinstall better) new/previous RouterOS with usual way, reset to no-default and apply "section by section" the "actualconfig.rsc" export.
"section by section" = NO IMPORT, use "notepad" and paste relevant lines on termial.

If it was routing related config that was lost then yes it is possible when downgrading from newer betas. As it was already mentioned always export your current config before any upgrade/downgrade from/to beta version.

Infabo, please tell me the ticket number of this request. I will investigate.

thanks normis, already resolved. it was probably a misunderstanding from the support. already got the direct download with the recommendation to better go with 7.1beta7. As 7.1beta7 runs stable for a month already I can't complain at the moment.

still: when was 7.0.3 released and what is included?

As 7.1beta7 runs stable for a month already I can't complain at the moment.

There's a beta7? Also, if there is a beta7, then I need it soon because my RB4011 keeps bricking itself with Wireguard.

As 7.1beta7 runs stable for a month already I can't complain at the moment.

So Beta7 was released at the same time (or close to same time) as Beta6?
What's new in 7.1beta6 (2021-May-18 14:49):

Anyone care to comment if that means the 7.1 beta might well be "stable" enough for me with my RB4001, CRS328 and 4x cAP AC?

Really? You didn't read to the end of post you quoted part of? @raimondsp clearly wrote that (everything) still needs polishing. I wonder how you'd deal with rough parts of ROS if you can't read a few clearly written simple sentences.

This was the kind of statement required. Thanks a lot for the clarification.

Yes, that is a result of their previous business decisions.

I don't want to sound rude but have you ever work in software development industry? This is not the issue with business decisions really. As the software grows the legacy grows exponentially. You can see this first hand in products of trillion-dollar companies like Apple or Microsoft. It's inevitable.

You've picked up one of the most painful parts, but it should be ready before you start releasing products on it.

I think you're oversimplifying here - the v7 stable and v7 dev aren't the same products (which I think by now should be clear based on posts above). You can have a branch with feature flags and disable unstable components. The ERP software I was involved in was running the same exact codebase for everybody but different departments were getting different features released at different times (e.g. risking something going sideways in marketing wasn't as bad as letting it slip in accounting).

How the WG comes here? It is part of the kernel. They have to provide a configuration interface for it.

RouterOS is not an ordinary Linux distro with some userland tools and scripts cobbled together. The fact that something is in the mainline doesn't mean it can be easily made available and work within the ecosystem. The fact that they're able to bring the wireless blobs from manufacturers (which are probably modified anyway) and enable stuff like WG means some major internal change happened.

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

I will like to bring two things here:
1. How well bigger companies communicate their future plans? From my experience you get a product announcement when it's ready and that's it and the changelog lists "bug fixes and improvements".
2. Culture. I was born and raised in Poland and for me the way they communicate is very natural. However after I asked my US friends to read it they said it sounds slightly rude or dismissive in some places. I guess this is just the style and, quite frankly, I much prefer developers saying things here and there instead of a stonewall of a PR department.

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

That was more of an idiom than a comparison ;)

Let's clarify rumors.

That was an amazing read! I know it may be a lot to ask but is it possible for you guys to give even some more rough updates in between releases with such things like "yeah, we have a showstopper with XYZ and we're working on it".

If it was routing related config that was lost then yes it is possible when downgrading from newer betas. As it was already mentioned always export your current config before any upgrade/downgrade from/to beta version.

Correct me if I'm wrong but isn't the internal config format not stable by definition between dev releases? I.e. shouldn't we always start from a fresh one between betas and restore from an rsc?

beta 7 offers far more stability. I guess it is worth the wait.

beta 7 offers far more stability.

Do you have beta7?

I can put it here too. This is 7.0.3 for Chateau only: https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1

We should put a big disclaimer next to it:
DO NOT INSTALL v7.0.3 ON ANYTHING BUT CHATEAU!
But I doubt it will solve people's inability to read.

What /system/package/update channel is this?

channel=forum_with_angry_mods?

I'd rather say it's channel=frustrated_support_engineers ... frustrated by incompetent users who can't read warnings, written with letters of usual size and colour.

beta 7 offers far more stability.

Do you have beta7?

yes

... frustrated by incompetent users who can't read warnings, written with letters of usual size and colour...

+10

I'd rather say it's channel=frustrated_support_engineers ... frustrated by incompetent users who can't read warnings, written with letters of usual size and colour.

Right, so Mikrotik releases an official "stable" software, that is released... on a forum ... page 10 pages down... in a thread related to v7 launch date... ? makes literally no sense.
And it doesnt have a release channel in "system package update"... and every channel you update to, will either downgrade to 6.x or 7.1.x. unstable shit that will probably brick your device.

Yes very stable, and very user friendly. Lets blame our stupid users. :D

And no, I have not bricked my device. I use chauteu device, but the software is nowhere near "stable" on this 7.0.3 release.

Great to know that someone is actually using 7.0.3 on a Chateau. I am on 7.1beta7 and that version is running really stable for me right now. As literally noone reponded to the "what is actually included in 7.0.3? is there a release log?" I did not dare to downgrade to that "stable" version. Doing a netinstall only to find out, that "stable" is not stable as one would expect? Nope. Not worth to find out myself.

Rextended, our download page is automated, we have no ability to manually add something there. If version is not released in all channels, we can only give it out manually.

I have one idea:
read user-agent when is requested LATEST.6 on upgrade site.
If the user-agent is "RouterOS 7.0.3" / "RouterOS 7.0.2" / "RouterOS 7.0beta6" is Chateau LTE12 for sure

Provide new firmware 7.0.4 with a fix on channel, if the model is Chateau LTE12 instead to request LATEST.6
request someting like LATEST.6cl12 etc. etc. etc.

Another hint:
on all devices, add model on user agent...
instead to request upgrade from "RouterOS 6.47.10"
if you add also the model you have more control & statistics...
"RouterOS 6.47.10 CRS112-8P-4S"

I wrote a post recently on v7 timeline and current status:

https://stubarea51.net/2021/07/09/mikro ... l-release/

Thanks to MikroTik for honest summary.
Looks like few users enjoy 7.1b7, any reason why it is not official?

Thanks to MikroTik for honest summary.
Looks like few users enjoy 7.1b7, any reason why it is not official?

Because they have asked to test filters specifically.

Because they have asked to test filters specifically.

Sorry for my ignorance, but why does anybody need route filters?

They had changed the syntax of the route filters already once because a lot of people were complaining about the new syntax and it became a big point of contention, but people did not like the new syntax either. As a result, they are re-conceptualizing the routing filters syntax yet again with this new release. It is particularly important that they get this nailed down rather early to something that people are happy with, as once RouterOS v7 is released more broadly it will become too late to make sweeping changes like this. It makes sense to delay the beta 7 release for this given that such a large number of people wanted for this to be addressed.

Sorry for my ignorance, but why does anybody need route filters?

It's a carrier-grade feature. https://mum.mikrotik.com/presentations/ ... 374753.pdf

If anyone is interested testing new filter syntax and send some feedback, you can contact support and request a test build.

Sorry for my ignorance, but why does anybody need route filters?

Routing filters are needed when running dynamic routing protocols to ensure that subnets that shouldn't be advertised aren't leaked inadvertently.

An example:

Two organizations are merging that have separate networks. The networks will be joined with an L2TP tunnel and a BGP peering between them to exchange routes.

Org 1 has a route for:10.2.0.0/23
Org 2 has a route for 10.2.1.0/24

When they are peered together, there will be a partial route overlap if all routes are exchanged which will break applications. Filtering both of those routes out until they can be renumbered will prevent issues with reachability.

Rextended, our download page is automated, we have no ability to manually add something there. If version is not released in all channels, we can only give it out manually.

I can put it here too. This is 7.0.3 for Chateau only: https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1

Is it possible to download and install the wifiwave2 package on 7.0.3?

If anyone is interested testing new filter syntax and send some feedback, you can contact support and request a test build.

Hi,
Can i get latest test dev build for x86 ?
Im currently using latest v7.1beta6 build, got working CAKE QoS without kernel panic with some tuning.
But there's something odd. As an example, if we create simple queue with CAKE as queue type it wil automatically preserve approx 2M of RAM with no traffic running on that queue.
However, i managed to get rid bufferbloat with CAKE QoS without single mangle or priority stuff which is very nice!
Sure would be happy if i get *early test dev build & give some feedback, since im using x86 then it should be safe enough.

By the way, RB5009 will also have "per device" ROSv7 stable version?

RB5009 was not officially announced yet. So far it took quite some months between official announcement and availability on the street for any new device in last few years. If this tradition remains, we might see stable ROS v7 (for all supported devices) at around same time as street availability of RB5009.

Having a known issues post at the top of the v7 beta forum for the currently available v7 version might not be a bad idea.

The forum is a pretty bad way of managing issues. I think it will be great if MT had a public bug tracker like e.g. JetBrains or other software companies. This will allow for searching for issues using parameters, linking them, marking as duplicates, communicating what was/wasn’t fixed etc.

Currently IMHO we have a lot of noise and mix of questions with bugs.

The forum is a pretty bad way of managing issues. I think it will be great if MT had a public bug tracker like e.g. JetBrains or other software companies. This will allow for searching for issues using parameters, linking them, marking as duplicates, communicating what was/wasn’t fixed etc.

Currently IMHO we have a lot of noise and mix of questions with bugs.

Like other vendors, Mikrotik manage this internally with their helpdesk and bug tracking systems.

If you have bugs, please email support@mikrotik.com or log a ticket via the web portal.

That is exactly my point - they don’t have any public bugtracking system. This results in the same things being repeated in 10 threads. For example the “config resets after reboot” was discussed many times in the v7 sub forum alone.

Duplicate posts are a problem because there are lazy users who instead of doing a search first and going to the right section,
till create a new topic for the same thing...
One example is the hundreds of "dual WAN"...

But for this reason the research has become dispersed and difficult to use...

And thanks for discussing this bug. We read the forum and can decide what looks like a bug, then file it into our internal system.
We don't need 29 similar "config problem in v7" bugs

Although of course it is again more work, it could be useful when "known bugs" or "unimplemented features" are made visible to users via a slightly more structured method than the forum.
I.e. a tree on the HELP system where bugs that are known and require some time to be resolved are shown in an easy searchable way, with some ID that can be referred to here in the forum or in communication with support.
So when a "new bug" or "new feature request" is mentioned here on the forum or in a ticket, it can be referred to as "duplicate of" or "similar to" a certain registered one.

That way you do not need to open your entire bugtracking system to the world, but you can still make the handling more efficient both for us and for you.
I don't know how flexible the internal bugtracking system is, but maybe you could have a text-field there where the person registering and handling the bug can optionally type a short description which would then be regularly extracted and published on the help site. When the bug is resolved, the article automatically disappears or gets a "resolved" status.

See how well that works for the "v7 Routing Protocol Status" in the help system! Finally some status information where you can easily see how things are going.

+1
This was discussed here many times before. Simple list of "known issues" that's updated would be good, even better if it included expected status or result (already fixed,working on it,won't fix)... but that's probably too much to ask for.
However as it is now, Mikrotik have to read duplicate bug reports, here on forum people are repeatedly posting about known problems etc. Have to read every post in new version thread to know what's going on and if there are any known problems.
Best would be to have either special page for known issues/bugs or update the first port in release thread here on forum (as you have done a few time in the past).
There is no need to open your bug tracker to the public or to list every single bug you may have found or fixed... but at least adding a note about most reported/known ones would be good for everyone.

As mikrotik has no interst in maintaining such a public list: why not start as a community maintained list? using e.g. https://hackmd.io where anyone can edit a shared markdown document.

Already this forum can be used:

Simply add buglist topic and a list of post for each error and linked separate topic to discuss every problem...

No, forum-hosted bug-tracking won't do ... unless the initial post is actually edited every time bug state changes. Discussions, interleaved with bug-tracking announcements, will make finding bug-tracking list even harder. If MT us using internal issue tracking tools, it would be nice if the page was actually automatically updated from those tools ... and I don't know if forum posts are easily changable/replacable via some automated procedure.

We already have lots of discussions about bugs, no need to change that. We do need bug-tracking list on a constant URL outside forum so that people learn to go to that well known URL to check if their problem is a known bug and what's status of it. And use forum wisely.

Already this forum can be used:

Simply add buglist topic and a list of post for each error and linked separate topic to discuss every problem...

this has the disadvantage that posts can only be edited by the author. Who keeps it up2date? a single user keeping track?

this has the disadvantage that posts can only be edited by the author.

AFAIK all forum moderators can directly edit all posts. AFAIK all MT staffers present on forum are moderators.

But yes, manually keeping bug-list current is RPITA and I guess MT won't go into this.

AFAIK all forum moderators can directly edit all posts. AFAIK all MT staffers present on forum are moderators.

This is scary, as on other sites like Reddit, it was a scandal if even the site owner was able to change someone else's post.

...it was a scandal if even the site owner was able to change someone else's post...

I ask somethig to hide accidental revealed private data for security,
is not a scandal, is a need.

AFAIK all forum moderators can directly edit all posts. AFAIK all MT staffers present on forum are moderators.

But yes, manually keeping bug-list current is RPITA and I guess MT won't go into this.

Indeed, but AFAIK only MT-staff has mod rights.

Red are administrators (e.g. @normis), green are moderators. I might be wrong, but I think @nz_monkey is not MT staffer.

To be a moderator is not need to be a staff member

Red are administrators (e.g. @normis), green are moderators. I might be wrong, but I think @nz_monkey is not MT staffer.

No @nz_monkey is not part of MT staff.

I think @nz_monkey is not MT staffer.

I am but a mere mortal.

Rextended, our download page is automated, we have no ability to manually add something there. If version is not released in all channels, we can only give it out manually.

I can put it here too. This is 7.0.3 for Chateau only: https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1

Hello, the link doesn't work anymore. Can you give us another one to download ROS 7.0.3 Main package and Extra packages (cwmp/tr69)
tks,
[admin@MikroTik] > /system/routerboard/print
routerboard: yes
model: RBD53G-5HacD2HnD
serial-number: D7B00DB8DFD9
firmware-type: ipq4000L
factory-firmware: 7.1beta4
current-firmware: 7.1beta6
upgrade-firmware: 7.1beta6
[admin@MikroTik] > /system/package/print
Columns: NAME, VERSION
# NAME VERSION
0 routeros 7.1beta6
1 tr069-client 7.1beta6
[admin@MikroTik] >

Now why the heck would you post in the v7 Launch date thread, to ask for a chateau upgrade firmware??
Do you enjoy getting peoples hopes up falsely?????? arggg

Anticipation is the greatest joy and malicious joy is the most joyful one

i've problem reported around 2015 regarding CCR such as (randomly rebooting, ospf NSSA routing, BGP).
Mikrotik allway said, it will be fixed on v7
And Now in 2021, the v7 still not sure when it will release and it's still not sure that it will be stable yet?
A lot of people depend their business on their flagship product such as CCR
All the problem reported such as ospf, bgp are essential function for a router specially for CCR (i think CCR will not mean to use for wireless or LTE function on it)
A very old version of cisco or maybe opensource router like bird and guagga event better handling BGP and OSPF
for example OSPF-NSSA default route are known, when we try to connect CCR with opensource router (BIRD) installed on vm machine.


thx

OSPF NSSA default route problem is also fixed in v6.

We seem to have moved away from the point here, is there a currently a date for Stable, LTS and Testing

In other topics, people say the date is Aug 23rd. No idea what will happen on that date, though...

We seem to have moved away from the point here, is there a currently a date for Stable, LTS and Testing

We have nothing official. Some say aug 23 - but it's all hearsay. Personally, I don't think so. My personal bet (no inside info) is that we will have at least a 7.1beta10. This would put RoS 7.1final somewhere June 2022. But my guess is as good as yours.

I would love to hear where this August 23 date was taken from

No, RouterOS v7.x is continuing the same path as before. We keep fixing the more critical issues, then the smaller ones. It will be out of beta when it's ready, and there is a very small chance it will be in August. If you are using v7, we would love to hear from you, email us about all bugs you find, this will help make it sooner.

I don't really know where it came from...
Ask @mozerd

When will the next Beta be released i would love to see the dynamic routing improvement? im still running 7.1beta6

I would love to hear where this August 23 date was taken from

No, RouterOS v7.x is continuing the same path as before. We keep fixing the more critical issues, then the smaller ones. It will be out of beta when it's ready, and there is a very small chance it will be in August. If you are using v7, we would love to hear from you, email us about all bugs you find, this will help make it sooner.

What needs to be improved? Are there specific issues you have seen?

What needs to be improved? Are there specific issues you have seen?

Yes, I get a crash partway through OSPF configuration and then all the config is lost(disappears)

i am testing on this device.

routerboard: yes
board-name: hEX PoE
model: 960PGS
serial-number: xxxxxxxxxxxx
firmware-type: qca9550L
factory-firmware: 3.41
current-firmware: 7.1beta6
upgrade-firmware: 7.1beta6

This issue is already fixed in internal versions. Please wait until next release.

This issue is already fixed in internal versions. Please wait until next release.

Do you have an ETA for the next release?

When is done.

I would love to hear where this August 23 date was taken from

Hearsay, here on the forum. To be clear: August 23 is rumored to be the date for 7.1beta7 - not 7 gold.

Pouring gold into a tin can?

I don't know this expression. What's the meaning?

You called it gold but many expierence it as being made of the same material as a tin can.

When is done.

This is almost as good as, my legs are long enough to reach the ground.

Can someone upload firmware 7.0.3 for Chateau 5G.
Previous links are dead.
Thx in advance

Could I kindly ask someone to reupload - routeros-arm-7.0.3.npk ?
I cannot find it anywhere... all links are dead

Thanks

@Sn1p3r @kresozg

you need to email support@mikrotik.com for this.

Mikrotik now recommend that you use the latest beta version instead of 7.0.3.
Apparently, before there were issues with the betas that made 7.0.3 a better choice for the Chateau, but it no longer is true.

I've been looking at PCQ and reading about CAKE but the terms used in the help files for CAKE are all foreign to me. Is CAKE capable of breaking customers up into multiple bandwidths? We have about 150 houses on a gig dedicated fiber and a ccr 1009-7g-1c-1s+ with ultra-low latency and that's kept me from imlementing PCQ, but it's getting time to do something. If CAKE can do what I need, then I'll put it off but if not I may as well proceed with PCQ.

By the way, RB5009 will also have "per device" ROSv7 stable version?

I got one now.

How is with updates ?

RB5009 running ROS 7.0.5 stable....

Should I "upgrade" to 7.1 beta 4 ?
There is no official downloads for RB5009.

By the way, RB5009 will also have "per device" ROSv7 stable version?

I got one now.

How is with updates ?

RB5009 running ROS 7.0.5 stable....

Should I "upgrade" to 7.1 beta 4 ?
There is no official downloads for RB5009.

7.1RC3 and 7.1RC4 have IPsec offload so if you need that might be worth upgrading.

Ok, thx,

Installed.

Please close this thread.
MT will not tell when it will launch v7
And its missused for other question....

7.1 non-RC will be released this year, when most critical showstopper bugs are fixed. Please make separate topics for other questions