v7.1 is released!

really?
A few months on the RC version and now on 7.1. No problem. Problem is in configuration.

[admin@hEX S] > caps-man/radio/print detail 
Flags: L - local; P - provisioned 
 0  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="cAP ac - kuchyn" interface=c2-cAP ac - kuchyn-1 
 1  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="cAP ac - kuchyn" interface=c5-cAP ac - kuchyn-1 
 2  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="cAP ac - obyvak" interface=c2-cAP ac - obyvak-1 
 3  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="cAP ac - obyvak" interface=c5-cAP ac - obyvak-1 
 4  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="hAP lite" interface=c2-hAP lite-1 
 5  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="cAP ac" interface=c2-cAP ac-1 
 6  P radio-mac=XX remote-cap-name="[XX]" remote-cap-identity="cAP ac" interface=c5-cAP ac-1 

[admin@hEX S] > caps-man/remote-cap/print detail 
 0 state="Run" name="[XX]" radios=2 address=x.x.x.x/50930 board="RBcAPGi-5acD2nD" version="7.1" identity="cAP ac - kuchyn" 
 1 state="Run" name="[XX]" radios=2 address=x.x.x.x/45591 board="RBcAPGi-5acD2nD" version="7.1" identity="cAP ac - obyvak" 
 2 state="Run" name="[XX]" radios=1 address=x.x.x.x/47335 board="RB941-2nD" version="6.49" identity="hAP lite" 
 3 state="Run" name="[XX]" radios=2 address=x.x.x.x/38077 board="RBcAPGi-5acD2nD" version="6.49" identity="cAP ac"

This is caused by the setting of “local address” in the connection, where in v6 an interface name was allowed and now it requires an IP address.
In v7.1 it is claimed to be fixed, but for me it still does not work correctly on interface that aren’t always up (tunnels).

I agree with you that there are still lots of problem, especially in BGP. It’s logging sucks. Some features do not work. The overview of
its connection state is incomplete and partially not working.
Not ready for prime-time!

Still I am running it on my home router to keep track of problems and report them here. I hope it results in improvements.

I think that’s a thing of the past. Remember that RoS 7.0.x moved from kernel 5.x (I think it was 5.3) to 5.6? Things are much easier now - I think Mikrotik got rid of 90%* of the inhouse kernel patches.

  • 95% of the cited statistics are made up on the spot.

Mikrotik can outsource the work on the kernel and they focus on theirs (Mikrotik) part of the product. Somebody else can work on the kernel, so Mikrotik will have more resources to work with.
The new kernel had useful features but Mkt stuck with the old one, so their products couldn’t have the features which customers wanted.
Too much time Mkt spends on backporting bug fixes to an old kernel. By the time a new Mkt OS is published, Mkt has to invest a LOT of time into adapting to the newer kernel.From one smaller kernel release to the next are very few changes - or even none for networking. But in major releases in several years of development of the kernel, Mkt has to put in a lot of unnecessary time to align their software to newer kernel.
To whom Mkt can outsource work on kernel? Perhaps Linux kernel developers? Don’t waste time on backport and caching up. Invest that time to develop Mkt solutions.

I would love to hear Mkt’s reply on this.

No, linux was upgraded from 3.3 to 5.6…

It worked for 12 hours flawless, and all at a sudden it crashes. This is all done with a clean factory reset and build op from scratch config. I can see it’s the CAPsMAN itself, crashing.

Like PE1CHL, I’m keeping v7 on my home router, just to test, and hopefully improve over time.

The changes of the kernel are the core business of MikroTik.
(ok there is the configuration interface as well, but for the actual features it is like that)

Yes it is likely CAPsMAN because I have a RB4011 and a hAP ac2 both running 7.1 without CAPsMAN and I have not seen a single WiFi problem.

kernel 5.6 never was a LTS kernel. These versions between LTS go EOL instantly when the next version goes public. So 5.6 was EOL on the day 5.7 launched. I won’t put too much focus on that detail. but not receiving security updates may be a critical thing.

They probably chose to upgrade to 5.6, because it is the first kernel to include wireguard directly. But I agree, they should raise to 5.10 LTS - that has support till end of 2026!

I wonder if the wireguard sources are up to date or in the state they were at 5.6.3

We always keep internal code up to date, the kernel version is mostly irrelevant

OK,

for the moment i'm back to 6.49.2 on the ccr1009 and everthing runs fine ....

Hello,
i've got 2 CHR ( v7.1 rc7 ) in 2 different Datacenters ... My ccr1009 ( v6.49.2 ) at home connect via l2tp / eoip tunnel to the devices .... on both chr, wireguard is active for wan access

today i upgraded my ccr and the eoip tunnel is not working :frowning:

l2tp is active / PH2 state establised / eoip ipsec sa installed normally ...
i can ping l2tp addresses, but the eoip tunnel is not running ( it shows running for only around 30s, but no ping possible )

where can i find the prob ? is it ipsec or bridge problem ? any ideas ?

can i get back to 6.49 ? from packages not ... only show 7.1

regards
christian

… or Linux 5.15, which is a LTS release as well and supported till October 2023 at least.

I think a yearly bump for the next LTS release would make sense in future. IMHO that would be a good compromise between constant change with recent linux release and “ancient” linux that requires a release like RouterOS v7 with its huge changes.

Current situation; switched off CAPsMAN and configured Wireless by hand, BGP somewhat working, except BGP-redistribution towards a Fortigate (Linux+Bird and a CHR-VM works fine), BFD switched off.

WiFi is stable without the CAPsMAN, but the funny part; it worked with CAPsMAN, and all of sudden it’s in a flapping state. Even turning off CAPsMAN, reboot, and turning it on delayed, doesn’t work.

to Mikrotik: is it possible to create light main packages to switch from extra v6 packages to v6 / v7 main package? They could only contain the system, dhcp, system, wireless packages. hAP ac2, disk lite5 ac etc. cannot be upgraded to main package remotely due to “system, error not enough space for upgrade”

Due to a bug you cannot upgrade from separate packages to single package on some devices. This is not really a lack of space.
You need to netinstall either the v6 combined package or the v7 package and then load your backup.

Not exactly. Looking through the changelog, we have:
https://mikrotik.com/download/changelogs/development-release-tree

7.0beta3 → Based on Kernel 4.14.131
7.0beta7 → system kernel has been updated to version 5.6.3;

So, it is possible (now) to upgrade the kernel on a timely manner - these versions were about 8 months apart.

possible yes. But MT should put that to backlog for now.

kalamaja,
look below …

Had the same problem but then in firewall. I had double entries in the table and as soon I changed one entry and save Winbox crashed.

Best sent a e-mail to support@mikrotik.com or if you have already a account create a support request. You may refer to SUP-60072 that was resolved earlier.