Please use resource on getting a long term 7.x version. As it is now there are new 7.x train every week, but not may bug fixes for current train.
Latest releases that should be followed up
7.1.5 - 22 Mars 2022 (maybe 7.1.6 LT next)
7.2.3——2022年5月2日
7.3.1 - 9 Juni 2022
7.4.0 - 19 Juli 2022

Lol at this rate, by the time 7.x reaches true stable status we will be on 8.x v7 will be a bridge/transitional version to stable only xD
But with changelogs like these, that's worth it IMO :)

Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.

Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.

7.5beta4 is on Kernel 5.6.3.

Please use resource on getting a long term 7.x version. As it is now there are new 7.x train every week, but not may bug fixes for current train.
Latest releases that should be followed up
7.1.5 - 22 Mars 2022 (maybe 7.1.6 LT next)
7.2.3——2022年5月2日
7.3.1 - 9 Juni 2022
7.4.0 - 19 Juli 2022

Its cuz v7 as a whole is NOT considered production ready and I fully support this approach to at least subtlety acknowledge it to the community

What's new in 7.5beta5 (2022-Jul-28 10:59):

*) health - renamed "CPU" to "switch" for temperature reading information on CRS518-16XS-2XQ;
*) l3hw - fixed HW offloaded NAT;
*) ppp - improved service stability under high load;
*) ppp - use /32 as default netmask if not specified for "routes" parameter;
*) sfp - fixed "eeprom" reading on single SFP port ARM devices;
*) sfp - fixed unresponsive "sfp1" interface after disabling "ether1" on NetMetal devices;
*) swos - enabled SwitchOS support for CRS310-1G-5S-4S+;

PLEASE ADD THIS TO THE FIRST POST !

It will be, in the first post of the 7.5 release topic.

Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.

7.5beta4 is on Kernel 5.6.3.

how did you find this? is there a CLI command that shows the kernel version?

Rocket science!

7-zip....

Rocket science!

Code:Select all

/system/resource/usb/print Columns: DEVICE, VENDOR, NAME, SPEED # DEVICE VENDOR NAME SPEED 0 2-1 ADATA XPG EX500 5000 1 1-0 Linux 5.6.3 xhci-hcd xHCI Host Controller 480 2 2-0 Linux 5.6.3 xhci-hcd xHCI Host Controller 5000

This only works in devices that indeed have USB. But all devices use the same kernel version so when you have multiple routers running the same RouterOS you can likely find it from some.

7-zip:
routeros-7.4-mipsbe.npk\lib\modules\5.6.3\

From what I can see, the only changes regarding netmap in Linux kernel 5.8+ were with nftables, but I believe RouterOS still uses iptables and so I don't think these nftables related enhancements would make any difference.

I'm sure they will upgrade to a newer kernel at some point in the reasonably near future. However, given that they are focused mostly on quashing bugs, I can understand that they might want to hold off on that if it isn't completely necessary, as the kernel upgrade itself could create new issues that did not exist before.

I'm sure they will upgrade to a newer kernel at some point in the reasonably near future.

RouterOS v8 for sure :-)
New kernel seems a major effort. Maybe now at this moment it is a little easier because they have been working on it recently.

New kernel seems a major effort.

Not really. v6 sticked at ancient 3.something due to routing stuff ... if kernel functions (API) don't change (much), then it's much easier to upgrade. I'm with @mducharme, I also think MT will stick to 5.6.3 while they port/implement functionality. I hope we'll see newer kernel later in v7 development.

I think that a new kernel is not a major effort anymore (as mkx said). It was true that it was a major effort when making the move from the old RouterOS v6 kernel, as the removal of route caching was a huge change that required rewriting the entire routing stack. However, we are unlikely to see any such major changes in the near future in the Linux kernel 5.x. The biggest risk in upgrading the kernel in RouterOS v7 above 5.6.3 is unintentionally introducing new bugs, which is why I suspect they would wait until the biggest v7 bugs have been quashed before changing the kernel version.

