MikroTik

Posted: **Tue Jun 07, 2022 5:29 pm**

RouterOS version 7.4beta2 has been released the "v7 testing" channel!

Before an upgrade:
1) Remember to make backup/export files before an upgrade and save them on another storage device;
2) Make sure the device will not lose power during the upgrade process;
3) Device has enough free storage space for all RouterOS packages to be downloaded.

What's new in 7.4beta2 (2022-Jun-07 12:08)

*) api - fixed comma encoding within URL when using the ".proplist" argument;
*) bridge - properly process IPsec decapsulated packets through the firewall when the "use-ip-firewall" option is enabled;
*) capsman - require a unique name for configuration and configuration pre-sets;
*) cloud - print critical log message when system clock gets synchronised;
*) console - added ":retry" command;
*) console - fixed situation when print output was not consistent;
*) dns - convert the domain name to lowercase before matching regex;
*) e-mail - added VRF support (CLI only);
*) filesystem - fixed repartition on RB5009 series devices;
*) firewall - added "srcnat" and "dstnat" flags to IPv6/Firewall/Connection table;
*) firewall - added support for IPv6/Firewall/NAT action=src-nat rules (CLI only);
*) firewall - fixed IPv6 NAT functionality when processing GRE traffic on TILE devices;
*) firewall - fixed IPv6/Firewall/RAW functionality;
*) firewall - include "connection-mark", "connection-state", and "packet-mark" when packet logging is enabled;
*) firewall - properly handle interface matcher when VRF interface is specified;
*) hotspot - fixed ARP resolution for clients when address pool is specified on the server;
*) hotspot - fixed Walled Garden entries with action=deny;
*) ipv6 - fixed system stability when adding/removing IPv6 address;
*) ldp - correctly handle AFI selection for usage on dual-stack peers;
*) lte - request connect with the same IP type as in LTE attach status for MBIM;
*) lte - fixed Telit AT interface numbering;
*) lte - improved LTE interface detection for LtAP-2HnD devices;
*) lte - keep MBIM working even if AT channel fails to respond in the initialisation stage;
*) mmips - improved USB device detection after system bootup;
*) mpls - fixed VPLS functionality when PW peer is an immediate neighbor;
*) ovpn - use selected cipher by default when the server does not provide "cipher" option;
*) pimsm - improved system stability when changing configuration;
*) ppp - properly try to use different authentication algorithms when Conf-Rej is received during the LCP phase;
*) quickset - specify the "in-interface-list=WAN" attribute on firewall rules created through "Port Mapping";
*) route - added option to join static IGMP and MLD groups (available in "/routing/gmp" menu, CLI only)
*) route - fixed false route type detection as blackhole;
*) route - provide more detailed information about prefixes when using "discourse" tool;
*) routing - moved "/interface bgp vpls" to "/routing bgp vpls" menu;
*) routing-filter - fixed regexp community matcher;
*) ssh - disable ssh-rsa when strong-crypto=yes and use rsa-sha2-sha256;
*) ssh - implemented "server-sig-algs" extension in order to improve rsa-sha2-sha256 support;
*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;
*) vxlan - allow to specify MAC address manually;
*) webfig - updated WebFig HTML files with the new MikroTik logo and removed Telnet option from index page;
*) webfig - updated link to the WinBox executable;
*) webfig - updated link to the documentation;
*) wifiwave2 - fixed "frequency-scan" functionality (introduced in v7.3);
*) winbox - add a log and log-prefix options to IPv6 firewall NAT and mangle rules;
*) winbox - fixed IP/Route and IPv6/Route OSPF type value;
*) winbox - removed unused "Apply Changes" button from BGP sessions menu;
*) wireguard - fixed system stability when adding/removing WireGuard interface;
*) wireless - fixed possible traffic flooding to WDS clients when using Nv2 and multicast helper;
*) x86 - fixed keep old configuration functionality during x86 setup installation;
*) x86 - improved log warning message on failed downgrade attempt;
*) x86 - removed "hdd-model" information from installation screen;

To upgrade, click "Check for updates" at /system package in your RouterOS configuration interface, or head to our download page: http://www.mikrotik.com/download

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while the router is not working as suspected or after some problem has appeared on the device

Please keep this forum topic strictly related to this particular RouterOS release.

Posted: **Tue Jun 07, 2022 5:45 pm**

hAP Lite took 4 minutes to update from 7.3

Posted: **Tue Jun 07, 2022 5:51 pm**

Interesting that the fix for 328-24P SFP port flopping is to disable a CPU core.

Posted: **Tue Jun 07, 2022 5:54 pm**

" *) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;"

This one may finally resolve my issues with the CRS328 - but I have a question - is this expected to cause any issues re: performance? Was the second core not operational in v6? The stability issues came about with the upgrade from v6 to v7, so curious if the second core was enabled as part of this.

Posted: **Tue Jun 07, 2022 5:58 pm**

" *) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;"

This one may finally resolve my issues with the CRS328 - but I have a question - is this expected to cause any issues re: performance? Was the second core not operational in v6? The stability issues came about with the upgrade from v6 to v7, so curious if the second core was enabled as part of this.

I remember quite clearly that the 2nd CPU core was enabled with an upgrade from v6 to v7. I'm not sure on how much of a performance difference the 2nd CPU core brings, unless you're doing a load of things that switches don't usually do I think it's fairly minimal.

Posted: **Tue Jun 07, 2022 6:21 pm**

Sounds like it might be a nice fix then; perhaps a hardware issue that can’t be resolved hence just disabling the core. I was able to trigger the flaps with NAND activity, so this may be for the best.

Posted: **Tue Jun 07, 2022 6:35 pm**

Hey..It looks like PIMSM is working.. Hoo-Hoo. Kudos Tik !! 😎

Posted: **Tue Jun 07, 2022 6:48 pm**

Mkay guess i'm skipping stable again. YOLO
Ok, so quick question regarding:

*) filesystem - fixed repartition on RB5009 series devices;

Is it normal to see this after upgrade/reboot without touching anything else? ..

/partitions/print 
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE  
0 AR part0  next         RouterOS v7.4beta2 Jun/07/2022 09:08:00  512MiB
1    part1  next         EMPTY                                    512MiB

What if I had more than 512MB on it? 0o

Posted: **Tue Jun 07, 2022 8:51 pm**

Regarding the IPv6 NAT fixes, you missed one:

/ipv6/firewall/nat/add chain=srcnat src-address=fd01::/64 action=netmap to-address=2001:db8::/64
failure: dstnat/redirect/netmap action must be in dstnat/output chains

For IPv4 there can be netmap action in both srcnat and dstnat chains, and ip6tables in Linux also accept NETMAP in both POSTROUTING and PREROUTING.

Posted: **Tue Jun 07, 2022 8:54 pm**

Now with the new beta, please use some time to get the logging more uniform.

Prefix mess: viewtopic.php?t=124291
Timestamp should be in ISO 8601 format, not jun/02/2022
Events that may log more than one line should have the same ID. Example IPSec login. If many users logs inn more or less at same time, it not possible to see what logline belongs to what user.

Posted: **Tue Jun 07, 2022 9:07 pm**

Mkay guess i'm skipping stable again. YOLO
Ok, so quick question regarding:
*) filesystem - fixed repartition on RB5009 series devices;
Is it normal to see this after upgrade/reboot without touching anything else? ..
Code: Select all
/partitions/print 
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE  
0 AR part0  next         RouterOS v7.4beta2 Jun/07/2022 09:08:00  512MiB
1    part1  next         EMPTY                                    512MiB
What if I had more than 512MB on it? 0o

Hi,
this is what mine looks like, so it seems to me normal, except you had a second part configured before update:

[admin@badfast] > /partitions/print 
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE   
0 AR part0  next         RouterOS v7.4beta2 Jun/07/2022 09:08:00  1024MiB
[admin@badfast] /system/routerboard> print
       routerboard: yes
             model: RB5009UG+S+
     serial-number: ECxxxxxxxxxx
     firmware-type: 70x0
  factory-firmware: 7.0.5
  current-firmware: 7.4beta2
  upgrade-firmware: 7.4beta2

Posted: **Tue Jun 07, 2022 9:11 pm**

@Jotne: open a ticket as it's not a version-specific issue.
@woland: tried to partition before, sure, but nothing happened back then, and all the space was still there until now. Someone could've used it ..
I don't know how the partitioning script deals with it
Oh well, if nobody gets hurt, all is fine :)

Posted: **Tue Jun 07, 2022 9:27 pm**

@woland: tried to partition before, sure, but nothing happened back then, and all the space was still there until now. Someone could've used it ..
I don't know how the partitioning script deals with it
Oh well, if nobody gets hurt, all is fine :)

@Znevna: I think it was the partitioning bug, which was corrected. The amount of space shown was probably wrong.

I was able to successfully repartition now.

The RB5009 upgrade from 7.2rcX went smoothly. I don´t see anything obviously wrong here. (Lab deployment only, no 2.5G connections...)

W
Ps. missing the container....

Posted: **Tue Jun 07, 2022 9:36 pm**

"RouterOS WinBox Error — Couldn't make backup - action failed (6)" when doing backup. 7.4beta2 on RBD53G-5HacD2HnD (Chateau).

Posted: **Tue Jun 07, 2022 9:37 pm**

Great, partitioning on RB5009 works finally!
Thanks

Posted: **Tue Jun 07, 2022 9:52 pm**

@Jotne: open a ticket as it's not a version-specific issue.

Have already done some years ago, and was told that they will look at it on a later release.
Posted a new support request. #[SUP-84077]

Posted: **Tue Jun 07, 2022 10:13 pm**

Chateau updated without issue.
Is DNS over TLS supported yet?

Posted: **Wed Jun 08, 2022 12:00 am**

Have already done some years ago, and was told that they will look at it on a later release.Posted a new support request. #[SUP-84077]

Thanks @Jotne, it's a good merit to be stubborn and never give in! :thumbsup:

Posted: **Wed Jun 08, 2022 1:20 am**

Can someone check if this change.
*) wireguard - fixed system stability when adding/removing WireGuard interface;

Means they have addressed the outstanding of issue of having to reboot the client setting or even client device, if the connection to the server gets broken, (either a new IP at the server or the server reboots etc,) and the server endpoint is done via mynetname ddns etc.........

If not, hint, Strods put it on the next beta please! :-)

Posted: **Wed Jun 08, 2022 6:56 am**

When BGP vrf PE-CE issue will be fix?

This is BGP configuration in v6 and v7

v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no

v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no

actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.

PE-99-vrf-capture-1.jpg

PE-99-vrf-capture-2a.jpg

PE-99-vrf-capture-2.jpg

thx

Posted: **Wed Jun 08, 2022 7:03 am**

Chateau updated without issue.
Is DNS over TLS supported yet?

What advantages does DoT have over DoH? If you had to pick one, is that the one you prefer? Why?

Posted: **Wed Jun 08, 2022 7:33 am**

hecatae - Congratulations, that was fast

Znevna - We will re-check this issue with repartitioning.
Sob - We will check what we can do about NAT netmap functionality in ROS.
memelchenkov - Works for us. Can you provide supout file from this device to support@mikrotik.com which would be generated right after you have tried to make a backup?
anav - The particular case which we did manage to reproduce and fix was that router could freeze, go to unusually high CPU usage, or reboot when wireguard interface was being added/removed.

Posted: **Wed Jun 08, 2022 8:50 am**

return container support

