What router specific features from 5.15 kernel do you expect to have that are not in 5.6?
@pe1chl @anav, thanks for your replies. I appreciate the discussion
if it really is easier for MT to increment kernel version going forward then I’m 100% for it. in a way, it could be viewed as “outsourcing” because the kernel maintainers will be doing some of the work that MT had to do previously with 6.x for security fixes and etc
honestly, I don’t think anyone except MT knows the full extent of what they do to modify the kernel.
I read many different things and it would be nice if MT give some direction on this? “Device has enough free storage space for all RouterOS packages to be downloaded.”, is a bit uninformative.
https://forum.mikrotik.com/search.php?keywords=calculating&t=180831&sf=msgonly
That statement by normis doesn’t make much sense … e.g. the old ntp package (which was part of extra packages) did add some userland apps to the basic install and without those files, disk usage was slightly lower (and that was the whole point of de-bundling of ROS install). If one used the bundle and disabled some package, then what that did was disable UI of that functionality and disable the functionality. With v7 where most packages are part of “bundle”, it is not possible to un-occupy disk space. Now one doesn’t disable packages, one only disables functionality (but essentially that’s the same thing). And by disabling functionality, the resources saved are RAM and (some) CPU cycles.
So previously by not installing ntp from extra packages one saved some precious disk space, some RAM and some CPU cycles. Now if one disables NTP functionality, one saves some RAM and some CPU cycles, but the precious disk space is gone. And disk space, on some devices, is the single most important bottleneck (e.g. hAP ac2) which already prevents us from getting e.g. wifiwave2 drivers, so this aspect should not be easily dismissed.
Possibly none, except from some small bug fixes. But loosely following kernel versions with ROS v7 would make sure that when kernel does offer some crucial functionality, the amount of work needed to be done to fit in ROS will be kept at minimum (because most will be done regularly).
Just as an example: if MT decided to go beyond kernel 3.5.x years ago, then all the heavy utility and UI changes would be done years ago and e.g. wireguard would have been available on mikrotik devices a few years ago.
Similarly for some other features we are waiting for such a long time. So basically saving some developers’ months here and there means they have to be spent later … when things are highly urgent and possibly hurting business. I guess sometimes it’s extremely hard to convince bosses and bean counters that penny spent on (on time) development is heaps of bucks saved/earned in due time.
Lets say new protocol “wirelessguard” is added in kernel 6.x years lateer, it doesn’t make any difference if we have 5.6 or 5.15 now.
That is correct. But what would make a difference is when MikroTik could limit the number of kernel patches to the absolute minimum, or to
have a streamlined internal procedure to migrate to a new kernel without having to do a lot of manual work again.
When the kernel is updated e.g. twice per year, it does not get so much behind and there is both less chance that people start asking for features “that have been in Linux for a long time” and also it will be less work to make the patches again.
This also applies when new hardware arrives that would be interesting to incorporate in a new device (some new WiFi chip for a new and faster protocol, some new technology like LoRa) and the drivers for it expect an actual version Linux kernel.
No, what I’m saying is that if you upgrade kernel version to some suitably new LTS kernel with every new ROS minor version (e.g. upgrade from 5.6 to 5.15 with 7.2, upgrade to 5.28 with 7.3, upgrade to 5.42 with 7.4 and upgrade to 6.4 with ROS 7.5 … and do the minor work needed for every new kernel to fit ROS, then wirelessguard would be easily implemented in ROS 7.6 which would require minimum work to adapt for kernel 6.12). If you keep at kernel 5.10 until ROS 7.5, then amount of work needed to be done to fit kernel 6.12 would be much higher, and some bean counter might decide to postpone introduction of wirelessguard to some uncertain future (because there wouldn’t be demand high enough to pay the necessary development costs). And things would spiral down the same path they did years ago when MT decided to stick with last kernel supporting the former routing engine.
I’m pretty sure sometimes it takes longer time (and is thus more expensive) to back-port some security or bug fix to older kernel than to perform minor tweaks on current mainstream kernel (which includes the very same fix). And the added functionality in newer mainstream kernel is just a bonus (from MT’s point of view), but if MT can capitalize that bonus, it means both additional revenue for MT and happiness for users.
Update to my previous report. My browser probably kept cache of previous page version.
It still doesn’t work properly though, NTP client menu in WebFig doesn’t show configured nor active servers.
Actual configuration:
@mrz, you’ve prompted me to look through the kernel changelog, I referenced this page: https://kernelnewbies.org/LinuxChanges
granted, I have only looked through the prominent features, network, and security sections of each release, and I am not smart enough to understand lot of what they mention. but I’ll list the things that look interesting to me here…
I’ll be honest, I don’t completely understand the majority of the kernel changelogs, but I’ve copied the parts that I think others here will be interested in.
please, discuss.
in 5.7
Networking
Improve bind(addr, 0) behaviour. Linux used to fail to bind sockets to ephemeral ports when all of the ports were exhausted even if all sockets had SO_REUSEADDR enabled. In this case, it still is possible to connect to the different remote hosts. This release adds the net.ipv4.ip_autobind_reuse, which allows to bind SO_REUSEADDR enabled sockets to the same (addr, port) when set to 1 and all ephemeral
UDP: Bare UDP L3 Encapsulation Module. The Bareudp tunnel module provides a generic L3 encapsulation tunnelling support for tunnelling different L3 protocols like MPLS, IP, NSH etc. inside a UDP tunnel
Packet schedulers
Make FIFO Qdisc offloadableIntroduce connection tracking hardware offload
Add software offload of connections with an established ct state using the NF flow table offload infrastructure, so once such flows are offloaded, they will not pass through conntrack again, and instead act_ct will restore the conntrack info metadata on the skb to the state it had on the offload event - established
Allow user to specify the type of hardware stats for the added TC action: immediate, delayed, or disabled
RED qdisc: Introduce an ECN nodrop mode
Enables tc classification to start from a specified chain. TC multi chain configuration can cause offloaded tc chains to miss in hardware after jumping to some chain, in such cases the software should continue from the chain that was missed in hardware
Expose HW stats types per action used by drivers
Implement callback used for adding HW counters to the SW ones for pedit and skbedit actions
WiFi
Add encapsulation offloading support
…
Add support for Beacon protection
in 5.8
Better behavior in memory thrashing situations
(FEATURED) IPv6: add MPLS support
IPv6: Implement the upcoming rev of RFC4941 (IPv6 temporary addresses)
IPv6: support RFC 6069 (TCP-LD)
Add IPv6 encapsulation support for ESP over UDP and TCP
802.11
Unprotected Beacon frame RX indicationInitial definitions for S1G (802.11ah)
Support bigger kek/kck key length
Support multicast RX registration
Allow SA-QUERY processing in userspace
Implement Operating Mode Notification extended NSS support
Support control port TX status reporting
Add support to configure TID specific Tx rate configuration
Packet scheduler
flow_dissector, cls_flower: Add support for multiple MPLS Label Stack Entries
sch_fq: add horizon attribute
in 5.9
icmp4/6: support RFC 4884
Add stream gate action policing in IEEE802.1Qci (Per-Stream Filtering and Policing) software support and hardware offload support in tc flower
Introduce qevents. Those are attach points for TC blocks, where filters can be put that are executed as the packet hits well-defined points in the qdisc algorithms. The attached blocks can be shared, in a manner similar to clsact ingress and egress blocks, arbitrary classifiers with arbitrary actions can be put on them, etc
sch_cake: add RFC 8622 LE PHB support to CAKE diffserv handling
Add support for Parallel Redundancy Protocol (PRP) - a network protocol standard for Ethernet that provides seamless failover against failure of any network component - in the Linux HSR driver as defined in IEC-62439-3
Support ipip and ipv6 tunnels in vti and xfrmi
in 5.10 (LTS)
Support 6 GHz scanning
Add support for WPA/WPA2-PSK 4-way handshake and SAE offload in AP mode
packet scheduler: Add the necessary TC actions for supporting layer 2 MPLS VPNs (VPLS)
in 5.11
Faster memory leak debugging in ARM
IPv6: Add support for the SRv6 End.DT4 and End.DT6 (VRF mode) behavior. The SRv6 End.DT4 behavior is used to implement multi-tenant IPv4 L3 VPNs. It decapsulates the received packets and performs IPv4 routing lookup in the routing table of the tenant. The SRv6 End.DT4 Linux implementation leverages a VRF device in order to force the routing lookup into the associated routing table. The SRv6 End.DT4 behavior is defined in the SRv6 Network Programming
IP: Add an IPv6/IPv4 route encapsulation attribute to the result of netlink RTM_GETROUTE requests
macvlan: Support for high multicast packet rate
TLS: Add CHACHA20-POLY1305 cipher to Kernel TLS
Add support to calculate and report 4096-QAM HE rates
Remove WDS mode
in 5.12
IPv6: Allow user to set metric on default route learned via Router Advertisement
UDP: allow forwarding of plain (non-fraglisted) UDP GRO packets
RFC 6056 induced changes
IPv4-mapped IPv6 addressing for subflows
Add Extended MCS Phyrate Conversion Support on 60GHz
Add VHT rate entries for MCS-10 and MCS-11
in 5.13
Add support for x509 certs with NIST P384/256/192 keys
UDP: improve UDP L4 - either ‘forward’ or ‘frag_list’ - co-existence with UDP tunnel GRO, allowing the first to take place correctly even for encapsulated UDP traffic
Better support for sandwiched LAGs with bridge and DSA
ICMP: Add support for RFC 8335 PROBE messages, a specialized ICMP message that makes use of the ICMP Extension Structure outlined in RFC 4884. It allows querying specific interfaces on a node and requiring bidirectional connectivity between the probing and probed interfaces
macvlan: Add nodst option to macvlan type source to skip destination MACVLAN processing if any matching source MACVLAN device has the option set
in 5.14
Core Scheduling, for safe hyperthreading
Support hidden AP discovery over 6GHz band
Allow bypass of the lockless qdisc to improving performance (for pktgen: +23% with one thread, +44% with 2 threads)
sctp: implement RFC8899: Packetization Layer Path MTU Discovery for SCTP transport
in 5.15 (LTS)
ksmbd, a in-kernel SMB 3 server
Support for asymmetric scheduling affinity
XDP bonding support
Some improvements to generic XDP mode to brings it closer to native XDP
Update your wAP ac to version 7.1.
I apply version 7.1 (stable), but the router shows (testing). It is not clear why ..
The download is the same as it was but there are problems with the upload. It had to be around 350Mbit whatever it was before the upgrade! Downgrade is not possible. I am very disappointed with the new version! I will not upgrade any equipment on v7.1.
When you run Speedtest, the router disconnects for about 30 seconds after the test. It’s not normal. The router is located in the internal network Bridge mode
Same on my wAP AC and hAP AC. You can downgrade - just copy firmware file on router’s disk (“Files” menu) and select “Downgrade” option in “System / Packages”.
looks like kernel updates are not so unimportant as one could think!!!
I’d say every kernel release matters this way or another. Most of changes are invisible because they target small things, obscure bugs, performance enhancements … and those changes matter regardless what kind of duties are performed by device running kernel. Some things are more prominent, such as addition of new functionality.
As I already wrote: it’s bad decission not to upgrade kernel version when there’s opportunity just because there’s no apparent reason to upgrade.
WildRat,
Thank you very much !!! I managed to downgrade. Now everything is working normally again as it should be.
If i can just borrow that picture from another user… In version 6, while adding Route you had a drop down menu to select Gateway. Now in version 7 you must enter it manualy. Is this considered normal behaviour?
I don’t know if this is a bug. But if you disable just IPv6>Settings, you may want/need to disable IPv6 ND as well – that seem unaffected by the first top level one.
/ipv6/settings/set disable-ipv6=yes
/ipv6/nd/set [find default] disabled=yes
Otherwise, it does seem to try but fail at discovery:
12:16:03 radvd,debug skip Router Advertisement sending on bridge1: no prefixes to send
12:16:28 radvd,debug skip Router Advertisement sending on zerotier1: no prefixes to send
It don’t know if more has to be disabled to accomplish what remove the package did in V6, but those two seem to work – @truefriendcz, I too like the similar ability to just remove/disable the entire codebases I’m not using if possible – in fairness, that may not have been possible with all the routing changes in V7 (likely other reasons, like space optimization).
It’s a fair question if “Disable IPv6”, includes discovery or just routing… But not as simple/clear as “Disable Package” as in V6.
Data structures for health changed with RouterOS v7… Try this:
:put [ /system/health/get [ find where name="temperature" ] value ]
How about NO. 
I actually trust Mikrotik’s decision making when it comes to the kernel. The quality of the device driver is likely a way more important factor than kernel version. And, this is what Mikrotik is doing for you over say OpenWRT/Linux – making sure hardware drivers works with the kernel they’re using (and in some cases using non-OSS drivers ones if better). Some drivers prefer older kernels as well. What they do is curate all this mess Linux things into one pretty rational config format. If you want involvement in what kernel your devices is using, Mikrotik may not be right for you ;).
The likely bigger problem, and delay for V7, is the hardware driver model changes NOT the kernel per se. Since the driver model ain’t changing significantly in 5.x, I’d imagine Mikrotik can patch any change from any kernel – if was needed to fix a problem. Otherwise, pulling in the kernel “just because” means a lot more testing on the backend since more would have changed. All of this is a tricky balance.
Now their release management decision-making, from a customer POV, gets a poorer assessment.
Note that when you have downgraded this way, you cannot upgrade to version 7.x anymore in the future, at least not until the bug is fixed that conversion of configuration is performed only once.
I.e. when in the future you update to version 7 it will use the converted configuration that you made this time.
To work around that, you will have to export the configuration under v6, start from zero with a netinstall of v6 and no configuration, import the exported configuration and only then you can attempt the upgrade again.