General discussion on stable releases - cut off from 7.25 [stable] announcement thread

RouterOS General
1

Not that I want to get too off topic of 7.25 in this thread - but on the Winbox v4 tangent I agree I can make it a little better by changing fonts etc, however I am most bothered with:

  1. can't use v3 sessions, I have to start a fresh, I have several thousands of sessions in my session folder it is a pain to set up winbox windows on every router again!

  2. I can't find a way to set a network share for my sessions folder, it seems to be stuck in username/appdata/roaming/

  3. screen real estate is everything, the main page with the huge banner on the left hand side needs to be moved back to the top, I have to have my fonts sooooo small to fit our long router dns names, groups and comments in the list and

  4. the buttons at the top of windows are now two-click via a tools menu unless I want them on the right hand side panel, I want them back at the top.

Cheers,
Jono.

2

It's disappointing to continually read issues with 'stable' releases, especially after people raise feedback during Beta and RC stages. The ongoing angst about how Mikrotik should do their release notes, testing, LTS etc. is a bunch of hand wringing that has gone on for years and simply doesn't change anything - you're all shouting into the void. Mikrotik clearly has a culture inside the company of 'move fast and break things' which none of us will fix by yelling from the outside.

I really want to love Mikrotik as a company, but software stability is one area they really let themselves down on. I won't ever go back to SOHO crap like Asus/TP Link/Fritz, and I won't go back to Ubiquiti after being burnt on their lack of support too.

All I can suggest from this is never upgrade to a .0 version, and wait at least to .2 or .3 if possible. It is good to see continual developmet of ROS by Mikrotik, but for those who want stability in their SOHO, Retail ISP etc. suggest the only way forward is upgrading to the final release of the prior major version, and only updating to latest version if there are critical security flaws like those that recently came up.

Hopefully with more AI tools, Mikrotik can virtualise more of their hardware and do better regression testing. I hold out little hope on that and will just upgrade as above in future.

3

Software quality gets a lot of impact from CVEs that describe purely imaginary "attacks" that still have to be mitigated immediately or else a lot of backlash occurs from people who have not even read the CVE. Quick fixes may solve the vulnerability but may introduce new functional problems, and it then takes time to fix those, if it is even possible. Functions may cease to work forever, older protocols may be removed even though they are still used by some old equipment you may have. And in the process, all software becomes larger and slower. Hooray!

4

It's not just the software anymore; MikroTik's hardware is having issues lately too.

I eventually switched my core router over to Debian because setting it up took way less time than constantly reading forum threads about their bugs and dropping quality control.

With them pushing out PM2.5 dust sensors now, maybe we'll get a MikroTik smartwatch next instead of stable core products.

Our loyalty works against us!

5

While I agree with most criticisms to MikroTik (and I make my fair share of them often), I cannot see how setting up a linux box as a router can be faster than setting up a MikroTik. On a MikroTik and Winbox, with literally a few clicks you can start routing packets. With Debian (or any other distro) you have to type tons of commands until you can just do the basics. If you need more advanced stuff then it's loads more of typing.

Even having pre-made scripts that set up everything automatically, still cannot beat RouterOS in configuration time.
Having both configured via scripts, RouterOS will still be faster from boot to routing packets for the first time.
RouterOS would start routing packets before Debian had even booted its kernel. There's just no comparison.

I am not sure what your use-case is exactly, that you run on so many bugs that'll take you so much time to set up.
Probably it's lack of experience with the platform, rather than bugs and QC. There are bugs for sure, but routing works fine for the most part - especially for normal stuff. Really advanced/esoteric stuff will tend to bring out bugs, but normal use just works.

In regards to hardware, while I am not trying every single piece of MikroTik hardware anymore as much as I used to (especially anything related to wifi), the RB4011, RB5009, CCR line etc (ie just routers) work flawlessly, and I haven't had any issues with them (with hundreds of them - so a substantial sample size).
Many of them are placed in terrible environments (ie 60-70degrees ambient temps) - and still work after many years. Other vendors simply fail within a year in those environments, and those that have variants rated for harsh environments are on another league of their own cost-wise.

As a matter of fact, the quality on MikroTik hardware is substantially better than many other vendors out there - especially for how little they cost in comparison.

Some models may feel like plastic toys, sure, but they just work. For years on end without breaking ever.
Most failures I've had were with power supplies rather than the routers themselves.

Sure, there have been some models that had design flaws, but those were very few in the last 15 years I've been using MikroTik hardware.

6

Seriously? On my Linux systems, the moment I set /proc/sys/net/ipv4/ip_forward to "1", I'm routing ... Firewalls and such are a different issue, but getting IP routing running across all configured interfaces is changing a single parameter. Mikrotik or Linux, the interfaces still have to have IP's set, and the workload there is similar.

Even on a clean install, it's pretty much trivial. (However, I don't run distros that layer on a bunch of crap that you need to disable first either.)

Boot times are similar as well, and most of my main Linux servers will come up far faster than most of my Mikrotik gear (and can run with similar uptimes), so, again, not seeing the boottime issue unless one is running ancient resource strangled hardware as a Linux router . . . .