Posted: **Wed Jun 08, 2022 8:52 am**

Any idea when we might see better logging for the routing components of v7 ?

Posted: **Wed Jun 08, 2022 8:53 am**

Chateau updated without issue.
Is DNS over TLS supported yet?
What advantages does DoT have over DoH? If you had to pick one, is that the one you prefer? Why?

There is only one big difference. DoH uses https port, so can't block by port. DoT uses a known port, so operators like it, since they can block it.

Posted: **Wed Jun 08, 2022 9:32 am**

memelchenkov - Works for us. Can you provide supout file from this device to support@mikrotik.com which would be generated right after you have tried to make a backup?

SUP-84114 just filed. Thanks!

Posted: **Wed Jun 08, 2022 9:32 am**

Mkay guess i'm skipping stable again. YOLO
Ok, so quick question regarding:
*) filesystem - fixed repartition on RB5009 series devices;
Is it normal to see this after upgrade/reboot without touching anything else? ..
Code: Select all
/partitions/print 
Flags: A - ACTIVE; R - RUNNING
Columns: NAME, FALLBACK-TO, VERSION, SIZE
#    NAME   FALLBACK-TO  VERSION                                  SIZE  
0 AR part0  next         RouterOS v7.4beta2 Jun/07/2022 09:08:00  512MiB
1    part1  next         EMPTY                                    512MiB
What if I had more than 512MB on it? 0o

I noticed it used the configuration i had used to try ( in a previous version in the past ) but didn't work.
It seems it keeps the configuration you created in the past and uses that on upgrading.
In my case it created 4 partitions as i tried to create before.

Posted: **Wed Jun 08, 2022 9:40 am**

Yeah I thought so too.
Scary a little, isn't it?

Posted: **Wed Jun 08, 2022 10:47 am**

return container support

soon! just some minor things left.

Posted: **Wed Jun 08, 2022 1:00 pm**

disabling default bgp template and enabling it result to invalid flag, workaround remove the default template and create again from scratch!

p.s i don't have issues with container support in MT, but first prioritized the core routing features of v7 specially BGP and MPLS support and general stability over all of the ROS v7, there were a lot of people buying high end CCR with V7 only OS as an ISP core router and suffering set back in deploying it in production from mild to extreme case, we have a few people and colleague deploying MT in internet exchange only to be embarrassed and bring other gear in a next few weeks and throw a towel as a result.

@ MT Please take this criticism carefully we really loved your product you are getting there but please add more resource on your BGP/MPLS programmer and Q&A department

Please if you do have roadmap please published it, people don't necessarily influence the direction of ROS v7 we just want to gauge on where we at and what were are going to do also in the future, we just want a respect for what we deserved

Posted: **Wed Jun 08, 2022 10:03 pm**

soon! just some minor things left.

Yay! I'll take your word for it so maybe already next week? ;-) Joking apart, it's good to know that work is in progress, thank you!

Posted: **Thu Jun 09, 2022 7:13 am**

Another release without full VRF functionality (as attested by posts from buset1974 and loloski above).

I'm perplexed that we're up to a dot-four release, but there still appear to be chunks of L3 VPN functionality missing. These are not bugs; they are things that haven't even been implemented. Specifically, output filters don't work and it's not possible to use the mangle to look up routes in a VRF.

Can MikroTik provide some indication of when this might be addressed?

Posted: **Thu Jun 09, 2022 3:04 pm**

In RB5009 - cannot disable and/or remove DHCP client with "D" flag (not enough permissions). DHCP client is appearing automatically after plug in USB Huawei LTE modem (3372h).
On 7.3 stable release I can remove dhcp client without any permissions issues.

Posted: **Thu Jun 09, 2022 3:09 pm**

It seems that the terminal icon in the web login page is missing… (hap ac3, accessing from iPadOS 15.5/safari)

Posted: **Sat Jun 11, 2022 3:03 pm**

*) webfig - updated WebFig HTML files with the new MikroTik logo and removed Telnet option from index page;

Maybe the user-manager could use some makeovers too?
Would MT care enough to implement the reseller functionality in the user manager?

2022-06-11_16-23-14.jpg

Posted: **Sun Jun 12, 2022 4:48 am**

*) mpls - fixed VPLS functionality when PW peer is an immediate neighbor;

I hoped this would fix the VPLS crash I have been experiencing - alas, it has not. One ping goes through and then one core of my device goes to 100% and it locks up and eventually reboots on its own.

Posted: **Sun Jun 12, 2022 10:00 am**

*) bridge - properly process IPsec decapsulated packets through the firewall when the "use-ip-firewall" option is enabled;

NAT with IPSEC with Use IP Firewall enabled still not working correctly. Connections are freezes. Fortunately, Bridge Filter Marks now works!! So IP Firewall for some (incl. my) cases may be replaced with Bridge Filter. I'm done with IP Firewall but who cares about it, beware.

Posted: **Sun Jun 12, 2022 12:32 pm**

*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;

So ... any more details around this? Is this an interim fix or rather permanent? And how does it affect performance?

Posted: **Sun Jun 12, 2022 10:14 pm**

*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;
So ... any more details around this? Is this an interim fix or rather permanent? And how does it affect performance?

I can say it has "fixed" the port flapping issue I've had since 7.x was released on my CRS328. I've been running 7.4beta2 since June 7, and haven't had a single port flap since. I'd been having port flapping every 5 minutes to a few hours (once I disabled anything that wrote to NAND) prior to this release, on all versions of 7.x. It seemed to be related to NAND operations, in my case, but that may have just been one of the triggers.

My switch isn't doing anything taxing so I can't speak to performance implications, and I do have the same question(s). It seems like a kludge type of fix vs. root cause, but I am extremely happy to have a stable network again after 6+ months of trying to get traction on my support ticket until it was taken seriously.

Posted: **Sun Jun 12, 2022 10:35 pm**

CRS328-24P-4S+ is advertised as having one CPU core, and it had one in v6.

Product code 	CRS328-24P-4S+RM
Architecture 	ARM 32bit
CPU 	98DX3236
CPU core count 	1

It got one extra core enabled for some reason in v7, which probably was not supposed to happen. Don't sweat about it.

Posted: **Sun Jun 12, 2022 10:43 pm**

It got one extra core enabled for some reason in v7, which probably was not supposed to happen.

I'm pretty sure it was supposed to happen, why would SoC designer include two cores if it wasn't?
Can't say if current "solution" is permanent or not, but I wouldn't be too surprised if eventually MT would find the actual culprit for instability and re-enable the second core. But probably this does take time and with current amount of outstanding items for ROS v7 they probably decided to postpone solving this problem.
OTOH I wouldn't be too surprised if the second core remained disabled for next millenium or two ...

Posted: **Sun Jun 12, 2022 10:51 pm**

98DX3336 is Dual Core while 98DX3236 that is used in this switch is single core in all sources I've found on the internet:
Marvell Prestera 98DX3336: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for Campus edge/access with a dual core ARM v7 CPU
Marvell Prestera 98DX3236: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for SMB/SME edge/access with an ARMv7 CPU
armada-xp-98dx3236.dtsi:
https://github.com/torvalds/linux/blob/ ... x3236.dtsi
armada-xp-98dx3336.dtsi adding one extra core:
https://github.com/torvalds/linux/blob/ ... x3336.dtsi
Did you find anything else that suggests two cores in 3236?

Posted: **Mon Jun 13, 2022 12:17 am**

*) mpls - fixed VPLS functionality when PW peer is an immediate neighbor;

I hoped this would fix the VPLS crash I have been experiencing - alas, it has not. One ping goes through and then one core of my device goes to 100% and it locks up and eventually reboots on its own.

Same trouble. mipsbe

Posted: **Mon Jun 13, 2022 12:33 am**

When BGP vrf PE-CE issue will be fix?

This is BGP configuration in v6 and v7

v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no

v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no

actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.

PE-99-vrf-capture-1.jpg
PE-99-vrf-capture-2a.jpg
PE-99-vrf-capture-2.jpg
thx

I have the same issue, it would appear to be an issue with .default-originate=always function if you set to .default-originate=always. if you set to .default-originate=never or .default-originate=if-installed then issue is resolved.

Doesn't help much but shows where the issue is.

Posted: **Mon Jun 13, 2022 9:01 am**

So you don't have any proof that suggests two functional cores in that SoC.

And you don't have anything to suggest there aren't two cores in that SoC.

As to the part of "functional" ... that's debatable ;-)

Posted: **Mon Jun 13, 2022 9:02 am**

I've posted above how current linux kernel treats those two SoCs, that's more than you've put to the table.
And those two lines I've posted can be found browsing marvell.com from 2017:
https://web.archive.org/web/20171220010 ... estera-dx/
again, i'll post them here:
Marvell Prestera 98DX3336: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for Campus edge/access with a dual core ARM v7 CPU
Marvell Prestera 98DX3236: Integrates 24 ports GbE, 2 ports of 10GbE and 2 ports of 20G stacking for SMB/SME edge/access with an ARMv7 CPU

Posted: **Mon Jun 13, 2022 9:22 am**

@Znevna: seems you're right. Also this article corroborates: https://www.linleygroup.com/newsletters ... p?num=5159

So I really wonder where that second CPU core came from?

Posted: **Mon Jun 13, 2022 9:30 am**

Probably brought up by mistake, but did anyone see it doing anything? besides creating problems..

Posted: **Mon Jun 13, 2022 10:17 am**

Probably brought up by mistake, but did anyone see it doing anything? besides creating problems..

If it wasn't there to start with, what would it possibly be doing ?

Posted: **Mon Jun 13, 2022 12:29 pm**

Probably brought up by mistake, but did anyone see it doing anything? besides creating problems..
If it wasn't there to start with, what would it possibly be doing ?

In one of pages (and I can't find it now) the text was written in a way that might lead some people believe it's got two cores. At the same time it could be read as if CPU implemented sort of hyper-threading. If the second is the case and linux kernel devs (at certain time) treated it as dual-code CPU, this might explain some problems.

Posted: **Mon Jun 13, 2022 1:58 pm**

Weird thing is, this pdf lists them as dual core:
https://download.datasheets.com/pdfs2/2 ... 015-02.pdf

Just run a search for 98DX3236 and You find it. At the very end, just two matches - one with a quad core solution and another with a dual core.
As for the number of CPUs: The kernel just keep couting what it sees - there is no magic there. Sure, it needs to know the architecture. Sure, if it doesn't know the CPU it says that. But it counts the cores all the same.

Just for fun I just created one VM with RoS 7.4beta2. The real CPU is one Rysen 3600X - six cores, twelve threads. I attributed the VM 26 cores. And that's what RoS thinks it have.

Because the kernel just counts the number of cores presented to it.

"It can't be! They changed it and the number dropped!"
Yes, it can. For two reasons. Well, three.

1) Ok, ok. You MAY be right. I doubt it, but maybe it only has one core. I don't believe it, but I'm not always right. So...
2) They patched the kernel, and it introduced a bug - leading to count one core as two. Again, I don't think it's this.
3) The kernel have one option, enabling multicore/processor support. Yes, it's true. Well, at least it had it, when single core CPUs where what we had, and servers used multiprocessors and/or single/dual core. Disable it, and the kernel uses only one core. Enable it, and the kernel uses all the available cores/processors.

I think they are having problems with dual core - some racing condition, analog to the reordering packets on the Tile CPUs - and found out that using only one core solved the issue.

