The only problem you have is: Mikrotik does not announce EOL dates?
congratulations - coming from 7.20.6 - changing devices to have a long-term tree - seems like the perfect idea.
sadly 7.20.7 lost the OIDs 1.3.6.1.4.1.14988.1.1.18.1.1.2.nnnn to call scripts and get return values⌠how could this happen in a long-term release?
and - yes the calls like 1.3.6.1.4.1.14988.1.1.18.1.1.2.1 (for the first script) worked in 7.20.6
To v8, please avoid as much as possible ports and special customizations on Kernel.
This will make it more possible to upgrade Kernel Base during the same Major Release.
I understand that MikroTik's standard was that each Major Release should always be in the same kernel. Other manufacturers have also used this for a long time.
But I've seen a movement in Appliances manufacturers decoupling as much as possible from the Kernel precisely with the intention of not having to refactor everything when they need to update the Kernel.
And to break the ice, a brief reference to Eleonor, a respectable V8.
Edit: In the point of view of all these âLTSâ arguing, beyond decoupling from KernelâŚ
One more ask: Please use Tests!
- Development tests.
- Production tests.
- Container Lab tests. SEVERAL of those.
- Some hardware based tests.
Anyone who has even a modicum of interaction with dev knows that writing tests is a pain in the ass.
But please... Write tests!
And if possible, share ContainerLab's test templates.
Encourage the community to replicate testing, and perhaps even extend testing and share it.
Could you please explain what is meant by âLTS stays the same.â?
I mean, will the long-term branch receive v7.21.x once it is mature enough, or you plan to maintain separate channels, with the long-term receiving only fixes for v7.20.x while new features continue to evolve in v7.2X.x?
Every version above 20.6 have same SNMP issue 
The MikroTik business is partly based on having features that are desirable in the router market, and that are not available on standard Linux boxes. Sure you can buy a generic PC or âsoftware routerâ box and install a standard Linux or evens something like OpenWRT and use it as a router, and for most functions the difference will be only in the user interface, but special features sometimes require kernel changes and MikroTik sees these as added value. Of course motivated by requests from users here on the forum and via sales.
When RouterOS would use a standard kernel, some of its features would not be available.
I partially agree with you.
Without a doubt, some of RouterOS's most interesting features today depend on strong interaction with the kernel. No doubt about it.
The suggestion in this case is to put as much as possible into modules coupled to the Kernel (considering that in Kernel versions 5 and 6, module support and the depth of what can be done with modules improve significantly).
This would make maintaining these features much simpler (from an outsider's perspective), even in cases of Kernel replacement.
I think a very interesting example of this is eBPF.
One of the recurring requests is IDS/IPS/WAF and things from an NGFW. And trying to achieve that by porting it into the Kernel would be a nightmare. And using eBPF is essential for that.
Well, that's not what I was referring to.
I see open source solutions like SONiC, VyOS, IPFire going along the same lines I mentioned.
And also commercial products like the Juniper Junos-EVO, Cisco IOS-XE, Arista EOS.
Here's where I think you might have misunderstood my point.
The idea isn't to prohibit or completely eliminate changes to the Kernel.
The proposal is to minimize, as much as possible, direct changes to the Kernel, using modules and related methods.
And for cases where changes to the Kernel are essential, do so in patch format, as a branch of Linux Base, resulting in a customized Kernel. In this way, applying a patch that is functional in version 6.12.58 would have a very high chance of working without needing any adjustments when applied to 6.18.5.
In short, the idea is to break the paradigm that I only recently understood that "Kernel-Linux replacement" RouterOS only occurs during Major Release updates.
A desired scenario(hypothetical) would be something like this:
- RouterOS 8.3 using Kernel 6.17 as a base.
- RouterOS 8.4 using Kernel 6.18 as a base.
I have not checked the current state of things but back in the v6 days the changes to the kernel were available for download. I think they should still be, that is a GPL license requirement.
But the changes were very large, and it has taken many many years before the step of using a new kernel was taken. I agree the changes should be limited as much as possible, but what is âpossibleâ.
There is not much difference between putting things in a module or adding a new sourcefile to the kernel tree. What matters is the interface to the rest of the kernel, and the kernel developers do anything they can to make this as volatile as possible, precisely to frustrate developers who make products that rely on the kernel interface but who do not want to submit everything in the kernel tree, e.g. Nvidia.
MikroTik probably have, like many developers, given up on getting what they need accepted into the official kernel tree. I once tried to submit a patch that was only a couple of lines and that affected only a niche part, and I understand the problem.
Kudos to the Mikrotik team on the LTS release, itâs been something Iâve been waiting for for a while. I am pleased those Wifi issues many of us had are now behind us - my hAP AX3 will now enjoy 7.20.7 for some time!!
After upgrading CRS317 7.20.6 â 7.20.7 the backup script fails.
Reason: filename starting with /flash/ is not valid any more and you can not get configuration backups which survive reboot.
/ export file=/flash/DPsw2
invalid file name
Remove the leading /.
/export file=flash/DPsw2
Found the change needed in the script - you have to remove leading â/â:
/flash/DPsw2 is invalid since 7.20.7
flash/DPsw2 is OK and will work.
It may be better to use only a plain filename, i.e. backup in the RAMdisk, and then extend your script with some method to move the backup somewhere else. E.g. mail it.
Devices that have the /flash directory have limited flash space and putting stuff there may make you run out of space. Furthermore, it is not very safe to put the backup on the device itself.
I've just disabled a VXLAN interface and router stop working ; need poweroff to get it back.
Anyone who is experiencing issues with script execution via SNMP.
*) system - detect policy mismatch sooner if script is executed internally by some other service
SNMP is limited to the following script policies: ftp,reboot,read,write,test,romon
Permissions are now checked before script execution, and scripts requiring additional policies will not be executed.
Remove the policy,password,sniff,sensitive policies from scripts intended to be executed via SNMP.
It is currently known that if a script is configured with dont-require-permissions=yes, it still cannot be executed via SNMP.
Upcoming RouterOS versions will provide improved error messages for permission-related issues, and the dont-require-permissions=yes behavior will be fixed.
Sorry for the inconvenience caused.
Heureka! I always struggled to find out proper minimal permissions for scripts. I highly welcome log message pointing in the right direction which permissions are missing.
That is just not true and frankly a bit silly to think so... to quote Greg Kroah-Hartman
You think you want a stable kernel interface, but you really do not, and
you don't even know it. What you want is a stable running driver, and
you get that only if your driver is in the main kernel tree. You also
get lots of other good benefits if your driver is in the main kernel
tree, all of which has made Linux into such a strong, stable, and mature
operating system which is the reason you are using it in the first
place.
Maybe you should read rationale behind this at .. _stable_api_nonsense:
And no Linux developers do not waste time to deliberately break something just as MikroTik does not do it to make some 3rd party OS like OpenWRT cannot boot on their devices...
Just created a case (SUP-208488) on MKT support about VXLAN when enable/disable interface totally kill the router (rb5009) with this release and the 7.21 ; but no problem in 7.20.6.
Because i've problem on two routers, i've send boths logs and supout.
I'm looking for " * bridge - improved system stability when forwarding traffic with fast-path and bridged interface gets removed or disabled (introduced in v7.20);"
The problem with that reasoning is that it is very hard to get your driver or other change into the main kernel tree.
I can fully understand when MikroTik (or Nvidia) no longer even TRY to submit such changes! And just live with the fact that their locally developed patches are difficult to apply to a newer kernel version.
Using modules instead of compiled/linked functions does not change anything in that regard, precisely because the modules have to interface to the same code.