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 - 2 May 2022
7.3.1 - 9 Juni 2022
7.4.0 - 19 Juli 2022
Re: v7.5beta [testing] is released!
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 :)
But with changelogs like these, that's worth it IMO :)
Re: v7.5beta [testing] is released!
Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.
Re: v7.5beta [testing] is released!
7.5beta4 is on Kernel 5.6.3.Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.
Re: v7.5beta [testing] is released!
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 - 2 May 2022
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
Last edited by JJT211 on Thu Jul 28, 2022 7:15 am, edited 1 time in total.
Re: v7.5beta [testing] is released!
PLEASE ADD THIS TO THE FIRST POST !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+;
Re: v7.5beta [testing] is released!
It will be, in the first post of the 7.5 release topic.
Re: v7.5beta [testing] is released!
how did you find this? is there a CLI command that shows the kernel version?7.5beta4 is on Kernel 5.6.3.Anyone know which linux kernel version 7.5b is based off of? Looking forward to full NETMAP support in kernels 5.8+.
Re: v7.5beta [testing] is released!
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
Re: v7.5beta [testing] is released!
7-zip....
Re: v7.5beta [testing] is released!
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.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
Re: v7.5beta [testing] is released!
7-zip:
routeros-7.4-mipsbe.npk\lib\modules\5.6.3\
routeros-7.4-mipsbe.npk\lib\modules\5.6.3\
Re: v7.5beta [testing] is released!
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. 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.
Re: v7.5beta [testing] is released!
RouterOS v8 for sure :-)I'm sure they will upgrade to a newer kernel at some point in the reasonably near future.
New kernel seems a major effort. Maybe now at this moment it is a little easier because they have been working on it recently.
Re: v7.5beta [testing] is released!
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.New kernel seems a major effort.
Re: v7.5beta [testing] is released!
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.
Re: v7.5beta [testing] is released!
Why do they stick with kernel 5.6.3? Why not using latest 5.6.19 at least? Makes me really wonder.
Re: v7.5beta [testing] is released!
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.Why do they stick with kernel 5.6.3? Why not using latest 5.6.19 at least? Makes me really wonder.
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.
Re: v7.5beta [testing] is released!
well explained, some people think is like updating a PC typing or something like that
Code: Select all
sudo apt-get updateRe: v7.5beta [testing] is released!
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
I cannot depend on mikrotik anymore in my environment, i dont think v7 will be stable soon
Re: v7.5beta [testing] is released!
Mind blown. I always thought all they do is just a simple apt-get update every time they release a new ROS version.
Re: v7.5beta [testing] is released!
Not only their hardware, but more important: their features.Mikrotik heavily modifies the Linux Kernel to support all their hardware.
There are 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.
Re: v7.5beta [testing] is released!
5.6.19 may not be that big of a jump from 5.6.3
The Linux kernel is one of the busiest software projects of all time. Even between two point releases made a few months apart, it's a huge jump:
Code: Select all
$ cd ~/src/linux/kernel
$ git diff v5.6.3..v5.6.19 | diffstat
...
1687 files changed, 17478 insertions(+), 8471 deletions(-)
Who are we volunteering to integrate these seventeen thousand changes again?
(If you want to replicate this result, you have to use the stable Linux kernel Git tree, not any of the many others, since they generally won't have these version tags in them. My oh my does Git suck.)
When MikroTik does change to another Linux version, my vote is for one of the longterm releases, ideally the one with the furthest-out projected EOL date. Today, it'd be 5.10.
Re: v7.5beta [testing] is released!
In this case there are always two approaches:Who are we volunteering to integrate these seventeen thousand changes again?
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.
Re: v7.5beta [testing] is released!
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.
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.
Re: v7.5beta [testing] is released!
…depending on how much they changed…
We don't have to guess about that. MikroTik's policy for complying with the GPL is to give the sources to anyone who asks. Some recipients then use their freedoms under the GPL to repost the archive publicly, such as this one here.
(Beware: they're using Git LFS for that, so it requires a few steps to get to the actual files.)
The Linux kernel changes alone are extensive:
Code: Select all
$ zstdcat linux-5.6.3.patch.zst | diffstat
…
2129 files changed, 719225 insertions(+), 6425 deletions(-)
Fun weekend project: find out which is easier, to integrate 17k changes into 719k changes, or vice versa. :)
Re: not strictly related to v7.5beta
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.
A lot of the above probably comes from "support for TILE" as it is no longer present in the standard kernel.
Re: not strictly related to v7.5beta
The difficulty does not dpeend (much) on number of inserted lines
Programmer here: yes, it does. Source: my RSI. :)
But okay, we can add diffstat's -m option to get that answer. It tells us there are 4095 hunks in the 5.6.3 patch file and 4953 hunks between Linux kernel 5.6.3 and 5.6.19. It's a hell of a lot of work no matter how you try and slice-and-dice the data.
Let's steel-man the argument: we've got a developer who's able to read, understand, vet, apply, and test each hunk in one minute on average. That's roughly 2 weeks of work, and it's only that low if none of the changes conflict or create other new work. I do believe we can all think of other things we'd rather MikroTik's developers do with two weeks of dedicated time than bumping a kernel version number.
Re: not strictly related to v7.5beta
Perhaps you were assuming automated patch application. We can try that, too:
That's 28 cases where a human will have to go in and find out why the automated tool couldn't figure out how to apply the patch, despite being given the "--batch" option, which gives it a lot of freedom to shoehorn the patch hunks in.
What that command's output doesn't tell you is how many of the ones that did apply cleanly are appropriate atop this new base. Only building and then regression-testing them on real hardware will tell you that.
I also tried the above command atop kernel 5.10.135, the latest long-term stable version in that line. The failure count rises to 479.
EDIT: The initial version of this experiment used "patch -f", which resulted in two orders of magnitude more failures for the 5.6.19 case. ("Only" one order for 5.10.135.) I'm not certain "--batch" is doing the right thing, but I'm optimistic that it's fixing simple things that "-f" was intolerant of.
Code: Select all
$ cd ~/src/linux/kernel
$ git reset --hard v5.6.19
$ zstdcat ../routeros-7-source/linux-5.6.3.patch.zst |
patch -p1 --batch |
grep -c FAILED
28
That's 28 cases where a human will have to go in and find out why the automated tool couldn't figure out how to apply the patch, despite being given the "--batch" option, which gives it a lot of freedom to shoehorn the patch hunks in.
What that command's output doesn't tell you is how many of the ones that did apply cleanly are appropriate atop this new base. Only building and then regression-testing them on real hardware will tell you that.
I also tried the above command atop kernel 5.10.135, the latest long-term stable version in that line. The failure count rises to 479.
EDIT: The initial version of this experiment used "patch -f", which resulted in two orders of magnitude more failures for the 5.6.19 case. ("Only" one order for 5.10.135.) I'm not certain "--batch" is doing the right thing, but I'm optimistic that it's fixing simple things that "-f" was intolerant of.
Re: not strictly related to v7.5beta
Hey, I already wrote it will probably be a lot of 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)
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)
Re: not strictly related to v7.5beta
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.
Who is online
Users browsing this forum: vortex and 5 guests