I hope they fix this, and get back to using two cores. But since this is sold as single core, we can't say they are cheating the consumer...

Posted: **Mon Jun 13, 2022 2:19 pm**

If you're so familiar with this subject, please explain the two files above that I mentioned: viewtopic.php?t=186583#p939191
Why did they bother creating another file for 3336 specifying just one extra core if the kernel is so smart figuring it out on it's own?
Could it be that x86 and arm are two different beasts? no? nah, didn't think so either.
Thank you.

Posted: **Mon Jun 13, 2022 3:42 pm**

Paternot:
So you mean it's a bug of linux kernel or Mikrotik OS?

Posted: **Mon Jun 13, 2022 6:55 pm**

If you're so familiar with this subject, please explain the two files above that I mentioned: viewtopic.php?t=186583#p939191
Why did they bother creating another file for 3336 specifying just one extra core if the kernel is so smart figuring it out on it's own?
Could it be that x86 and arm are two different beasts? no? nah, didn't think so either.
Thank you.

Because several things are declared to optimize it further.

One example:
When Intel started using HyperThread the Linux kernel interpreted each CPU (there weren't multicore designs at the time) as two. It lead to problems with the scheduler, since the system tried to consider each thread as a single CPU. When You where running a single socket machine it didn't make much difference - but with two or more sockets it did. Why? Because with a (say) 2 socket machine You had 4 threads - 0,1,2 and 3. When running two heavy threads one should put one thread at each CPU (so, threads 0 and 2), instead of two threads on the same CPU (like 0 and 1).

Without this optimization the kernel still worked, and still thougth it had 2 CPUs for each socket. With the optimization it worked better.

Another example:
Now the x86 CPUs are able to boost beyond their clock speed. Basically an auto overclock. AMD CPUs usually have one given core that goes further up, but until very recently Intel had a simpler boost, and all cores would go up to the same clock. But they would slow down, after some time, due to thermal throttling.

So, we had ANOTHER optimization - that was used on a per CPU model basis: The kernel would cycle the load through the cores (taking care not to use two hyperthreading from the same core), in order to let them cool down. Without this optimization, the kernel would work - but You would loose speed on a single threaded load scenario.

Now, get down from your high horse, and learn to debate in a civil way. Just because You are rude doesn't mean we have to put up with it.

Posted: **Mon Jun 13, 2022 7:03 pm**

Paternot:
So you mean it's a bug of linux kernel or Mikrotik OS?

I don't know. I think maybe. I don't think the kernel would find another CPU that wasn't there. It could be something like hyperthreading, but I don't think these CPUs have it.

I do know that the Tile CPUs (the smallest of them with 9 cores, and going up to 72 cores) had one interesting problem: if the routing engine used more than one core to route single connection, the packets would get out of order at the other side. Mikrotik solved this making the routing of a single connection single core. This is why the Tile routers are great dealing with hundreds of slower connections, but quite awful dealing with one single very fast connection.

I think we have something like this here: with two cores there were flapping problems, with one core they are gone. Looks to me like a timing problem. It probably can be solved with more work on it - but I believe stabilizing RoS V7 ir more important now. It is a switch, after all. The second core will not make any difference while processing the L2 traffic.

Posted: **Mon Jun 13, 2022 7:04 pm**

I well know that I have to draw it out for you to make you understand that you are wrong, considering our past interactions: viewtopic.php?p=847956#p848050
You only dug up some even older document that claims nowhere that 3236 is dual core (but it states somewhere that some cpu has 800GHz speed, legit so far) and you're talking about x86, again, which has nothing to do with arm or this particual SoC.
So I'll get down from my high horse when needed ;)
Cheers!

Posted: **Mon Jun 13, 2022 7:41 pm**

Paternot:
Thank you for nice explanation mainly for 72 core.

Posted: **Mon Jun 13, 2022 8:01 pm**

I well know that I have to draw it out for you to make you understand that you are wrong, considering our past interactions: viewtopic.php?p=847956#p848050
You only dug up some even older document that claims nowhere that 3236 is dual core (but it states somewhere that some cpu has 800GHz speed, legit so far) and you're talking about x86, again, which has nothing to do with arm or this particual SoC.
So I'll get down from my high horse when needed ;)
Cheers!

Ah. Just trolling, then. Ok, carry on.

Posted: **Tue Jun 14, 2022 3:40 pm**

It would really be cool to get a somewhat more descriptive statement from Mikrotik regarding the CPU core topic ...

Posted: **Tue Jun 14, 2022 4:36 pm**

It would really be cool to get a somewhat more descriptive statement from Mikrotik regarding the CPU core topic ...

Does it matter really? It's the software threading model used by things in userland that matters. And the kernel's scheduler take into account a variety of things beyond "core count" in how it divides CPU tasks.

Perhaps there is a bug in how the CPU's capacities are translated into RouterOS attributes in CLI/winbox, but it's not like there is some hidden switch they aren't turning to use the "all of the CPU". Their software utilization of the kernel is way more important, and that manifested directly in network speed so not much to document about "core count" & actual traffic results would speak louder.

Posted: **Tue Jun 14, 2022 6:13 pm**

@Znevna: seems you're right. Also this article corroborates: https://www.linleygroup.com/newsletters ... p?num=5159

So I really wonder where that second CPU core came from?

Chip binning - google it.

TLDR version - phisically there are 2 cores on the chip, but manufacturer detected issues with 2nd core, and sold it as cheaper single core part to MikroTik. Probably it was not locked in any way, so it just showed up when you solder all pins. so it needed to be disabled in software.

Posted: **Tue Jun 14, 2022 8:33 pm**

*) switch - disabled second CPU core for CRS328-24P-4S+ device in order to improve SFP+ link stability;

Confirmed here: I haven't seen a bounce in the 1 day 18 hrs this switch has been up on 7.4beta2. Before, I'd see it happen several times a day, staying down for about a second each time.

I'm using generic modules, with a 10GBASE-SR one down to an RB4011 on one leg and a 1000BASE-SX one down to a hEX PoE on the other leg.

I'm not sure it's improved anything performance-wise, but it is nice to have that noise out of my logs now.

Posted: **Tue Jun 14, 2022 11:48 pm**

TLDR version - phisically there are 2 cores on the chip, but manufacturer detected issues with 2nd core, and sold it as cheaper single core part to MikroTik. Probably it was not locked in any way, so it just showed up when you solder all pins. so it needed to be disabled in software.

Interesting idea. It would explain several observed things. Although one thing strikes me as a problem to this idea: It wouldn't be very practical if the deactivation of a given core was dependent on a given pin not being soldered. Imagine the logistical nightmare, to find out if (say) pin 2 or 3 should be left alone - since the problematic core could be the 0 or 1.

By the way, just remembered: The CRS326 use the very same CPU. Are they showing two cores on RoS V7.x? Are they affected by the same problem?

Posted: **Wed Jun 15, 2022 6:29 am**

Another release without full VRF functionality (as attested by posts from buset1974 and loloski above).

I'm perplexed that we're up to a dot-four release, but there still appear to be chunks of L3 VPN functionality missing. These are not bugs; they are things that haven't even been implemented. Specifically, output filters don't work and it's not possible to use the mangle to look up routes in a VRF.

Can MikroTik provide some indication of when this might be addressed?

i saw that many people have the same experience and i don't know how to make mikrotik listen.
With this issue, we cannot upgrade the current production router with version 7.x,

Posted: **Wed Jun 15, 2022 11:10 am**

Interesting idea. It would explain several observed things. Although one thing strikes me as a problem to this idea: It wouldn't be very practical if the deactivation of a given core was dependent on a given pin not being soldered. Imagine the logistical nightmare, to find out if (say) pin 2 or 3 should be left alone - since the problematic core could be the 0 or 1.

By the way, just remembered: The CRS326 use the very same CPU. Are they showing two cores on RoS V7.x? Are they affected by the same problem?

well we are in the world of chip shortage now, so manufactuers are soldering anyting on the boards that they actually get. It wouldn't suprize me that some part of these devices have actual 2 core CPU on them, just to be able to produce them.

Posted: **Wed Jun 15, 2022 3:05 pm**

well we are in the world of chip shortage now, so manufactuers are soldering anyting on the boards that they actually get. It wouldn't suprize me that some part of these devices have actual 2 core CPU on them, just to be able to produce them.

True. But this practice isn't new - far from it. It stands to reason that the CPU would have a simple way to be shipped with one of this cores disabled at factory. Better to the manufacturer (no one can cheap out and buy one core to use two) and better to the buyer (easier to use, just put it on the board and the chip says it only has one core).

Just like it's done on the x86 world: Intel or AMD disable the core at the factory, and sell it this way. The consumer just puts it on the motherboard, and the CPU tells the number of cores it has. Zero effort on the consumer part.

Posted: **Wed Jun 15, 2022 3:39 pm**

Frequency differences on CPU is the same (at least, used to be).
You really think they MAKE them for a certain frequency within the same family ?
No way.
One production process and then some testing to see where you can get. If there are not enough for the lower frequencies, they take the higher ones and put a lower label on it.

Posted: **Wed Jun 15, 2022 3:47 pm**

Although one thing strikes me as a problem to this idea: It wouldn't be very practical if the deactivation of a given core was dependent on a given pin not being soldered. Imagine the logistical nightmare, to find out if (say) pin 2 or 3 should be left alone - since the problematic core could be the 0 or 1.

Assume that you not remember jumpering motherboards. Setting speeds, dividers/multipliers, cache sizes ... Freedy Kruger wasn't the most frightening nightmare those times

Posted: **Wed Jun 15, 2022 3:50 pm**

Those were the days ...

Posted: **Wed Jun 15, 2022 5:49 pm**

Worth reading how real silicon chip could be visible to the rest of "the world" https://www.igorslab.de/en/intel-deacti ... editorial/

Posted: **Wed Jun 15, 2022 6:27 pm**

Hello thanks mikrotik for implementing support of VRF for PPP , this is a big step for us , as we use to use it with cisco and Juniper
however could you work on support of BGP inside VRF, is it the only thing that miss , if we want to replace about thousand old cisco / juniper router to Mikrotik device

regards

by the way I tried .default-originate=never or .default-originate=if-installed without success

When BGP vrf PE-CE issue will be fix?

This is BGP configuration in v6 and v7

v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no

v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no

actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.

PE-99-vrf-capture-1.jpg
PE-99-vrf-capture-2a.jpg
PE-99-vrf-capture-2.jpg
thx
I have the same issue, it would appear to be an issue with .default-originate=always function if you set to .default-originate=always. if you set to .default-originate=never or .default-originate=if-installed then issue is resolved.

Doesn't help much but shows where the issue is.

Posted: **Thu Jun 16, 2022 4:14 am**

Assume that you not remember jumpering motherboards. Setting speeds, dividers/multipliers, cache sizes ... Freedy Kruger wasn't the most frightening nightmare those times :)

Don't You talk to me about jumpering motherboards - I have had my fair share of IRQs and addresses with 386s...

But my point stands: When You have two cores, and one of them dead, it's far easier to just disable it at factory testing. Can You imagine otherwise?
"No, no! This is the item number 378917835644 - it has the core 1 dead! The one with the core 0 dead is the 378917835643! Move this jumper C1 to the 1-2 position!"

Posted: **Thu Jun 16, 2022 11:44 am**