(Not that I am advocating Linux as a router vs. MikroTik . . . just it's ease of use.)

????

7

You completely missed my point about Debian. I wasn't comparing boot times or how long it takes to configure Debian versus RouterOS. I was comparing the time it takes to set up Debian against the hours wasted "reading this forum" - trying to figure out which ROS version is actually safe to use, tracking regressions, and reading about the latest bugs and users dispute regarding RouterOS software quality/software policy. It’s not about a lack of experience; it’s about the administrative overhead of dealing with their software lottery.

Regarding the hardware, I'm glad your CCRs and RB5009s are holding up well. But look at their recent track record. The new "BE" series is already infamous on these boards for temperature issues and underwhelming Wi-Fi performance. That’s exactly my point: instead of ensuring their new core networking and wireless gear works flawlessly out of the box, they're busy releasing dust sensors.

8

I setup my first mikrotik router from 0 with very very basic knowledge wanting to learn and get better at networking and with chatgpt in literally 35 minutes, i have no idea what you're talking about, actual baseless ragebait.

We are talking from "getting the internet from my isp to everything on the networks".

9

you can DO the same with debian.
You just didnt do it :slight_smile:

10

The difference is that with Debian "Stable", I don't have to do it.
When Debian pushes a security patch or a minor update to their stable branch, it doesn't randomly break basic routing, BGP, or firewall rules.

With RouterOS, checking the forum before every single update isn't just an option - it's a mandatory survival step to avoid beta-testing their "stable" releases.

Debian’s quality control actually reflects what "stable" means. There has been a lot of discussion on the forum regarding the MikroTik update policy.

11

Congratulations on setting up basic e.g. NAT and DHCP with ChatGPT in 35 minutes. Most consumer routers do that out of the box in three.

You completely missed the point. I'm not talking about the initial setup of a simple home network.
I'm talking about the long-term maintenance: babysitting RouterOS updates because "stable" releases frequently break things, and dealing with hardware regressions.

When you have to maintain an actual infrastructure over time instead of just connecting to your ISP, you'll realize it's not "ragebait".

EOD / EOT.

12

And i am not surprised longer, to see how many installing a new release just some hour after a release. And many of them are user that are listed as new user that has their firs post.

I do agree that all update should work out of the box. Like I have rarely have problem update a linux distro.

But for Mikrotik.
Try to stay away for .0 release.
Read the forum.
Install on a similar test device and see if it works.
Then if all looks ok, do upgrade after some days.

13

There's OPNsense and pfSense - or if you insist on running a Linux kernel instead of a BSD one OpenWRT and IPFire.

I am running all my layer 3 on OPNsense, could not be more satisfied. But the other projects supposedly work fine, too.

Main reason for me to pick OPNsense: project located in the EU, hardware company behind the development is Dutch. The same reason I have come to prefer Mikrotik over Unifi or Cisco for layer 2, now that I think about it :wink:

Kind regards,
Patrick

14

Ugh. Liberation Mono is so much better; should have been the default. But all the other complaints remain valid. Very disappointed to be forced to WinBox 4. (Don't really care about progress meters and other gee whiz graphical things in WinBox. I can go to Webfig for those.)

15

Depends on use case. On internal routers, firewalls are often not needed . . . .

DHCP, DNS, are not actually routing, but often get dumped there (things like a full bind implementation are far more appropriately deployed on a server).

VLAN routing on linix is as simple as configuring the VLAN interfaces.

(Granted, a gateway router to the outside is far more complex . . . )

16

That's really the scenario I had in mind. This all started with someone moving their core router to Debian, and that's the box doing NAT, firewalling, DHCP, DNS and quite possibly PPPoE. So I think we're closer than it looks.

Agreed, and I wasn't saying they were routing. My point was about who owns them. On RouterOS they're part of one image from one vendor. You upgrade the router, and DHCP, DNS and the firewall all move together. On Debian, each is a separate project with its own lifecycle, and you're the integrator. ISC DHCP going end-of-life and everyone having to move to Kea is a good example, as is the iptables to nftables shift. None of it is hard, but it's your work, and upkeep is what this thread is really about.

This is where I'll respectfully disagree. Even a purely internal router has a management plane (SSH, WinBox, the API, SNMP, BGP), and I'd want that filtered so only the management network can reach it. And if a router passes traffic between VLANs with no rules at all, the VLANs give you separate broadcast domains but no real segmentation. That's fine in a lab, but I wouldn't run it anywhere that mattered, since lateral movement across internal networks is how a lot of compromises spread.

VLAN interfaces on Linux are easy, though. No argument there.

Anyway, we're well off-topic for a release thread, so I'll leave it there and happily agree to differ on the internal firewall bit.

17

Traffic management in a larger environment and separate broadcast domains.

18

Did we start yet another offtopic "what is better MikroTik or ..." and "what MikroTik is doing wrong' discussion in a release topic?? UNBELIEVABLE!
Mods: please move everything over to another topic or delete it altogether. People come here to see issues with this particular release, not that kind of discussion.

19

Done as you see/read.

20

So, starting with 7.25, we'll actually have clean release topics? And the reported posts will actually be handled? Thank you.