Here is a quote from our manual - “Converts specified value from one format to another. By default uses an automatically parsed value if the “from” format is not specified (for example, “001” becomes “1”, “10.1” becomes “10.0.0.1”, etc.)”
You can easily see which value will be actually be used with a simple test like this:
{
:local a 001
:put $a
:put [:typeof $a]
}
{
:local a 1.0
:put $a
:put [:typeof $a]
}
This will be the type and value of the input argument if you do not specify the “from” parameter. However, since “convert” does not support the “num” format at the moment, it will use the from value as “raw”.
I had the same problem, because it´s a little bit tricky.
You have to configure the “Slave Datapath” in the CAP menu on the CAP itself:
Additionally you need to configure the physical wifi interfaces on the CAP as managed by capsman:
The result for me is exactly what you also want, dynamically added “virtual” wifi interfaces added to the local bridge on the CAP with the correct VLAN ID:
*) certificate - fixed trust store CRL link if generated on an older version (introduced in v7.7);
*) console - improved stability when canceling console actions;
*) ike2 - fixed ECP521 DH group usage (introduced in v7.11 beta1);
*) lte - fixed R11e-LTE6 “EARFCN” reporting format (introduced in v7.11rc1);
*) ssh - fixed SSH key agreement on the client side when ed25519 used under server settings;
*) wireguard - fixed peer IPv6 “allowed-address” usage;
Yeah the num type to/from hex is common one that does come up sometimes, so be good to see that at some point.
As feedback,
the “raw” type is confusing “at the moment” — it really seems to mean a string with unknown encoding. Maybe that’s right, just think “raw” means an unknown type also, not an unknown encoding. Maybe to=raw shouldn’t even be valid, dunno…
“:convert from=raw to=raw” always converts to a string type, even if the input was num/ip/ipv6/etc and to=raw – guess I was expecting that to be noop (no conversion applied) and return the input as the output.
e.g. in the extreme,
:convert from=raw to=raw 1.1
IMO should be returned as an “ip” typeof with value of 1.0.0.1. Right now, it’s a string “1.0.0.1”.
And, fair enough…while extremely subtle… “:convert 001 to=hex” = “31” does illustrate what happens… just disagree what should happen.
hope that @strods will show this post to mr Oskars K. from ticketing portal [SUP-121761]
maybe ticketing stuff will be less arrogant next time
it was stated in every 7.10 ++ forum topic that WG IPv6 with non /64 allowed address will break on certain platforms
after sending 2 .rif (7.9.2 vs 7.11) mr Oskars have very negative attitude
I’ve finally updated from 7.7 to 7.11rc1 & rc2, and while it looks like the openvpn problems have been fixed, I’m experiencing lots of sfp problems.
A lot of sfp ports flapping that didn’t happened neither with 7.7 nor with 6.xx versions.
And since updating to rc2, the SFP interface with my DAC (XS+DA0001) between my CRS328 and my RB5009 doesn’t go up automatically anymore. I need to connect to the CRS328 and disable/enable the sfp interface after each reboot to make it work.
7.11rc2 broke iBGP for my office CCR2116 as an rr-client to my two RR’s (2011’s running 7.10rc4). It was working on 7.11b6 and 7.11rc1. Fortunately I had 7.11b6 saved to disk. Unfortunately there’s not a way to get 7.11rc1 back from the website.
We are very sorry if you felt offended in some way. However, I do not see why. You were just asked few additional questions in a polite manner which you did refuse to answer. Yes, the problem was not - wireguard does not work with any IPv6 allowed addresses. Particular addresses and specifi routers had to be used. After you declined to answer, we luckily managed to find that information and fix the issue.
i saw that all old beta forum topics are erased
i reported few time when v7.10 betaX started to show, that WG with IPv6 and non /64 suffix have a problem
in 7.11beta topic there was also another user with same observation, and i clearly remember that he has ticket number also
in previous posts i was clearly show configs, tracert, and errors reported by ROS when one try to use WG with non /64 on various platforms
all these post was ignored by MT staff
and then, when i had enough of ignorance, i filled the bug report with all data and RIFs to trace bug
few day of silence, then question …
it was obvious that no one take seriously bugs reported in forum (at least 3 time, two different user) and that staff from ticketing portal is not aware of similar bug reports
so, it is annoying that we, users, help MT to debug they OS, for ex WG / IPv6, which is broken in last XX releases ( and will break again ) with different behavior on different platforms and our rewards is silence or ignorance
at least answer what i expected was: yes, we read forum posts, we are aware of problem, tnx for RIFs, will try to reproduce …
To everyone! Please remember - this is a user forum. Report bugs to support@mikrotik.com immediately, if you are sure that the issue you have is a bug. This will get things done much faster!
Because 90% of problems are due to user ignorance, and often with the help of forum users they are fixed.
Then there’s the 2% that users persist in reporting on the forum, instead of to support@mikrotik.com.
The remaining 8% are not problems related to any of the previous aspects.