The point is, that motherboard COULD has been designed for cheaper only one-core factory enabled chip not needing soldering/grounding/powering particular pins as it was not needed for such processors. IF, watch the "IF", MT mounts two core enabled chips as they are the only accessible then the additional core is recognized as it is not disabled by in silicon nor by proper pin settings. The untested or problematic second core has to be disabled in software or ROS has to be tested/extended for the second core use.
In Poland we say "If you don't own what you like, then you must like what you possess." what in English is " beggars can't be choosers"

Posted: **Thu Jun 16, 2022 4:22 pm**

What's new in 7.4beta4 (2022-Jun-15 14:04):

*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
*) defconf - fixed default configuration loading on devices with WifiWave2 package;
*) dhcp-relay - fixed DHCPv6 relay forward and reply creation (introduced in v7.1.3);
*) dhcp-server - change "vendor-class-id" matcher to generic option matcher;
*) dot1x - fixed "undo" command for server instances;
*) l2tp - improved stability when establishing l2tp-ether connection (introduced in v7.3);
*) leds - fixed GPS LED configuration on LtAP LTE kit;
*) leds - fixed LTE signal strength LED configuration on LHGG LTE kit;
*) leds - fixed LTE signal strength LED configuration on LtAP LTE kit;
*) lte - added AT chat support for Dell dw5821e modem;
*) lte - fixed LTE interface running state after modem reconnection;
*) mqtt - fixed socket error handling;
*) netwatch - added support for more advanced probing;
*) ovpn - fixed "called-station-id" RADIUS attribute value for OVPN server;
*) ppp - do not fail connection when trying to add existing IP address to address list;
*) ppp - log warning message when remote IP address can not be added;
*) route - changed "mode" setting to "exclude" for group management protocol (CLI only);
*) route - made export run faster on tables with a large number of dynamic routes;
*) routing-filter - added origin matcher to match for example routes of a specific OSPF instance;
*) routing-filter - made "do-jump" work in select rules;
*) ssh - fixed host key generation (introduced in v7.3);
*) switch - fixed multicast flooding when HW offloaded bridge port gets disabled;
*) system - fixed configuration reset with "run-after-reset" with file stored on ramdisk;
*) upgrade - improved RouterOS upgrade stability with attached USB modem on MIPSBE, SMIPS and MMIPS devices;
*) w60g - improved interface initialization after being inactive for a while;
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
*) winbox - fixed filename dropdown value filtering;
*) x86 - fixed Broadcom NIC support;

Posted: **Thu Jun 16, 2022 4:26 pm**

Container has now some improved usability and a pull command. New documentation here: https://help.mikrotik.com/docs/x/KYAPBQ

Posted: **Thu Jun 16, 2022 4:30 pm**

Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch

Posted: **Thu Jun 16, 2022 4:34 pm**

Hi.
Is this fix from 7.3.1 also included in this beta ??
*) wifiwave2 - fixed WPA3-PSK authentication incompatibility with certain vendor and model devices;

Posted: **Thu Jun 16, 2022 4:36 pm**

Posted: **Thu Jun 16, 2022 4:41 pm**

*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

Anything special to be configured for this to function ?

Posted: **Thu Jun 16, 2022 4:45 pm**

is this
*) route - made export run faster on tables with a large number of dynamic routes;
helping about support #[SUP-83756]: ccr2216 with 3xBGP_fullroute not able to sort route when rpki is checked??

regards
Ros

Posted: **Thu Jun 16, 2022 4:46 pm**

Thanks for the Netwatch improvements, specifically the VRF support! :D

Posted: **Thu Jun 16, 2022 4:51 pm**

Upgraded 2x hAP AC3 from 7.3.1, from the very short time it's running, no issues seen.
(VLANs, Wifi, WG, ... all ok so far)

When checking for new version in Winbox (testing or development), release notes for 7.4beta4 are not shown. Only 7.4beta2.
But proposed package is 7.4beta4 (I hope it is :lol: )

Posted: **Thu Jun 16, 2022 4:55 pm**

Two quick questions about containers:

1) are veth interfaces mandatory, or can host networking be used?
2) the docs state that ext4 is supported, is this new? Any plans to add ext4 support to Disks > Format Drive?

Posted: **Thu Jun 16, 2022 5:02 pm**

Two quick questions about containers:

1) are veth interfaces mandatory, or can host networking be used?
2) the docs state that ext4 is supported, is this new? Any plans to add ext4 support to Disks > Format Drive?

1) Yes
2) Disks are formatted from RouterOS as ext4 for a while now.

Posted: **Thu Jun 16, 2022 5:02 pm**

Two quick questions about containers:

1) are veth interfaces mandatory, or can host networking be used?
2) the docs state that ext4 is supported, is this new? Any plans to add ext4 support to Disks > Format Drive?

7.4b4_ext4.JPG

Posted: **Thu Jun 16, 2022 5:28 pm**

Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch

Thank all very nice Jon, just why you all not considering adding the from-src-address: or from interface option to Netwatch, is there any limitaion?

Posted: **Thu Jun 16, 2022 5:29 pm**

Thanks for the Netwatch improvements, specifically the VRF support! :D

Would be nice if specifying a local address or a routing mark is allowed too...

Posted: **Thu Jun 16, 2022 5:35 pm**

I can't access netwatch from command line on 7.4beta4
/tool/netwatch
bad command name netwatch (line 1 column 7)

Anyone else can confirm?

Erm yeah... Me neither. Oh MikroTik, what have you done...

Posted: **Thu Jun 16, 2022 5:37 pm**

I can't access netwatch from command line on 7.4beta4
/tool/netwatch
bad command name netwatch (line 1 column 7)

Anyone else can confirm?
Erm yeah... Me neither. Oh MikroTik, what have you done...

Do you have advanced-tool installed?

Posted: **Thu Jun 16, 2022 5:39 pm**

Erm yeah... Me neither. Oh MikroTik, what have you done...
Do you have advanced-tool installed?

That's v6 stuff isn't it? Last I knew, you'd done away with separate packages for core functionality with v7.

Posted: **Thu Jun 16, 2022 5:41 pm**

What device it is? Architecture?

Posted: **Thu Jun 16, 2022 5:42 pm**

What device it is? Architecture?

For me, I'm running a CHR with v7.4beta4

[ali@<redacted>] > /system/resource/print
                   uptime: 14m46s
                  version: 7.4beta4 (testing)
               build-time: Jun/15/2022 11:04:34
         factory-software: 6.49.3
              free-memory: 1829.4MiB
             total-memory: 1920.0MiB
                      cpu: Intel
                cpu-count: 1
            cpu-frequency: 2394MHz
                 cpu-load: 0%
           free-hdd-space: 39.7GiB
          total-hdd-space: 39.7GiB
  write-sect-since-reboot: 460272
         write-sect-total: 460272
        architecture-name: x86_64
               board-name: CHR
                 platform: MikroTik
[ali@<redacted>] > /tool/netwatch
bad command name netwatch (line 1 column 7)
[ali@<redacted>] >

Posted: **Thu Jun 16, 2022 5:49 pm**

hap lite, hap ac2, chateau lte12 upgraded without issue.

Posted: **Thu Jun 16, 2022 5:53 pm**

is this
*) route - made export run faster on tables with a large number of dynamic routes;
helping about support #[SUP-83756]: ccr2216 with 3xBGP_fullroute not able to sort route when rpki is checked??

regards
Ros

What you experience is something else, the fix is only for export.

Posted: **Thu Jun 16, 2022 6:12 pm**

arm64:

/tool/netwatch
bad command name netwatch (line 1 column 7)

Configured via WinBox it seems to work.
But anything you configure in it is not visible in an /export.

Posted: **Thu Jun 16, 2022 6:26 pm**

Updated my containers from the 7.0x beta and was redeploy it on my CHR with no issues.

Posted: **Thu Jun 16, 2022 6:44 pm**

how to update the device mode to enable the container under CHR ?

 /system/device-mode/update container=yes
  update: please activate by turning power off or pressing reset or mode button in 4m55s

Posted: **Thu Jun 16, 2022 6:47 pm**

thanks for the netwatch improvements, but I agree, src-address parameter is also needed.
any ETA when we can expect a working igmp part of PIM?

Posted: **Thu Jun 16, 2022 6:50 pm**

how to update the device mode to enable the container under CHR ?
Code: Select all
 /system/device-mode/update container=yes
  update: please activate by turning power off or pressing reset or mode button in 4m55s

You'll need to force power-off or force reboot the CHR VM. Do that from your hypervisor/VPS dashboard.

Posted: **Thu Jun 16, 2022 6:57 pm**

In fact ,I tried. but the problem remains.
I am running it on esxi 7.03. I can easily shut down or restart it. not sure if that is "forced way"

Posted: **Thu Jun 16, 2022 7:00 pm**

2) Disks are formatted from RouterOS as ext4 for a while now.

That's good news! As of 7.3.1, Disks > Format Disk in WebFig only offers ext3 though, and the formatted disk also appears as ext3? Is this a WebFig text label issue only?

Screenshot 2022-06-16 at 18.59.43.png

Posted: **Thu Jun 16, 2022 7:04 pm**

In fact ,I tried. but the problem remains.
I am running it on esxi 7.03. I can easily shut down or restart it. not sure if that is "forced way"

I think that may be doing it "gracefully". What you need to do is force power-off/force reboot. I think they're called Hard stop and Reset respectively with ESXi?

Posted: **Thu Jun 16, 2022 7:04 pm**

I am running it on esxi 7.03. I can easily shut down or restart it. not sure if that is "forced way"

Resources → Machines → vCenter VM → Reset Virtual Machine

Posted: **Thu Jun 16, 2022 7:13 pm**

Sorry for any inconvenience caused regarding the Netwatch service unavailability under CLI. This will be fixed in the next beta release.

Posted: **Thu Jun 16, 2022 7:18 pm**

Thanks
@aliclubb @tangent

problem solved.

Posted: **Thu Jun 16, 2022 7:19 pm**

Thanks
@aliclubb @tangent

problem solved.

Happy to help!

Posted: **Thu Jun 16, 2022 7:21 pm**

Sorry for any inconvenience caused regarding the Netwatch service unavailability under CLI. This will be fixed in the next beta release.

Settings are also missing from the export. If that is unrelated, please fix that as well.
And now that you are working on it, please implement selection of the source address.

Posted: **Thu Jun 16, 2022 7:48 pm**

*) netwatch - added support for more advanced probing;

I wish you wouldn't use these combined ipv4@vrf, ipv6@vrf formats. Back when I started with RouterOS (WinBox), the thing I really liked was that everything was so clear and self documenting, I was able to use it without even looking in manual. If there was separate field for VRF, then everyone would immediatelly see that it's there. If it's <address>@<vrf name>, then every new user has to look that up in order to know that VRF support exists there (ipv6-linklocal%interface is at least expected, because it's common standard). And even when you know about it, wouldn't it be convenient to select existing VRF from dropdown, instead of having to type the whole name?

Posted: **Thu Jun 16, 2022 8:15 pm**

Fyi - Container help docs updated just a few hours ago: help.mikrotik.com/docs/display/ROS/Container

Posted: **Thu Jun 16, 2022 9:04 pm**

