Of course there is always the decision between “do we use a fixed kernel version, apply all our own patches, and then try to backport important patches from later kernel versions to keep it secure” and “do we follow the released kernel versions and maintain our own patches so that they can be applied to the released kernels”.
I would opt for the latter. And maybe try to submit some of the in-house patches so that they become part of the released kernel, and no longer have to be maintained separately.
Great to see a discussion about the Linux Kernel, that brings me to a feature request I have seen in this forum a lot 
When will Mikrotik introduce the support of IPsec VTI?
It is supported by Linux Kernel since 3.6.
Not using a LTS kernel can’t be “patched” by applying “lots of” patches. Your kernel branch is not supported anymore. It is kernel version 5.6.3 apparently. You may backport and apply all the patches you think you need selectively - nice try. This is wasting at least one developer manpower only for patch management for your diverging kernel. It gets harder every month/year. Randomly introducing bugs by this process included. In my opinion this is insane.
Maybe Mikrotik is already patching kernel heavily with their own code. Or maybe it is the size they could squeeze out of 5.6.x and after realizing that LOC are increasing heavily with every kernel release thus increasing size is a big issue when one deploys on 16MB platforms.
And of course you reach a point where you can’t “cherry pick” commits anymore. It won’t get better by finding workarounds for the AX compatibility thingy. My experience is: when someone talks about “finding a workaround” this is a clear sign of tech debt.
I mean: forget what I said. I am some random dude. Listen to Greg Kroah-Hartman.
As stated in the post and many other posts in other version topics - please keep this topic related to its purpose. This is v7.16 topic. For other discussions, open up a new topic. The bigger half of posts in this article is not in any way related to this release.
On Topic: 7.16 RC1 - Found an annoying bug with the 6to4 tunnel interface. I have VRRP on-backup and on-master scripts that disable or enable various interfaces to enable HA between to Mikrotiks.
One of the Mikrotiks ended up in a boot-loop. The root cause was a process failure when the 6to4 tunnel was re-enabled. (When booting the on-backup script is always run because VRRP starts in backup state, this disabled the 6to4 tunnel. A couple of seconds later the device transitioned to master, and the on-master script ran and enabled the 6to4 tunnel - this caused a router reboot, and then a boot-loop).
Reproduced on a blank netinstalled Mikrotik, and also a x64 CHR. Could also force the issue by disabling and re-enabling the 6to4 tunnel via Winbox a couple of times.
Created SUP-161728 to report the issue, included autosup.rif and also a script to re-create the problem. Hopefully this can be fixed before release.
My hAP ax lite lte6 reported:
lte;error lte mbim: >>> E #15 - connect: connect, error: FAILURE
Though with no real issues recognized. Are you interested in a support output file?
On the other hand, when issues related to this release are brought up, there is no reply from MikroTik employees, and when generic issues are discussed, they jump right in.
Thank you. Issue reproduced. We are working on a fix. Seems that problem is present if you configure 6to4 before adding any IPv4 configuration. Basically - while setting up.
The problem appears to exist regardless of IP configuration. It was first detected on a fully configured and working unit that was upgraded to 7.16 rc1. I just tried to find the minimalist config required to reproduce the issue. (Of course in my live mikrotik if the ISP pppoe tunnel is not up then there is no default route until it is established). I could also disable/enable 6to4 interface multiple times in winbox with a fully configured unit with ospf routes established and it would still crash.
But thank you for acknowledging the problem, I’m hopeful you’ll discover the root cause before the release version. It would be nice to have my ‘HA’ back.
I have some questions on how the reselect-interval works? Does it uses dedicated RF hardware like other vendors and most importantly does it interrupt WiFi network traffic on the interface when a DFS channel is being used and the background scan is triggered?
Thanks!
Edit: I have a hAP AX3
LTS kernel support was recently shortened to just 2 years and one of the reasons stated was that almost nobody is using them and that is according to Greg Kroah-Hartman. He is right of course when saying that the most recent mainline stable kernel is the most secure one but companies like Red Hat that also must care about stability of their product are using custom kernels with backported patches. RHEL 8 for example is using 4.18 and RHEL 9 is using 5.14, neither of which is supported by Linux mainline kernel developers for many years… Since Mikrotik must support their products for many years while keeping compatibility they cannot afford to change kernel to currently stable version every couple of months so Red Hat approach seems better fit for them…
Just a heads-up about the Linux kernel support lifecycle: LTS now typically lasts around 2-5 years while SLTS/CIP is supported for a minimum of 10 years from the initial release but might go on much longer.
https://en.wikipedia.org/wiki/Linux_kernel_version_history
https://lwn.net/Articles/749530/
https://www.kernel.org/category/releases.html
As a software engineer, I have to agree that latest and greatest is not always the best specially if you have to maintain such a complex codebase like RouterOS with custom network stack, device drivers and so on. It’s not uncommon for networking vendors to build from whatever Linux/OpenWrt based SDK the chipset maker gives them but Mikrotik is building their own thing from scratch and I admire that.
Reasons to move to new kernel versions include:
- major new features that have been added and are not so easily “backported” to the kernel you use
- drivers from manufacturers, maybe in binary form, that are not compatible with an older kernel
- not wanting to track each and every patch to see if not having it could impact security of your device
But of course, we have seen that the decision to move to a new kernel version is so hard for companies like MikroTik that it can take many many years before they finally take the plunge.
(and all that time it becomes harder and harder, because there will be more changes that impact functionality of your device)
See how long it took before the promised land of v7 was finally delivered.
(and still today people are complaining because routing performance is less than it was with v6)
Me too, also with the default !reselect-interval channels are not scanned?
Stil no answer to SUP-155649 asking to provide extra info about this feature.
You can read some advices: https://forum.mikrotik.com/search.php?keywords=reselect-interval&t=208039&sf=msgonly
I would answer with yes. It would be a breaking change otherwise.
I tried with a low interval and the interface status changes to scanning, dfs and whatever. So it is no background operation. May be different on AX hardware though.
This should be a good thing, right?
Please confirm that clients are not disconnected during scan.
Should be nice to have some indications about recommended values too.
Why is so hard for MT to make a real stable system, compare with cisco, juniper, even vyos, its suppose have a very powerfull cpu right? With so many rams and cpus
Kernel panic
Unstable bgp
Suddenly Reboot by watchdog.
Thx
I tried it as well on my AX3 and the clients get disconnected, that’s not good.
re read my post please. I said the interface status changes from running to scanning (don’t remember the exact term). So of course the clients are disconnected.
But with the change of 7.16 something changed and it may not noticable because anymore:
*) wifi - send channel switch announcements to clients when switching channels at requested re-select intervals;
But I don’t know what it actually does. Mikrotik did not explain it thoroughly. Classic Mikrotik changelog item that leaves you behind with a lot of questions. Mikrotik - please explain this functionality. Thank you.