Why do they stick with kernel 5.6.3? Why not using latest 5.6.19 at least? Makes me really wonder.

Why do they stick with kernel 5.6.3? Why not using latest 5.6.19 at least? Makes me really wonder.

Mikrotik heavily modifies the Linux Kernel to support all their hardware. For example, the tile architecture (used in CCR1016/1036/1072) was dropped in Kernel 4.17. So Mikrotik has to manually patch in support for this architecture and keep it up to speed with current kernel development. And the nature of kernel development is such that once support for an architecture is dropped a lot of adjacent functions that may have supported that architecture in the past are removed subsequently increasing the delta with every new version of the kernel.
So Mikrotik has to make a decision whether it is worth it constantly catching up with the Linux Kernel or doing one big push (eg. RouterOS 6 to 7) and then focusing on stabilizing the features against that huge leap in change of function.
And while 5.6.19 may not be that big of a jump from 5.6.3 it is likely that most changes in the changeset do not even relate to Mikrotik hardware. So why bother and possibly introduce negative side effects? Security fixes can be easily cherry picked and backported while leaving everything else untouched. This is not an uncommon way of stabilizing software in the Linux world.

Well, when the software will be properly stable then, all promise v7 will solve routing problem still not proven yet.
I cannot depend on mikrotik anymore in my environment, i dont think v7 will be stable soon

Mind blown. I always thought all they do is just a simple apt-get update every time they release a new ROS version.

Mikrotik heavily modifies the Linux Kernel to support all their hardware.

Not only their hardware, but more important: their features.
有a lot of RouterOS features that rely on specific changes in the kernel. You could see that (and can still see it) during early v7 releases where random did not work or were unavailable due to the kernel change which was not really completed.
Now they have re-done a lot of that on the 5.6.3 kernel and they have (or can make) a list of their patches from the stock 5.6.3 to the kernel they run.
(that should even be downloadable from the site due to GPL obligations)
Then, as long as the stock kernel has not diverted too much it may be possible to apply that same patch on a later kernel. But there will be rejects that have to be manually reviewed, and potentially there also can be problems because things now work differently in the new kernel and even when the patch applies cleanly it still does not work correctly anymore.
So there is work involved and testing. This work will get more and more the further they get behind the kernel developers, and at some point it will be deemed "unrealistic" and we are stuck with a kernel version (as happened in v6). That of course also gives them work to do, because new hardware uses new chips and the drivers they get from the manufacturer will be expecting some minimal kernel version as well. So integration of new hardware will become more and more difficult.

It is a tough situation to be in, and it is easy to see why things go as they do.

Who are we volunteering to integrate theseseventeen thousand changesagain?

In this case there are always two approaches:
1. start from the current modified 5.6.3 kernel and integrate the 17000 changes between 5.6.3 and the newer kernel into that
2. get the changes between stock 5.6.3 and the modified 5.6.3 kernel and apply those (likely less than 17000) changes to the newer kernel again

It will depend on available expertise (man hours of people who know what is happening in kernel development) if it is a costly job.

First approach would be really silly tbh. #2 is very likely what they do.

If they are really customizing the kernel source itself, then - depending on how much they changed - can be a really tough road to 5.10.

The difficulty does not dpeend (much) on number of inserted lines, more on number of inserted blocks of lines.
A lot of the above probably comes from "support for TILE" as it is no longer present in the standard kernel.

嘿,我已经写的可能会很多work! Some people seem to think it is just "apt-get upgrade" but that certainly is not the case here.
So let's assume for now we will be stuck with kernel 5.6.3 and not request any features that are in higher kernels.
(I would appreciate it when MikroTik work on feature parity with v6 instead. I.e. finish all the work to make v7 a worthy replacement of v6 before working on new features)

I mean if their modifications arent in the form of kernel patches, they are completely doing it wrong. We have been kernel patching on openWRT for decades (across multiple architectures), VERY successfully. I suspect its drivers and lack of a super solid regression test suite holding it back. My understanding is this new kernel is a rethink of their build architecture.