Is the boot-loop fix for the RB3011 included in beta4? I had tried beta2 to check if IPv6 netmap was fixed in this version (see viewtopic.php?p=940066#p940066 for the issue) but it looks like this version possibly did not yet include the 7.3.1 fix so it entered a boot-loop.

Posted: **Thu Jun 16, 2022 9:10 pm**

Current config on 7.3.1 runs fine...so there is nothing changed between updates. Previous beta 7.4beta2 was ok post upgrade from 7.3.1
Reflashed to 7.4beta4 second time ... seems to work..for a while then the connection from devices to wifi drops. The SSID is still visible but can't reconnect to network anymore.

Posted: **Thu Jun 16, 2022 10:27 pm**

Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch

Ok, did some tests, some observations:
"done-tests" counter only updates when there's a status change from up<>down or when you hit refresh in WinBox on the Netwatch window. (probably other fields update in the same way), you can hit refresh in WinBox, but in WebFig it's not so fun to hit refresh.
What is "failed-tests" used for? I thought it counts how many .. you know, tests failed, but it never increases, remains 0.

Posted: **Fri Jun 17, 2022 7:46 am**

I have encountered a strange issue.

If there are additional VRF's present in the configuration (IP > VRF), OSPF will not form an adjacency using the MAIN routing table and errors out with "routing table is not active". (picture attached).

The Router ID entries become invalid for all VRF's. (picture attached)

If I disable the other VRF's, the adjacency is formed after a reboot.

The Router ID entry for the MAIN VRF is once again restored.

Posted: **Fri Jun 17, 2022 7:47 am**

*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

Anything special to be configured for this to function ?

Support for fast BSS transitions can be enabled with
/interface/wifiwave2/set wifi1,wifi2 security.ft=yes
And a client device will only consider roaming between interfaces if they have the same SSID.

Posted: **Fri Jun 17, 2022 7:56 am**

I have encountered a strange issue.

If there are additional VRF's present in the configuration (IP > VRF), OSPF will not form an adjacency using the MAIN routing table and errors out with "routing table is not active". (picture attached).

The Router ID entries become invalid for all VRF's. (picture attached)

If I disable the other VRF's, the adjacency is formed after a reboot.

The Router ID entry for the MAIN VRF is once again restored.

Further testing shows that this VRF issue is ONLY present when Routing > BGP > VPN entries are enabled. More specifically, if I select 'redistribute ANY routes' in a BGP VPN Instance.
if I use the Routing > Filter > Select Rules and reject the export of any route, the issue subsides.

So it seems to be happening whenever any route is exported from VRF's and installed into the main table as a VPNv4 route. VPNv4 routes from other neighboring LSR's don't seem to cause the issue.

Posted: **Fri Jun 17, 2022 10:57 am**

There is another major error in the netwatch tool: with existing "simple" entries at least, when the target goes down, it runs the script for "up". The same script is run when the target goes up. The "down" script is never run.

Posted: **Fri Jun 17, 2022 11:02 am**

Netwatch now has extended functionality for ICMP, along with new probe types for TCP and HTTP GET. More information can be found here: https://help.mikrotik.com/docs/display/ROS/Netwatch
Ok, did some tests, some observations:
"done-tests" counter only updates when there's a status change from up<>down or when you hit refresh in WinBox on the Netwatch window. (probably other fields update in the same way), you can hit refresh in WinBox, but in WebFig it's not so fun to hit refresh.
What is "failed-tests" used for? I thought it counts how many .. you know, tests failed, but it never increases, remains 0.

Some more observations:
down-script never gets executed, whatever is in up-script gets executed "on down" too.

netwatch host.PNG

netwatch host on-up.PNG

netwatch host on-down.PNG

netwatch host on-test.PNG

netwatch log.PNG

Probably related to "failed-tests" never increasing?
LE: The documented read-only properties seem not well functional:
"status" doesn't say anything, and "since" contains the timestamp of the last change.. in unix format.

:log info "netwatch: $host up $status $since"

netwatch host status since.PNG

Posted: **Fri Jun 17, 2022 11:48 am**

*) netwatch - added support for more advanced probing;
I wish you wouldn't use these combined ipv4@vrf, ipv6@vrf formats. Back when I started with RouterOS (WinBox), the thing I really liked was that everything was so clear and self documenting, I was able to use it without even looking in manual. If there was separate field for VRF, then everyone would immediatelly see that it's there. If it's <address>@<vrf name>, then every new user has to look that up in order to know that VRF support exists there (ipv6-linklocal%interface is at least expected, because it's common standard). And even when you know about it, wouldn't it be convenient to select existing VRF from dropdown, instead of having to type the whole name?

You are in my mind.
And exactly that, is the reason why I hate the new routing filters syntax.

Posted: **Fri Jun 17, 2022 11:52 am**

Thank you for the reports, issue with CLI and the "up" script being executed instead of down will be resolved in upcoming releases, the fail counter should be resolved then as well.

Posted: **Fri Jun 17, 2022 11:59 am**

And exactly that, is the reason why I hate the new routing filters syntax.

Indeed, MikroTik is really going on the wrong track lately.
A bit more of this and we are better off running a plain Linux system and configure everything from scratch using config files and shell scripts native to Linux.
(and no longer be confronted with situations where the underlying system can do things that are hidden by the config layer, even after years of asking for additions)

There really should be internal discussion on what is the way to go.

Posted: **Fri Jun 17, 2022 12:26 pm**

Want to try containers but Waiting on the new release due to these new bugs... How does something like netwatch disappear from cli or start running the wrong scripts just because some extra advanced fields were added, that seems very strange..?

Posted: **Fri Jun 17, 2022 6:19 pm**

Anyone else having issues with L2TP on these more recent beta versions? (I'm IPSEC encrypted with config set in ip/ipsec rather than under the L2TP client and server config).

Client and server both running 7.4beta4, I get (on the client):

16:02:24 l2tp,ppp,info peter_home_l2tp: initializing...
16:02:24 l2tp,ppp,info peter_home_l2tp: connecting...
16:02:24 l2tp,debug tunnel 56 entering state: wait-ctl-reply
16:02:24 l2tp,debug tunnel 56 entering state: established
16:02:24 l2tp,debug session 58 entering state: wait-reply
16:02:24 l2tp,debug session 58 entering state: established
16:02:24 l2tp,ppp,debug peter_home_l2tp: LCP lowerup
16:02:24 l2tp,ppp,debug peter_home_l2tp: LCP open
16:02:24 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:27 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:30 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:33 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:36 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:39 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:42 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:45 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:48 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:51 l2tp,ppp,debug peter_home_l2tp: PPP received non-LCP packet (0xc223) when LCP not open
16:02:54 l2tp,ppp,debug peter_home_l2tp: LCP lowerdown
16:02:54 l2tp,ppp,debug peter_home_l2tp: CCP close
16:02:54 l2tp,ppp,debug peter_home_l2tp: BCP close
16:02:54 l2tp,ppp,debug peter_home_l2tp: IPCP close
16:02:54 l2tp,ppp,debug peter_home_l2tp: IPV6CP close
16:02:54 l2tp,ppp,debug peter_home_l2tp: MPLSCP close
16:02:54 l2tp,ppp,info peter_home_l2tp: terminating...
16:02:54 l2tp,debug session 58 entering state: stopping
16:02:54 l2tp,ppp,debug peter_home_l2tp: LCP lowerdown
16:02:54 l2tp,ppp,debug peter_home_l2tp: LCP down event in starting state
16:02:54 l2tp,ppp,info peter_home_l2tp: disconnected
16:02:55 l2tp,debug tunnel 56 entering state: dead
16:02:55 l2tp,debug session 58 entering state: dead

On the server side, the error relates to the client not responding to its CHAP challenge

On client side, error messages suggest the CHAP packets (0xc223) are being dropped due to "LCP not open", despite the log line immediately prior declaring "LCP open".

Posted: **Fri Jun 17, 2022 6:48 pm**

I am only running L2TP/IPsec connections on 7.4 on the client side, server is 6.49.x, and I have no such issues here.

Posted: **Sat Jun 18, 2022 12:45 am**

Is the boot-loop fix for the RB3011 included in beta4? I had tried beta2 to check if IPv6 netmap was fixed in this version (see viewtopic.php?p=940066#p940066 for the issue) but it looks like this version possibly did not yet include the 7.3.1 fix so it entered a boot-loop.

Can confirm that beta4 fixes the boot-loop. IPv6 NAT netmap still broken though :'(

Posted: **Sat Jun 18, 2022 3:45 am**

It is really nice how finally a RouterOS device that gets its IP via SLAAC will show that IP under IPv6->Addresses, thank you for finally doing this (I realize it was done in 7.3.x and not 7.4.x, but still, it is a new feature that I have been requesting for years now).

However, the default route being received through SLAAC is still not being displayed in the routing table. Are there plans to address this in 7.4.x?

Posted: **Sat Jun 18, 2022 1:24 pm**

My RB5009 running 7.3.1 and firmware 7.2.3 refused to boot after upgrading to 7.4Beta4. Only a netinstall back to 7.3.1 resurrected it.

No supout - it never booted. I also struggled for about 3 hours just to get Netinstall working. Only Neinstall 7.2.3 seemed to work for me - I had to run Wireshark and see which versions would send the code via BOOTP without failing halfway through with "port unreachable" after block 2763.

Once I managed to force 7.3.1 back onto it, it came back. It's really hard to diagnose the 5009 given its lack of a serial port for the pre-boot environment.

Posted: **Sun Jun 19, 2022 12:30 am**

When BGP vrf PE-CE issue will be fix?

This is BGP configuration in v6 and v7

v6.49.6 (works)
2 name="peer-trial-bgp-ce" instance=bgp1 remote-address=172.19.2.2 remote-as=65500 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m
ttl=default in-filter="" out-filter="" address-families=ip default-originate=always remove-private-as=no as-override=no passive=no use-bfd=no

v7.3 (did not works, BGP session not established)
2 name="peer-trial-bgp-ce"
remote.address=172.19.2.2/32 .port=179 .as=65500
local.address=172.19.2.1 .role=ebgp
connect=yes listen=yes routing-table=vrf-trial-xxx vrf=vrf-trial-xxx
router-id=172.19.2.1 templates=bgp1 as=65505 address-families=ip
output.network=ebgp-vpnv4-networks .default-originate=always
.no-client-to-client-reflection=no

actually the BGP session di v7 did something in route (see attachment) , it just like leak on memory and BGP status not established.

PE-99-vrf-capture-1.jpg
PE-99-vrf-capture-2a.jpg
PE-99-vrf-capture-2.jpg
thx

"this has been addressed in v7.3 , using pe-ce bgp , however run this in the lab before any live deployments "
CE :
[admin@bank] > routing/route/print
Flags: A - ACTIVE; c, b, y - COPY; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE IMMEDIATE-GW
b 1.1.1.1/32 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 1.1.1.1/32 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 2.2.2.2/32 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 2.2.2.2/32 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
Ac 3.3.3.3/32 loopback0 ip4 0 10 loopback0
Ab 8.8.8.8/32 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 8.8.8.8/32 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
b 100.64.0.0/31 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 100.64.0.0/31 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 100.64.0.2/31 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 100.64.0.2/31 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 100.64.0.4/31 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 100.64.0.4/31 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 100.64.0.6/31 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 100.64.0.6/31 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
Ab 100.64.0.8/31 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 100.64.0.8/31 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ab 100.64.0.10/31 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
b 100.64.0.10/31 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
b 203.0.113.0/30 203.0.113.1 ip4 20 40 10 203.0.113.1%ether1
Ac 203.0.113.0/30 ether1 ip4 0 10 ether1
b 203.0.113.4/30 203.0.113.5 ip4 20 40 10 203.0.113.5%ether2
Ac 203.0.113.4/30 ether2 ip4 0 10 ether2
Ac fe80::%ether1/64 ether1 ip6 0 10 ether1
Ac fe80::%ether2/64 ether2 ip6 0 10 ether2
Ac fe80::%loopback0/64 loopback0 ip6 0 10 loopback0
A H ether1 link 0
A H ether2 link 0
A H ether3 link 0
A H ether4 link 0
A H ether5 link 0
A H ether6 link 0
A H ether7 link 0
A H ether8 link 0
A H loopback0 link 0
[admin@bank] > tool/traceroute 1.1.1.1 src-address=3.3.3.3
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV, STATUS
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 100% 46 timeout
2 192.0.2.14 0% 45 5.2ms 4.8 2.8 9.2 1.5 <MPLS:L=21,E=0 L=35,E=0,T=1>
3 192.0.2.8 0% 45 3.4ms 4.8 2.5 13.2 2.3 <MPLS:L=22,E=0 L=35,E=0,T=1>
4 100.64.0.0 0% 45 2.4ms 3.9 1.6 28.7 3.9 <MPLS:L=35,E=0>
5 1.1.1.1 0% 45 2.8ms 4.2 2.1 10.6 1.8

[admin@bank] >
PE:

[admin@p7.mikey.rsco] > routing/route/print where routing-table=bank
Flags: A - ACTIVE; c, b, y - COPY; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE, IMMEDIATE-GW
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE IMMEDIATE-GW
Ay 1.1.1.1/32 198.51.100.101 ip4 0 40 30 192.0.2.14%ether2
Ay 2.2.2.2/32 198.51.100.106 ip4 0 40 30 192.0.2.19%ether1
Ab 3.3.3.3/32 203.0.113.2@bank ip4 20 40 10 203.0.113.2%ether3
Ay 8.8.8.8/32 198.51.100.109 ip4 0 40 30 192.0.2.14%ether2
Ay 100.64.0.0/31 198.51.100.101 ip4 0 40 30 192.0.2.14%ether2
Ay 100.64.0.2/31 198.51.100.106 ip4 0 40 30 192.0.2.19%ether1
Ay 100.64.0.4/31 198.51.100.101 ip4 0 40 30 192.0.2.14%ether2
Ay 100.64.0.6/31 198.51.100.106 ip4 0 40 30 192.0.2.19%ether1
Ay 100.64.0.8/31 198.51.100.109 ip4 0 40 30 192.0.2.14%ether2
Ay 100.64.0.10/31 198.51.100.110 ip4 0 40 30 192.0.2.19%ether1
b 203.0.113.0/30 203.0.113.2@bank ip4 20 40 10 203.0.113.2%ether3
Ac 203.0.113.0/30 ether3@bank ip4 0 10 ether3
Ab 203.0.113.4/30 203.0.113.2@bank ip4 20 40 10 203.0.113.2%ether3
Ac fe80::%ether3/64 ether3@bank ip6 0 10 ether3
A H ether3 link 0
[admin@p7.mikey.rsco] >

Posted: **Wed Jun 22, 2022 12:06 pm**

The terminal inkey timeout parameter is not working since around v7.3. In a few scripts I have that loop until a key press, they now get stuck on this command, endlessly waiting for a keypress.

When I run the following command on a MikroTik Chateau LTE12 on v7.3.1 stable or a Chateau 5G on v7.4beta4, it does not timeout after 5 seconds:

:put [ :terminal inkey timeout=5 ]

With earlier firmware versions such as 7.2, it would continue after waiting 5 seconds.

Posted: **Thu Jun 23, 2022 12:37 am**

Recently upgraded the RB4011 of my house to the v7.4b4 and had the need of connect by ethernet, because the wlan2 5Ghz radio was disabled by default after the reboot... enabling the radio, all work great again!

Posted: **Fri Jun 24, 2022 2:32 pm**

New beta today with BFD support, full VRF support and reported bug fixes?

:)

Posted: **Fri Jun 24, 2022 6:06 pm**

CCR2004-16G v7.4beta4; Using the device usb interface, if I insert the usb3.0 USB flash drive, the system and smb services will be unstable, and the device cannot automatically recognize the USB flash drive after restarting the device. If I use a usb2.0 USB flash drive, everything is normal. The brand of the USB flash drive is SanDisk.

Posted: **Mon Jun 27, 2022 3:48 pm**

What's new in 7.4beta5 (2022-Jun-27 10:39):

*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
*) dhcpv4-server - disallowed overriding message type option;
*) dhcpv4-server - log message when user option updates existing option;
*) dhcpv4-server - placed option 53 as the first one in the packet;
*) health - fixed requesting data from sensor when issuing "get" command;
*) health - fixed voltage reporting on some RBmAP-2nD devices;
*) lte - validate LTE attached IP type in MBIM mode;
*) netwatch - added support for more advanced probing;
*) poe - hide "poe-voltage" parameter on devices that do not support it;
*) route - expose all valid routes to route select filter from OSPF and RIP;
*) route-filter - fixed route select filter rules;
*) upgrade - ignore same version packages during upgrade procedure;
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;
*) winbox - added "name" parameter under "Routing/BGP/Session" menu;
*) winbox - added "to-address" and "to-ports" parameters under "IPv6/Firewall/NAT" menu;
*) winbox - added support for "Routing/GMP" menu;
*) winbox - added support for "veth" interface types;
*) winbox - fixed "inactive" flag naming under "MPLS/Local Mapping" menu;
*) winbox - fixed minor typo under "Interface" stats;
*) winbox - fixed units for "reachable-time" parameter under "IPv6/ND" menu;
*) winbox - removed "TLS Host" parameter from "IP/Firewall/NAT" menu;
*) winbox - removed duplicate signal strength column under "Wireless/Registration Table" menu;

