Please also add unbound (1.24.2) app…
Not yet.
Side note, you need to set channel:
/system/package/update/set channel=development
This is actually great improvement since MikroTik is actually using the "empty" channel= for something! Now we can only hope this allow things to stay in "testing" longer before being called "stable" and one step closer to filling the long-term channel... 
.
Well spotted, that can handle multiple things including caching SSL GSLB etc
i wonder if at some point Mikrotik will surprise us with a NGFW based on ROS Containers ^^
/routing/bgp/instance documentation at /routing/bgp - RouterOS - MikroTik Documentation says:
| multipath (integer [0..4294967295]; Default: ) | BGP will pick configured amount of routes with similar attributes and install ECMP routes. |
|---|
However this is incorrect, multipath can only be set to “yes” or “no”.
It seems to work correctly, i.e. it sets ECMP routes for paths which evaluate to equal cost.
Since the kernel 7.x uses is behind mainline, I’m sure it’s just merging in/backporting whatever improvements have been made to mainline.
Upgraded my home/office router from 7.19.1 to 7.22b1 and the containers wouldn’t load (couldn’t load config.json it says). I’ll try upgrading the secondary partition from 7.19 through 7.20 and 7.21 to see if that is a necessary set of steps.
I upgraded a test CHR that I have via 7.21rc4 to 7.22b1 and apps (containers) continue to run fine.
Any chance that this is related to WPA3 and/or PMF?
I tested WPA2+WPA3 mixed mode for some time, but ended up switching back to WPA2-only mode with PMF disabled to get rid of stability issues.
Going from 7.20.6 to 7.22b1 also did not work. So there’s something between 7.20 and 7.22 that has to happen for containers to properly migrate. The error specifically is that it couldn’t load the config.json file.
I had this issue when I’ve downgraded RB5009 from 7.21beta to 7.20.5, only repulling container helps ( it was pihole)
Uhuuuul!
Development and Testing channels looks to be finally running to a correct use.
I don't even remember when the dev channel was used last time.
Thanks!
Basically yes
I'd add Bind9 DNS and ISC DHCP to that list....
I still wanna know who picked what /app contains to include... Nearly every release thread has various complaints about /ip/dns and yet someone thought these were more important:
# NAME CATEGORY DESCRIPTION
0 X adventurelog productivity AdventureLog is a travel blog and photo journal web application
1 X babybuddy productivity A buddy for babies! Helps caregivers track sleep, feedings, diaper changes, and tummy time to learn about and predict baby's needs without (as much) guess work
[...]
among other...
Perhaps /app/setup and /app/setting set disk=... should support XFS too. Currently /app restricts you to only btrfs or ext4.
hell yeah! enabled this option for the instance and now RR seeing routes with ECMP, but the logic of sending "active" route from RR is still strange for me, it select the first one from the ECMP and use only it. Will dig it deeper tomorrow, so tired for today =]
ISC DHCP isn’t supported anymore. They have a new DHCP server but I have no experience with that. While ISC DHCP was very powerful, I don’t think it has that many advantages over RouterOS DHCP, except maybe one thing, which I have suggested as a new feature for RouterOS some time ago: the capability to run a script at DISCOVER time that can determine whether the server should reply at all, and that can control things like which Pool is to be used for the request, what lease time to offer, etc. That script can then e.g. match on part of the MAC address for that. This is different from the current “lease script” which is called after the lease has already been given out.
As this beta version includes several things that I have suggested before (hooray!) maybe we will see that appear as well… would be nice.
BIND, well, it is the DNS server I am most familiar with, and it would be nice to have, but in a router where it has the role of resolver with maybe a couple of static records, and has to conform to modern oddities like DoH, DoT etc I think unbound is a better choice.
Agree in part. My thought was for testing compatibility with "Linux-things"... it be handy to just /app/enable . I'm just behind the times on what modern Linux uses for DHCP server ;-<. Although I'd add dnsmasq to that list.
My broader point is the focus seems on application servers, instead of network services - which is odd for a router.
In that vane, the categories seem kinda random/not useful. I'd rather see some organization around "listen ports" (/etc/services) like "DNS servers", "Web Servers", "Workflow Services" (nodered,n8n), "MQTT", etc. as a categories/sub-categories... then you could pick among the supported networking services, depending on needs.
And some categories seem wrongly assigned. For example, fossil is listed under "Productivity" while gitea is listed under "Development".