v7.13beta [testing] is released!

Please keep this and other version topics related to the particular version. Issues that were present in older versions should be reported to support@mikrotik.com and/or discussed in separate forum threads. These forum topics are created in order to find “what got broken”. There is no need to repeat the same reports on every release, even though any relevant fixes or changes are not listed in the changelog.

I tried to upgrade my rb5009 from 7.12 to 7.13beta1 but I get the following error:

/system/package/update> install 
            channel: testing
  installed-version: 7.12
     latest-version: 7.13beta1
             status: wifi-qcom-ac-7.13beta1-arm64.npk missing, use ignore-missing or disable package(s)

FC:AB:90:E7:AE:VB@wifi2 roamed to FC:AB:90:E7:AE:VB@wifi1, signal strength -66
Well, it’s works ok.
Updated Hap ac2.

Thanks for the reply, but I don´t understand what that exactly means? Maybe you can explain?
All VLANS are configured in the CAPsMAN only via “Configuration → Datapath” and it seems to work:


It´s working with all my CAP AX devices in the same manner (all 7.12). Actually it looks like a “cosmetic” error only…but I will test the VLAN functionallity on the AC device later…

I don’t think it’s a good idea to automatically install wireless package on chr. Having multiple WiFi / Wireless menus in winbox after installing the wireless package is extremely confusing.

Very impressive! Upgrade worked on my RB1100AHx4-Dude test box. Looking forward to testing Wave2 support on 16MB ARMs — that was a welcome surprise – I’d given up on that long ago.

The new :serialize and :deserialize caught my eye — JSON support has been lacking for a decade and seems to work in initial testing:

{
  :local arr {a=1;b="abc"}
  :local json [:serialize $arr to=json]
  :local arrFromJson [:deserialize $json from=json]
  :put "serialized json: $json"
  :put "deserialized json:"
  :put $arrFromJson
  :put "type of deserialized json: $[:typeof $arrFromJson]"
}

But perhaps the :[de]serialize should default the to= and from= to “json”. While I like the optimism for more “serializers”, default values are helpful & there is just one to/from format, RN…

Now also upgrade from ARM64 routers with installed wifiwave2 package should work. Sorry for any inconvenience caused.

Tested with RB5009, AX3, cAP ax. Everything works fine for now. This is quite a large number of changes, good work guys.

Few questions, PPSK maybe ?? :smiley:

And now on my CAPsMAN controller in WiFi menu i dont have any more that interfaces are controlled by capsman but on CAPs I have that. This is something new ?

Grep is nice, but please make it as a pipe argument. Like

/interface/print | grep anything

Or like “utility” on IOS XR

show run | utility egrep ....

*) ovpn - improved memory allocation during key-renegotiation;

After over an hour of extensive testing, forcing key renegotiation every 60 seconds, I can state that the memory leak issue related to OpenVPN key renegotiation has been fixed. Thanks to the Mikrotik team and to Oskars who responded to my support ticket regarding this problem.

New :grep command crashes console when invoking with the following pattern


:grep script="system clock print" pattern=".*"

I know this pattern does not make any practical sense here but it crashed the console repeatedly with high cpu usage. The command used doesn’t matter, it happens on every command used.

screenshot.png
just4info

#edit# Bug is fixed in RouterOS 7.13beta2

just done a lab test on the isis and so far so good, thanks mikrotik team for this

Why? NAT-PMP was already obsoleted by RFC6887. It would’ve made more sense to implement PCP, which is also usable in 464xlat, NAT64 and MAP-T.

Thanks Guys… all working here
flat-snoop :slight_smile:

qrt-ac with 128mb…
will have a try

Already included in 7.12.

There is no “pipe” as it the CLI isn’t a Bourne-based shell, that part is to be expected…

But I would have guess the command is:
:grep [/interface/print as-value] pattern=“."
but that actually causes the console to CRASH — with the ".
”, just using “.” works without a crash.

Ignoring the “.*” crash, :grep is still pretty funky in how it work AFAIK… e.g. :grep runs a command provided and uses the terminal output from that command based on pattern=… So while this works to search the command’s output, and prints the results to terminal (without a pipe needed & there is “as-array” options to use in script)
:grep “/interface/print” pattern=“.”

BUT… this “grep runs a command string” logic means to search a file, which you’d typically associate with grep, requires a :put…which is kinda strange in the current CLI scheme (but works):
:grep “:put [/file get myfile contents ]” pattern=“.”

Also there is a “filename=” attribute but that’s for OUTPUT, which isn’t entirely clear. It be nice if the was some in-file= or out-file= (not particular on names, but way to use files directly on INPUT be nice)

Anyway :grep a bit confusing, since it’s neither the file-based UNIX screme… or even RouterOS script, since you’d kinda expect :grep to take RSC string to parse, not a command to exec (which in RouterOS usually require the [cmd as-value] syntax…

It seems what is happening here is that "wireless" was part of the "routeros" package in versions 7.x up to 7.12, and when you now upgrade to 7.13beta it doesn't bother to check if you were really using any wireless functions, and just installs the "wireless" package that has now become separate.
But you can just "uninstall" it and remove some functions.
Unfortunately not all, because "the necessary utilities for WiFi management are now included in the RouterOS bundle." as it is written in the release notes.

I welcome the partial split into separate packages as we knew it in v6, but maybe the "WiFi" menu should go into a separate "wifi" package so we can uninstall that as well.

+1, it’s a mess currently
2023-11-13 at 18.41.17.png

Handling of output and redirection has always been funky… hopefully they will now sit down and fix that.

I expect any command like set $name [/some/command/print] to set the variable to the output of that command without printing that output on the console. I.e. that […] is capturing the output and returning it for storage in the variable.
But it does not work that way, at least not for all commands and options. There are awful hacks like as-value which do not work combined with other options like count-only.
That really should be cleaned up!