Posted: **Mon Jun 27, 2022 4:14 pm**

Some of those changes are present in the previous beta too, what gives?
*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
*) netwatch - added support for more advanced probing;
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

Or they contain fixes over the previous implementation?
LE: ok, netwatch script on-down is fixed, the rest of the reported issues are still present (regarding netwatch).
LE2: I don't know if containers existed in WinBox but it exists now.
LE3: netwatch config is visible in export, so this is fixed too.
envlist changed syntax: viewtopic.php?t=178342&start=300#p942131
It seems "list" is now "name" and "name" is now "key" . Thanks @daaf
envlist is not migrated to new syntax, so make a backup and readd them with the new syntax.
Adding comments to containers seem to be fixed....
Veth interfaces still can't be edited, any change to address or gateway require a reboot, or removing the interface and recreating it....

Posted: **Mon Jun 27, 2022 4:18 pm**

What's new in 7.4beta5 (2022-Jun-27 10:39):

*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

This was mentioned in the previous beta, yet you're saying this is new in beta5. Has something changed?

Posted: **Mon Jun 27, 2022 4:26 pm**

*) winbox - added "to-address" and "to-ports" parameters under "IPv6/Firewall/NAT" menu;

For what action specifically? I know dst-nat already had it, src-nat maybe? It still seems to be missing for netmap though. Which itself is also still broken in this version as well.

Posted: **Mon Jun 27, 2022 4:52 pm**

what is Routing/GMP?
EDIT: just found the wiki page.. never heard of this before
https://help.mikrotik.com/docs/display/ ... t+Protocol

Posted: **Mon Jun 27, 2022 4:58 pm**

Group Management Protocol(GMP)

Posted: **Mon Jun 27, 2022 8:41 pm**

ac2 upgraded to 7.4beta5.

Posted: **Tue Jun 28, 2022 3:45 am**

What's new in 7.4beta5 (2022-Jun-27 10:39):
*) dhcpv4-server - placed option 53 as the first one in the packet;

FYI this is necessary for Google Nest Doorbell (Battery) to work, as ROS 7.3.x changed the DHCP options order and the Google doorbell refuses DHCP offers if option 53 isn't first.

Alternatively if you have this issue you can drop back to ROS 7.2.3.

Posted: **Tue Jun 28, 2022 10:03 am**

So a more complete changelog for 7.4beta5 would be this: viewtopic.php?t=186583#p942098 + this:
*) container - (!)ALL CONTAINERS FROM THE PREVIOUS BETA WILL HAVE TO BE RECREATED, due to the changes below, sorry about that;
*) container - fixed pulling remote images to internal storage, now they get pulled in the destination set as "tmpdir" in /container/config;
*) container - implemented workaround for sudo issues;
*) container - environment variables changed syntax, "list" is now "name", "name" is now "key":
so this from 7.4beta4: /container/envs/add list=pihole_envs name=WEBPASSWORD value="mysecurepassword"
became this in 7.4beta5: /container/envs/add key=WEBPASSWORD name=pihole_envs value="mysecurepassword"
(!)settings don't get migrated to the new syntax, so please export the settings before updating to beta5;
*) container - memory limit can only be set via WinBox (container->config), it is not visible in an export, sorry about that, we'll try to fix it in future releases;
*) container - fixed adding comments;
*) netwatch - fixed on-down script execution;
*) netwatch - fixed visibility in CLI and config export;
*) winbox - added container support;
What did I miss?

Posted: **Tue Jun 28, 2022 11:11 am**

For me these changelogs are just too non-informative.

already in beta4 changelog

*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;

Then again in beta5

*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;

They apparently added docker support twice. Niceeee. Twice is better than once. Always good to have a spare docker. Quite an efffort to add the support two times, even if supporting docker once would be sufficient.

And if this is true, that the simple line

*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;

actually means this:

So a more complete changelog for 7.4beta5 would be this: viewtopic.php?t=186583#p942098 + this:
*) container - (!)ALL CONTAINERS FROM THE PREVIOUS BETA WILL HAVE TO BE RECREATED, due to the changes below, sorry about that;
*) container - fixed pulling remote images to internal storage, now they get pulled in the destination set as "tmpdir" in /container/config;
*) container - implemented workaround for sudo issues;
*) container - environment variables changed syntax, "list" is now "name", "name" is now "key":
so this from 7.4beta4: /container/envs/add list=pihole_envs name=WEBPASSWORD value="mysecurepassword"
became this in 7.4beta5: /container/envs/add key=WEBPASSWORD name=pihole_envs value="mysecurepassword"
(!)settings don't get migrated to the new syntax, so please export the settings before updating to beta5;
*) container - memory limit can only be set via WinBox (container->config), it is not visible in an export, sorry about that, we'll try to fix it in future releases;
*) container - fixed adding comments;

Then I feel confirmed. I already criticized "Improve stability", "add support", "fix the thing", "fix all" changelog entries. They do not add any value. Such changelog entries can be in fact omitted.

But many people seem to be fine with these often misleading changelog entries. When you don't know what a "improve stability of X"-change actually improves, then every update is actually like: "maybe it may fix my issue with X. but most likely I am going to experience new issues while the existing issue with X isn't covered". So the serious workflow for an admin, who reads changelogs and decides whether to apply an update or not, is just impossible. So one just updates (a lab device) and then come here to the forum complaining, because the existing issue they had still applies - and another functionality that broke instead (please lay down your arms, "always check in lab first"-folks. Checking in lab to see if some existing issue is fixed, because changelogs a more or less blackboxes, is cumbersome too).

Posted: **Tue Jun 28, 2022 11:35 am**

Then I feel confirmed. I already criticized "Improve stability", "add support", "fix the thing", "fix all" changelog entries. They do not add any value. Such changelog entries can be in fact omitted.

