Nice, this could be helpful in some extremely rare configs…, whereas Zerotrust cloudflare tunnel for all users would have so much more utility, but then again the programmers would actually have to do work vice simply inject a conversion schema into the mix.
If the backup/export file did not contain date, I would like to have a tool to compare files. Then if new backup file is different from previous file, send the backup file externally.
Zerotrust cloudflare tunnel is commercial product…why should MT involve this …it is not open source like zerotier…
I remember having seen a Youtube video explaining Cloudflare Zerotrust tunnel. Apparently that already works.
You can already use CF Zero Trust tunnel via Container.
Anav is just trolling. It will not be “built into” RouterOS.
hex… base64… base32… url…
Did you use the scripts I made as a base??? :lol: :lol: :lol:
“url” should likely encode spaces…
:put [:convert from=raw to=url "plus for space = no"]
plus for space %3d no
Perhaps to=urlencoded be better term than to=url? IMO, a “url” implies it might help with “fixing” URLs, but it will urlencode even the chars in the protocol stuff:
:put [:convert from=raw to=url "http://example.com?myval =854"]
http%3a%2f%2fexample.com%3fmyval %3d854
As an enhancement, the “url” should take an array to give you a value “querystring”, so IDEALLY this be possible:
:convert from=raw to=url {“my num”=843;“my str”=“i love spaces”}
my+num=843&my+str=I+love+spaces
Ah, not, with that error… haven’t used my scripts…
" " (space) must be encoded with “+”
From:
http://forum.mikrotik.com/t/rextended-fragments-of-snippets/151033/1
Only 4 characters - . _ ~ must not be escaped, and space must be replaced with +
I am not trolling, your answer makes it crystal clear you are ABANDONING all users without arm64 processor.
The semi-stolen script inject into RoS, is a small very niche case that is going to be used by what, .005 percent of MT owners???
Whereas, I personally read posts everyday of people with Servers on their LANs, probably safe to say approx 50% of MT users.
Furthermore, you would be forcing users to also learn containers and if they are having any scan/probe firwall issues and make a mistake the container will make them more vulnerable.
The Cloudflare approach negates opening up the public IP and ports to the world and simplifies the port fowarding for beginner to intermediate users for sure.
I understand it may not be an RoS core code option (not on the planning tree), but it could be put in an options package for all users.
When you show me some logic, Normis, I will be all ears. Until then, you are only creating disillusionment and lack of trust in your word and confirmation of a biased outlook.
We can do a teams/zoom/skype/discord chat if you want to keep your corporate dirty laundry out of the forum
Be it technical or whatever, I am assuming the above is not true and you have good reasons, but I have not seen anything yet to dissuade me from the above discourse ~~~
- Container feature needs a powerful CPU and plenty of RAM.
- ARM64 is a natural requirement to resolve these requirements
- All new products have ARM family chips, so this is our direction going forward
- It takes a lot of human resources to support other architectures for CPU hungry features.
Another :convert one…
is “F09FA4AC” in UTF-8 as “hex”
But I’d expect “%F0%9F%A4%AC” not
from this:
:put [:convert from=hex to=url "F09FA4AC"]
The problem with containers usually is not the CPU and RAM, but the nonvolatile storage. That tends to be tiny in MikroTik routers.
There are only very few models that have M.2 slot, and the alternative of USB3 is disappearing as well.
(I bought a CCR2004-16G-2S+ reading on the spec sheet that it has USB3, but in reality that is no longer true)
ROSE storage works surprisingly well to mount a disk for a container when the router doesn’t have the internal storage or USB/M.2/etc…
But the issue is they still sell platforms that are not ARM – KNOT and LtAP specifically. So there isn’t even a container (nor zerotier) on these…
Back To Home then …
As I said, this is not providing service its forcing customers in a certain direction, why do I feel MT is run by Elon Musk… ![]()
Usually one wants containers on the router to add some niche functionality to the network that is as independent as possible from other hardware.
When using ROSE storage, there presumably is an NFS mount from some NAS, but often those NAS devices provide containers themselves.
I have considered loading a container image in RAMDISK, but it would be preferable when the router config has better support for that.
(to download the image every time the router is booted)
I was going to try this…
https://youtu.be/KO9wbarVPOk?t=209
Another :convert one…
is “F09FA4AC” in UTF-8 as “hex”
But I’d expect “%F0%9F%A4%AC” not
from this:
:put [:convert from=hex to=url "F09FA4AC"]
Not…
is at least “\F0\9F\A4\AC”…
and at least must be “from=utf-8 to=url”…
or… [$UTF8toURLencode (“\F0\9F\A4\AC”)]…
so, it’s still too early to retire my functions…

Don’t worry I think it will be a while to work through the possible matrix in :convert. There does seem to be an unused to-scheme= and from-scheme= in the new :convert, so signs of future expansion…
Dealing with building the querystring from array, and json be useful for /tool/fetch. e.g. I’m hoping for a “:convert from=array to=json” and vise-versa…
Not…
is at least “\F0\9F\A4\AC”…
and at least must be “from=utf-8 to=url”…
The UTF-8 emoji was for fun. It’s still just a “hex string” and the bytes should be the % version if to=url since it’s NOT a text conversion and should just encode what’s given in the hex if it’s unsafe URL char… e.g. any extended/unsafe lower ASCII should be % encoded, regardless of the underlying text encoding…
Basically I think the “:convert $something to=url” seems buggy. But :convert with various text encoding would useful too, and seemingly possible in this new scheme.
Anyway happy with the progress in this area!
The possibility to use SSH Keys based on ed25519 would be a nice Feature addition ![]()