It looks like a minor release with a couple of quick fixes. Still hoping for major work on e.g. BGP to be finished.nice!
This happens every time so shortly after the release announcement. It probably is some caching/synchronization issue. Wait some time and it will be correct.I would say the lack of release notes being fteched via internal tool is a cosmetic bug, but surely some would pick up rocks and sticks to attack me...
I‘d guess we’ll see it again in 7.3When will container support be added?
Don't we all. But I like this "release early and release frequently" way: much better than a giant beta each two months. Let's hope they keep it this way from now on.It looks like a minor release with a couple of quick fixes. Still hoping for major work on e.g. BGP to be finished.
Of course I like it that fixes for problems that were blocking for some people are released in such an intermediate version. In fact I wish that v7 is made feature complete and reasonable stable ASAP so it can replace v6 in the field. This set of fixes at least concentrates on actual problems and not on new subsystems.Don't we all. But I like this "release early and release frequently" way: much better than a giant beta each two months. Let's hope they keep it this way from now on.It looks like a minor release with a couple of quick fixes. Still hoping for major work on e.g. BGP to be finished.
IPv6 L3HW is currently in development. However, it is not going to be included in v7.2.Hello,
Any plans to add IPv6 support for l3hw?
On the HAP-Lite (and HAP-Mini) it is best to install the 6.47.9 long-term version and not upgrade any further. Later versions include "fragattack fixes" that kill the performance.7.1.5 and 7.2rc1-6 cause 100% CPU usage and reboots by OOM on the HAP-Lite
It was just to show that in 7.x series MT has change from posting many beta version of the software to posting many RC version.What is the problem that you are reporting with this specific 7.2rc6 and what does it have to do with 6.4x versions?
It was just to show that in 7.x series MT has change from posting many beta version of the software to posting many RC version.What is the problem that you are reporting with this specific 7.2rc6 and what does it have to do with 6.4x versions?
In what configuration?7.1.5 and 7.2rc1-6 cause 100% CPU usage and reboots by OOM on the HAP-Lite
CPU not running at default frequency.which one of all that is an issue?
Still they call it:”The ultimate heavy-duty home lab router”I agree partitioning is important when testing! Fortunately it works on my 4011 but I agree it should work on all devices with sufficient storage.
(I would even like to see it added to CHR)
Can confirm this 2 problems, but already with upgrade to 7.2.RC4RB5009 some issues I picked up after upgrading from v7.2rc5 -> v7.2rc6 (happened on a few of our devices)
- info logging to memory topic disappeared after upgrade -> needed to recreate it
- DHCP Server static leases - some of them disappeared/didn't come across with the upgrade -> needed to recreate them
"Done" is the status of support ticket, not the issue.How come SUP-59224 has been closed while nothing as been done on that front?
Can we specify the direction of the Cake queue please so that we start testing and managing the bandwidth properly. I imagine we will find bugs so now should be the time to implement it no?
Could you provide us with support output file after the incident?RB5009 some issues I picked up after upgrading from v7.2rc5 -> v7.2rc6 (happened on a few of our devices)
- info logging to memory topic disappeared after upgrade -> needed to recreate it
- DHCP Server static leases - some of them disappeared/didn't come across with the upgrade -> needed to recreate them
Is this a new record? two releases in under 5 hours?What's new in 7.2rc7 (2022-Mar-30 15:21):
*) route - allow OSPF and RIP redistributed routes to be matched by routing filters;
No, there have been fix releases quicker than that...Is this a new record? two releases in under 5 hours?
From my long list of release, there has not been a faster public release (4:25) from 6.47 and up (including beta). Have not looked at releases before 6.47. But I may have missed some...No, there have been fix releases quicker than that...
You should not be shocked, since this is just a test version and should not be used in production.but it was a little shocking moment as the PING didn´t came back.....
Don´t worry, it was in a test environment and it was fixed within minutes. It was just to inform you and others (MT?) about a possible problem.You should not be shocked, since this is just a test version and should not be used in production.but it was a little shocking moment as the PING didn´t came back.....
It looks a bit like the "on reboot (or upgrade), part of the configuration is lost" issue of v7, for which we (outsiders) do not know if it is a generic v7 problem or if it affects just specific parts of the configuration.Don´t worry, it was in a test environment and it was fixed within minutes. It was just to inform you and others (MT?) about a possible problem.
You´re right, I saw the same behavior in other releases as well (even pre ROS7). For me it looks like parts of the config are not written to flash, but still exist in RAM (running config), so they are visible during runtime.It looks a bit like the "on reboot (or upgrade), part of the configuration is lost" issue of v7, for which we (outsiders) do not know if it is a generic v7 problem or if it affects just specific parts of the configuration.Don´t worry, it was in a test environment and it was fixed within minutes. It was just to inform you and others (MT?) about a possible problem.
I have seen it myself for "ipsec identities" (which was mentioned in rc5 to be fixed), "routing tables" (which was claimed to be fixed but I still saw parts of it), and I have seen others claim it for bridges (what you saw) and other config items.
It may be that when it is fixed in some version, you still encounter it on upgrade to that version because it was already lost in the version before that, before the reboot. Who knows.
I´ve tried in the last weeks several ROS versions (6.48.6, 6.49.5, 7.1.5, 7.2RC4 and 5) and every time I´ve reconfigured the devices from scratch with copy&paste the config via terminalFor completeness, already tried starting from clean configuration on such a device, configure it again and then reboot ?
To rule out there is no impact from prior undetected problems...
Which doesn't mean it doesn't need to be solved. Those devices have to be able to be upgraded on an existing config.
Either that, or the config file on disk is something like a database with transactions, and they sometimes forget to COMMIT changes that are made.For me it looks like parts of the config are not written to flash, but still exist in RAM (running config), so they are visible during runtime.
After a reboot the non-permant config changes are lost. But "why" can only be answered by MT....
Well, this post has nothing to do with the topic, but Hotspot is based on NAT and since RouterOS does not support NAT for IPv6, it is not possible at the moment.Will the hotspot feature work in ipv6?
Thanks in advance.
VZ
Looks like issues are resolved, can't recreate it in v7.2rc7Could you provide us with support output file after the incident?RB5009 some issues I picked up after upgrading from v7.2rc5 -> v7.2rc6 (happened on a few of our devices)
- info logging to memory topic disappeared after upgrade -> needed to recreate it
- DHCP Server static leases - some of them disappeared/didn't come across with the upgrade -> needed to recreate them
Um...Well, this post has nothing to do with the topic, but Hotspot is based on NAT and since RouterOS does not support NAT for IPv6, it is not possible at the moment.Will the hotspot feature work in ipv6?
Thanks in advance.
VZ
/interface ovpn-server server
set auth=sha1,md5
What's new in 7.2rc6 (2022-Mar-30 10:56):
*) lte - improved stability when modem disappears during firmware upgrade;
[brg3466@LtAP] > /interface/lte/firmware-upgrade lte1 upgrade=yes
status: checking
[brg3466@LtAP] >
When they make a change to a default setting in a new version, and you upgrade a device to that new version, the device retains the old default to avoid potentially causing issues. Therefore it begins to show that setting in the config export after upgrading to the version where the default setting has now changed from what it was before, since now it does not match the current default. That is probably what is happening here.I don't use OpenVPN and never have, so there are no old "echoes" of OpenVPN configuration for it to trigger off. Shouldn't /export suppress that?
When they make a change to a default setting in a new version, and you upgrade a device to that new version, the device retains the old default to avoid potentially causing issues. Therefore it begins to show that setting in the config export after upgrading to the version where the default setting has now changed from what it was before, since now it does not match the current default. That is probably what is happening here.I don't use OpenVPN and never have, so there are no old "echoes" of OpenVPN configuration for it to trigger off. Shouldn't /export suppress that?
Hello good sir. Is it at all possible we can get more information on L3HW development plans?
IPv6 L3HW is currently in development. However, it is not going to be included in v7.2.
When they make a change to a default setting in a new version...
Very probably indeed. I've never used OVPN either. A 6.49.3 device shows auth property set to "sha1,md5" while 7.2rc5 (netinstalled with that version) has it set to "sha1,md5,sha256,sha512".
Speaking about unwanted configuration in export... A lot of my systems have a default bgp template in configuration.
Is there any way to set parameters to make it disappear? I have not been successful to date.
Export shows the difference between built-in configuration and your configuration. Since built-in configuration now has aextra auth algorithms, then export shows that you use only these two. If you would reset your configuration now, then you would have four auth algorithms set on your server.This latest RC adds this bit of noise to the /export output:
Code: Select all/interface ovpn-server server set auth=sha1,md5
I don't use OpenVPN and never have, so there are no old "echoes" of OpenVPN configuration for it to trigger off. Shouldn't /export suppress that?
@strodsExport shows the difference between built-in configuration and your configuration. Since built-in configuration now has aextra auth algorithms, then export shows that you use only these two. If you would reset your configuration now, then you would have four auth algorithms set on your server.
I still use `use-network-apn=yes`. But export does not show anything related to `interface/lte/apn`. But from your statement, it should at least show something like `interface lte apn [ find default=yes ] use-network-apn=yes`. But it is not there.*) lte - made "no" the default value for "use-network-apn" parameter;
Confirmed, it's missing from export.So either buggy or wrong theory.
/interface lte apn
set [ find default=yes ] apn=free default-route-distance=5 ip-type=ipv4 name=FRFree
[xyz@MTSXTLte] /interface/lte/apn>
/interface lte apn export show-sensitive
/interface lte apn export verbose
/interface lte apn export terse
[xyz@MTSXTLte] /interface/lte/apn> export
# apr/01/2022 14:36:56 by RouterOS 7.2rc7
# software id = WZHT-RPE1
#
# model = RBSXTR
# serial number = <something>
/interface lte apn
set [ find default=yes ] apn=free default-route-distance=5 ip-type=ipv4 name=FRFree
add apn=mworld.be default-route-distance=5 ip-type=ipv4 name=BEOrange use-network-apn=yes
[xyz@MTSXTLte] /interface/lte/apn>
[admin@RouterOS] /interface/lte> export verbose # jan/02/1970 00:10:05 by RouterOS 7.2rc7 # software id = S8SE-P15J # # model = RB911G-5HPacD # serial number = 95F00D84B093 /interface lte apn set [ find default=yes ] add-default-route=yes apn=internet authentication=none \ default-route-distance=2 ip-type=auto name=default use-network-apn=yes \ use-peer-dns=yes /interface lte settings set firmware-path=firmware mode=auto [admin@RouterOS] /interface/lte>>>> use-network-apn=yes <<<
... and don't get me started on RFC 2549 compatibility. ;-)I've just discovered that this release COMPLETELY FAILS in compatibility tests with RFC 1149. Time to sell all my MikroTik gear and go buy Uni-TP stuff instead.
What, no RFC 6217 either?!... and don't get me started on RFC 2549 compatibility. ;-)I've just discovered that this release COMPLETELY FAILS in compatibility tests with RFC 1149. Time to sell all my MikroTik gear and go buy Uni-TP stuff instead.
Upgrade done on two CRS326-24G-2S+ done (ROS and FW) from 7.2RC5 to 7.2RC7, one of it lost the "bridge" after FW-upgrade and reboot.
Restore of the backup fixed it, but it was a little shocking moment as the PING didn´t came back.....
The REAL problem is RFC 7168: this is the one we should worry about!
Good to know.The REAL problem is RFC 7168: this is the one we should worry about!
I tested it here and it conforms to the protocol perfectly. It just returns a 418 is all.
*) lte - made "no" the default value for "use-network-apn" parameter;Confirmed, it's missing from export.So either buggy or wrong theory.
.Code: Select all/interface lte apn set [ find default=yes ] apn=free default-route-distance=5 ip-type=ipv4 name=FRFree [xyz@MTSXTLte] /interface/lte/apn>
2022-04-01_14-23-03.jpg
/tool graphing
set page-refresh=300 store-every=5min
/tool graphing resource
add allow-address=0.0.0.0/0 disabled=no store-on-disk=yes
Please create a support ticket and send us the supout file from your device.Sierra Modems EM74XX are broken in this release, wont detect at all. Works in 7.1.5 and 7.2rc2
I’m also seeing a memory leak.There seems to be a memory leak somewhere in v7.2rc7:
weekly.gif
monthly.gif