Dictionary for MikroTik changelog entries:
"improved stability" = under certain circumstances the router crashed. we have made changes to hopefully prevent that. we will not tell you exactly how it crashed.
"add support" = a first attempt at supporting a new feature has been added. it likely requires several more iterations. probably it works only in commandline mode.
"fixed" = one more iteration towards a working situation has been made. please test and report. we will probably not read your report here, so make a support ticket (we like to be overwhelmed by similar tickets!)

Posted: **Tue Jun 28, 2022 12:12 pm**

Hi, haven't followed updates for a while. Are there any plans to backport wwave2 features to currently unsupported AC devices?

I think they should start by fixing wwave2 on supported products before porting it elsewhere.

Posted: **Tue Jun 28, 2022 12:35 pm**

Nothing is added twice. BETA releases always include ALL changes since last non-BETA. This is how it's always been. The reason is that when 7.4 will be released, it will have all changes from last stable

Posted: **Tue Jun 28, 2022 12:36 pm**

Dictionary for MikroTik changelog entries:
"improved stability" = under certain circumstances the router crashed. we have made changes to hopefully prevent that. we will not tell you exactly how it crashed.
"add support" = a first attempt at supporting a new feature has been added. it likely requires several more iterations. probably it works only in commandline mode.
"fixed" = one more iteration towards a working situation has been made. please test and report. we will probably not read your report here, so make a support ticket (we like to be overwhelmed by similar tickets!)

Thanks, that is actually quite close explanation.
1. Yes and that is intended, we do not want to tell people exact scenarios how to crash a device for your own good.
2. Yes, and all iterations are listed under the same changelog entry during the beta stage as often there are major overhaul or huge amount of work on the new feature.
3. Also yes, and multiple tickets actually may help increase the priority of the issue on our side.

Thanks you all for the feedback regarding the changelog, now back to the topic please.

Posted: **Tue Jun 28, 2022 12:37 pm**

Nothing is added twice. BETA releases always include ALL changes since last non-BETA. This is how it's always been. The reason is that when 7.4 will be released, it will have all changes from last stable

I wouldn't put money on this statement.
Other than that, great work! netwatch and containers are in a usable state.
Is the manual gonna be updated with the new changes to Container? or will the environment variables settings be changed back to how they used to be in beta4?

Posted: **Tue Jun 28, 2022 1:30 pm**

Thanks! most of them, if not all, are findings by @daaf (thanks, again!), I can't take all the credits ^^. I've only put them in a list.

Posted: **Tue Jun 28, 2022 2:21 pm**

Nothing is added twice. BETA releases always include ALL changes since last non-BETA. This is how it's always been. The reason is that when 7.4 will be released, it will have all changes from last stable

Not true at all. How do you then explain that change log for beta2 is much larger than beta4 and beta4 change log is larger than beta5 change log.
From what you do say beta5 should have all in beta2 and beta4.

These are only in beta5

*) dhcpv4-server - disallowed overriding message type option;
*) dhcpv4-server - log message when user option updates existing option;
*) dhcpv4-server - placed option 53 as the first one in the packet;
*) health - fixed requesting data from sensor when issuing "get" command;
*) health - fixed voltage reporting on some RBmAP-2nD devices;
*) lte - validate LTE attached IP type in MBIM mode;
*) poe - hide "poe-voltage" parameter on devices that do not support it;
*) route - expose all valid routes to route select filter from OSPF and RIP;
*) route-filter - fixed route select filter rules;
*) upgrade - ignore same version packages during upgrade procedure;
*) winbox - added "name" parameter under "Routing/BGP/Session" menu;
*) winbox - added "to-address" and "to-ports" parameters under "IPv6/Firewall/NAT" menu;
*) winbox - added support for "Routing/GMP" menu;
*) winbox - added support for "veth" interface types;
*) winbox - fixed "inactive" flag naming under "MPLS/Local Mapping" menu;
*) winbox - fixed minor typo under "Interface" stats;
*) winbox - fixed units for "reachable-time" parameter under "IPv6/ND" menu;
*) winbox - removed "TLS Host" parameter from "IP/Firewall/NAT" menu;
*) winbox - removed duplicate signal strength column under "Wireless/Registration Table" menu;

These are both in beta4 and beta5

*) container - added support for running Docker (TM) containers on ARM, ARM64 and x86;
*) netwatch - added support for more advanced probing;
*) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

These are only beta4 changes: According to statement above all these are removed from beta5???

*) defconf - fixed default configuration loading on devices with WifiWave2 package;
*) dhcp-relay - fixed DHCPv6 relay forward and reply creation (introduced in v7.1.3);
*) dhcp-server - change "vendor-class-id" matcher to generic option matcher;
*) dot1x - fixed "undo" command for server instances;
*) l2tp - improved stability when establishing l2tp-ether connection (introduced in v7.3);
*) leds - fixed GPS LED configuration on LtAP LTE kit;
*) leds - fixed LTE signal strength LED configuration on LHGG LTE kit;
*) leds - fixed LTE signal strength LED configuration on LtAP LTE kit;
*) lte - added AT chat support for Dell dw5821e modem;
*) lte - fixed LTE interface running state after modem reconnection;
*) mqtt - fixed socket error handling;
*) ovpn - fixed "called-station-id" RADIUS attribute value for OVPN server;
*) ppp - do not fail connection when trying to add existing IP address to address list;
*) ppp - log warning message when remote IP address can not be added;
*) route - changed "mode" setting to "exclude" for group management protocol (CLI only);
*) route - made export run faster on tables with a large number of dynamic routes;
*) routing-filter - added origin matcher to match for example routes of a specific OSPF instance;
*) routing-filter - made "do-jump" work in select rules;
*) ssh - fixed host key generation (introduced in v7.3);
*) switch - fixed multicast flooding when HW offloaded bridge port gets disabled;
*) system - fixed configuration reset with "run-after-reset" with file stored on ramdisk;
*) upgrade - improved RouterOS upgrade stability with attached USB modem on MIPSBE, SMIPS and MMIPS devices;
*) w60g - improved interface initialization after being inactive for a while;
*) winbox - fixed filename dropdown value filtering;
*) x86 - fixed Broadcom NIC support;

Posted: **Tue Jun 28, 2022 4:15 pm**

Please stay on topic. Deleting offtopic now

Posted: **Tue Jun 28, 2022 5:21 pm**

Please stay on topic. Deleting offtopic now

OK, but what is the answer to my question. You do say that every new change log do show all added stuff since main release. My post clearly that what is sad, does not add up.

Posted: **Tue Jun 28, 2022 9:54 pm**

RB760 iGS

switch -> L3 HW Offload

it is some mistake?
or 750gr3/760igs will be "special" in small device category ?

Posted: **Wed Jun 29, 2022 12:13 am**

Chateau 5G comfortably running 7.4beta5

Posted: **Wed Jun 29, 2022 12:35 am**

RB760 iGS

switch -> L3 HW Offload

it is some mistake?
or 750gr3/760igs will be "special" in small device category ?

https://help.mikrotik.com/docs/display/ ... p+Features

Bridge HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.

Posted: **Wed Jun 29, 2022 5:35 am**

https://help.mikrotik.com/docs/display/ ... p+Features

Bridge HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.

vlan filtering is L2 feature, and yes, i was glad when MT enabled this option on mt7621

but question was about L3 HW offload ?

Posted: **Wed Jun 29, 2022 7:20 am**

RB760 iGS

switch -> L3 HW Offload

it is some mistake?
or 750gr3/760igs will be "special" in small device category ?

That looks like a visual issue in WinBox. RB760 iGS does not support L3 HW Offloading.

Posted: **Wed Jun 29, 2022 9:10 am**

Please stay on topic. Deleting offtopic now
OK, but what is the answer to my question. You do say that every new change log do show all added stuff since main release. My post clearly that what is sad, does not add up.

Because you are missing the point. Only new features repeat. Fixes do not.

Posted: **Wed Jun 29, 2022 9:49 am**

That looks like a visual issue in WinBox. RB760 iGS does not support L3 HW Offloading.

all my hopes are gone now :(
i was excited that after L2 HW, small 750/760 will be gifted with L3 HW like big brothers

tnx for reply

Posted: **Wed Jun 29, 2022 11:51 am**

Because you are missing the point. Only new features repeat. Fixes do not.

Change notes should be put on a dynamic website where you can query "what has changed between version X and version Y", with a link to that website in the forum release topics and the same query being made from the "check for upgrades" function of the router (where it will show changes between the version you are currently running and the offered version).
That will end all confusion and will make maintenance much easier. Nice project for a trainee or intern: make a database where all published change notes are stored and a query that returns a list similar to what we have now. Requires no RouterOS knowledge so any developer can quickly get started on this.

Posted: **Wed Jun 29, 2022 1:00 pm**

For strods, emils and normis:

Please on beta6, or any new version, start another topic.

I'm expecting, from this topic, the experience of users, and eventually problems encountered and how solve that.
All related only to latest beta, and not other version, container or wifiwave2 package (that have more than one topic already present)

This topic has been made perfectly useless and difficult to consult,
because users, instead of exposing the problems encountered on the beta,
do nothing but uselessly comment,
give useless suggestions in this context,
philosophize among themselves as if it were a chat,
and asking for new things here, instead of opening or using existing dedicated topics.

Thank you.

Posted: **Wed Jun 29, 2022 4:56 pm**

Please keep this forum topic strictly related to this particular RouterOS release.
Not strictly related:
viewtopic.php?t=186623

Posted: **Wed Jun 29, 2022 4:56 pm**

MikroTik staff:

Please change back the internal description of .npk file from generic-for-all-platform "system" to specific "routeros-<platform>" as before,
on this way on Netinstall is possible distinguish the files on list AND on The Dude is possible again to do updates,
because The Dude search (rigtly) "routeros-<platform>" inside internal description and not only "system"

viewtopic.php?t=186576

Thanks.

Posted: **Wed Jun 29, 2022 10:00 pm**

Hello

wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces

How to use/test 802.11r ? Do you need to configure MESH for use this?

Posted: **Wed Jun 29, 2022 10:13 pm**

scroll back to reply #115

Posted: **Thu Jun 30, 2022 7:18 pm**

DOM/DMM still not work at my RB760iGS ... with ROS V6 it work fine

Posted: **Fri Jul 01, 2022 12:35 am**

scroll back to reply #115

thx :)

Posted: **Sat Jul 02, 2022 3:28 am**

Not sure if this is specific to the RB1100AHx4 or not, but when enabling the container functionality in device-mode, power cycling doesn’t successfully enable it. Using the reset button does, but this isn’t going to work well for remotely deployed devices.

Posted: **Sat Jul 02, 2022 4:51 am**

Same trouble. mipsbe

Mikrotik this morning sent me an internal test version and it has fixed my issue - no more VPLS crash.

Posted: **Sat Jul 02, 2022 10:31 am**

Anyone managed to find a better way to use the data provided by netwatch (status, since etc) I currently only had successful results with something like this:

:local currenthost $host;
:local comment [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=comment];
:local status [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=status];
:local since [/tool/netwatch/get [find where disabled=no and host=$currenthost] value-name=since];
:log info "netwatch: $currenthost ($comment) is $status since $since";

Not the best way to do it, if you have multiple monitored hosts with the same IP it will obviously fail to work properly.
I've tried to use $host directly in the get commands but it only works for one host, once you start adding the same script for other hosts it fails to work for every host.

Posted: **Sat Jul 02, 2022 10:56 am**

Not sure if this is specific to the RB1100AHx4 or not, but when enabling the container functionality in device-mode, power cycling doesn’t successfully enable it. Using the reset button does, but this isn’t going to work well for remotely deployed devices.

The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.
But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.
Remember doing "/system reboot" is not the same as hard power cycling the device. Doing a software reboot this way would not work, but power cycling should work.

What I was a bit disappointed about was that enabling the feature using the reset button on the RB4011 actually did reboot the router. It was my impression that RESET simply is a software button used to control config erasure and in this case was used for this device-mode thing, but it seems it is actually a CPU reset as well. Or its handling is coded in such a way that pressing the button does a hard reboot. I expected the router to just remain running when using the button to enable the device mode.

That hard reset may not be so desirable, especially because the button (contrary to other devices) is easy to press and does not require fiddling with a pin.

Posted: **Sat Jul 02, 2022 11:47 am**

Anyone managed to find a better way to use the data provided by netwatch (status, since etc) I currently only had successful results with something like this:
snip...
Not the best way to do it, if you have multiple monitored hosts with the same IP it will obviously fail to work properly.
I've tried to use $host directly in the get commands but it only works for one host, once you start adding the same script for other hosts it fails to work for every host.

Have you tried it wit a foreach where $i is containing the .id? This way you can read multiple values in one go, sequential. Not having to do a new find for each value.

Bye

Update, try this if will display the information. About Epoch, there are scipts to convert that, it would be nicer if MT would create [:toepoch and [:todate for us.

{
 :foreach i in=[/tool/netwatch find] do={
   :set $host    [/tool/netwatch get $i host ]
   :set $comment [/tool/netwatch get $i comment]
   :set $status  [/tool/netwatch get $i status]
   :set $since   [/tool/netwatch get $i since ]
   :put "Netwatch: host $host ($comment) is $status since $since";
 }
}

Bye

Posted: **Sat Jul 02, 2022 11:55 am**

I didn't go that far.
I was expecting that using $host $status and $since in the scripts for the current host will work, apparently it doesn't, $host returns the host, $since returns the time in unix time and unusable, and $status shows nothing.
Using the .id probably works but I haven't found a way to get the .id for the current host that the current on-up or on-down script runs.

Posted: **Sat Jul 02, 2022 1:43 pm**

That hard reset may not be so desirable, especially because the button (contrary to other devices) is easy to press and does not require fiddling with a pin.

It seems to me that when changing device mode, command itself actually installs some kind of command file which executes at boot time ... but gets removed either after time out or when executing reboot/shutdown command. So "surprise" reboot is necessary and either reset (via button) or power cycle should do. However, my own experience is as well that power cycle doesn't do it, could be due to some flash controller/drive write cache which flushes with reset button but doesn't before power is cut (tried on arm device and mipsbe device, fails in both cases).

Posted: **Sat Jul 02, 2022 3:11 pm**

Maybe you need to wait a little longer before doing the powercycle? It could be that the flash is flushed every 30 seconds or so.
I did not yet test what happens when I push the button on the 4011 without having done the device-mode setting. It really would not be so good when it does a hard CPU reset as that button may well be accidentally hit.

Posted: **Sat Jul 02, 2022 3:23 pm**

Maybe you need to wait a little longer before doing the powercycle?

Could be. When I tried it, the delay between device mode set command and power cut was around 30 seconds if not more as devices were not in the same room as management chair. But even if it's a matter of delay, it should either be improved (so that no additional delay is needed) or clearly documented.

Posted: **Sat Jul 02, 2022 7:49 pm**

...not in the same room as management chair.

Ok, this expression must be worth something !!

Posted: **Sun Jul 03, 2022 1:41 pm**

The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.

That’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.

But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.

There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.

Posted: **Sun Jul 03, 2022 2:52 pm**

The entire reasoning behind this feature is that it should not work for remotely deployed devices! It should only work for devices with a physical operator present at the device.
That’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.

It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be able
to further take it over for their malicious purpuses entirely using commands on their remote session. So it requires an operator with physical access to
do some major mode changes. Container is just one of them. Consult the appropriate documentation.

But of course, when you have powered your device from a network controlled power distribution device where you can remotely toggle the power, it would still be possible.
There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.

Others have reported it as well. It looks like a bug that should be fixed.

Posted: **Sun Jul 03, 2022 5:39 pm**

Mikrotik this morning sent me an internal test version and it has fixed my issue - no more VPLS crash.

VPLS has been broken for a long time in ROS7, I've disabled it and switched to VxLAN which has been working well so far (and it's easier to use too).

Posted: **Sun Jul 03, 2022 9:24 pm**

> *) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

If 802.11r is enabled (`security.ft=yes`) some devices can't reconnect to an AP after the latter gets rebooted. In my case it was an iPhone with iOS 15.5. Logs show the following:

mac-address@wifi2 rejected, can't find PMKSA
mac-address@wifi1 rejected, can't find PMKSA
mac-address@wifi2 rejected, can't find PMKSA
mac-address@wifi1 rejected, can't find PMKSA
mac-address@wifi2 rejected, can't find PMKSA
mac-address@wifi1 rejected, can't find PMKSA

The device connected to the AP as soon as `security.ft` was set to `no`.

Posted: **Mon Jul 04, 2022 4:10 am**

VPLS has been broken for a long time in ROS7, I've disabled it and switched to VxLAN which has been working well so far (and it's easier to use too).

VxLAN makes more sense in a datacenter environment where you want to interface with virtual machines. MPLS and VPLS and SR-MPLS make more sense in the service provider space.

To me the big advantage of MPLS and VPLS is the decoupling of the MTU setting from IP, so that you don't end up with devices creating IP frames larger than 1500 bytes for things like management traffic, but are still able to provide for layer 2 tunnels to transport 1500 byte packets or larger (in case customers want to run Q-in-Q over the circuit).

Posted: **Mon Jul 04, 2022 3:38 pm**

Is there a way to make new netwatch with http-probe do its probes via https?

Posted: **Mon Jul 04, 2022 6:46 pm**

> *) wifiwave2 - added initial support for roaming (802.11r) between local AP interfaces;

If 802.11r is enabled (`security.ft=yes`) some devices can't reconnect to an AP after the latter gets rebooted. In my case it was an iPhone with iOS 15.5. Logs show the following:

mac-address@wifi2 rejected, can't find PMKSA

This looks like the PMKSA generated as last step of EAPOL (which in 802.11r is kept by the client to be reused for future (re)associations with the same AP, skipping time consuming 802.1X EAP) gets lost on AP reboot. If the client tries to reconnect with the cached PMKSA, it is not known to the AP anymore and it "can't find PMKSA".

Posted: **Mon Jul 04, 2022 6:53 pm**

Yes that is of course what is happening. What is not so clear is why that would result in "some devices can't reconnect to an AP".
I would think the AP would send an appropriate errormessage and the clients would then go through the complete authentication cycle instead of using the fast PMKSA.
It looks like this does not work correctly in this version...

Posted: **Mon Jul 04, 2022 9:26 pm**

I would think the AP would send an appropriate errormessage and the clients would then go through the complete authentication cycle instead of using the fast PMKSA.

Yes, obviously that is what's going wrong.
According to 802.11r, it is not based on error codes, but by the AP initating a full IEEE 802.1X handshake if the PMKID in the STAs (re)association request is not known:

"If a non-AP STA in an ESS has determined it has a valid PMKSA with an AP to which it is about to
(re)associate, it includes the PMKID for the PMKSA in the RSN information element in the
(Re)Association Request. Upon receipt of a (Re)Association Request with one or more PMKIDs, an AP
checks whether its Authenticator has retained a PMK for the PMKIDs and whether the PMK is still valid.
If so, it asserts possession of that PMK by beginning the 4-Way Handshake after association has
completed; otherwise it begins a full IEEE 802.1X/EAP authentication after association has completed"

Seems like a bug were the AP fails to do so, at least for iOS 15.5 STAs.
But this information should be enough for MikroTik to reproduce the issue.

Posted: **Mon Jul 04, 2022 9:49 pm**

That’s a short-sighted approach. Devices are increasingly being deployed in situations where a physical operator will almost never be present. Having to physically go to a remote site to replace hardware is one thing. Having to do it to enable a software feature is another.
It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be able
to further take it over for their malicious purpuses entirely using commands on their remote session. So it requires an operator with physical access to
do some major mode changes. Container is just one of them. Consult the appropriate documentation.

The is a very good reason to strongly advise the operator to secure the device properly. It isn't a good reason to require the operator to physically travel hours to a site after they have already secured it. Ensuring that the means to secure a device properly is the responsibility of the vendor. Locking the operator out of the proper operation of the device because the vendor supposedly knows better is another matter entirely.

There’s the problem right there. This device is being controlled from a network-controlled power distribution device (PoE off of the management switch) and hard power cycling the device doesn’t change the device mode like it should.
Others have reported it as well. It looks like a bug that should be fixed.

Definitely. In the meantime, I'll continue looking for a workaround for the "feature" above.

Posted: **Mon Jul 04, 2022 10:49 pm**

It is well motivated by security concerns. The feature was introduced to prevent people who had some way obtained remote access to a router to be able
to further take it over for their malicious purpuses entirely using commands on their remote session. So it requires an operator with physical access to
do some major mode changes. Container is just one of them. Consult the appropriate documentation.
The is a very good reason to strongly advise the operator to secure the device properly. It isn't a good reason to require the operator to physically travel hours to a site after they have already secured it. Ensuring that the means to secure a device properly is the responsibility of the vendor. Locking the operator out of the proper operation of the device because the vendor supposedly knows better is another matter entirely.

This feature is not intended to protect the operator that knows how to secure a device properly. It is intended to protect the "unpack, plug-in, use" type of operator that uses the device in a home network.
Also, there is a long history of security vulnerabilities in RouterOS (and of course in almost every kind of software) that has affected MikroTik routers whose operators thought they had sufficiently protected their device (although that usually wasn't really the case; they may have set a strong password but they e.g. allowed admin access from the internet).
The result has been that MikroTik routers are in large botnets where they are used to DDoS other users and be a stepping stone to attack networks behind those routers.
The device-mode feature was added to protect routers that have been hacked from becoming part of a botnet.
(of course in the current state it does not accomplish that, it requires more releases where e.g. the default mode setting is more restricted than it is now)

Posted: **Mon Jul 04, 2022 11:21 pm**

This feature is not intended to protect the operator that knows how to secure a device properly.

The thing is, with RouterOS, even the most knowledgeable sysadmin is not in full control of the container host. If there's any possibility that a rando could get a rogue container onto your router, the possibilities for mischief are immense.

Notice that most of the mitigation options aren't in the sysadmin's hands. In some cases, we can see that MikroTik cannot have addressed all of these paths, as with the inter-container communication item: sometimes, the router's admin may want that.

Until RouterOS + WinBox become as complex as Docker Desktop, exposing every last twiddly configuration item, I don't think it's reasonable to expect that RouterOS containers are fully secure by default.

And if we ever do achieve that extreme level of configurability, it will ipso facto allow people to misconfigure it.

I for one am glad containers aren't enabled by default, and that it requires hands-on access to enable them.

Posted: **Tue Jul 05, 2022 11:43 am**

RouterOS v7.4rc1 has been released

viewtopic.php?t=187351

MikroTik

v7.4beta [testing] is released!

v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!

Re: v7.4beta [testing] is released!