So you can simply forget the idea of seeing web app connect via MAC to your ROS device.
Much the same was said about accessing cameras from web applications… never say never.
It would really help if you stated what are your wishes/requirements from the new web app.
Unifi controller for RouterOS basically.
No it is NOT! Work is required to bring it on par. There should be multiple windows, tabs in the windows, saved settings, etc.
But there’s a very important difference, which can not be fixed by web app at all: WinBox can connect via MAC. And many users use WinBox because this function was a deciding point (when using it for one reason, one can use it always).
There should be a simple small portable MikroTik app (program) that you can run to:
- netinstall devices
- put config in new devices
- and: listen on a TCP port and translate actions to the MAC protocol.
Then you can connect via MAC also from a browser.
Preferably it would be open source so it can be installed on any device/OS the user may have.
Happened to be catching up on YouTube and came across this video by a staunch Mikrotik supporter with 222 videos mainly about Mikrotik - so you can hardly call him a hater but he felt compelled to release this video entitled “Things I don’t like about MikroTik…”
https://www.youtube.com/watch?v=Z2HeQ7znKBs
He covers the subject touched on above at the very end about lack of overall management.
Central (overall) management is the topic of another thread.
You know, one of those “we are considering, we want your input” and then you never hear from the product again.
Of course. As soon they realize (after reading community input) it’s gonna be a ton of work and a lot of expectations to meet. “Nah, better not”.
I sometimes wonder, considering the philosophy of Mikrotik esp. around licensing, whether an open source approach to developing web based management tools would work? I’m semi-retiring now and I’m interested in a project although that might be something completely different like a model railway. Mikrotik control the hardware (obviously) and maybe the API on the board and an enthused team develop the rest. Just an idea. If you ever met me, you’d know I’m always looking for solutions to problems and don’t like blockers.
PS. Total aside but many model railways are networked so not that radical a change.
Yes, you could certainly write a web management tool that performs all its actions via API. That basically is what winbox is doing as well. The winbox protocol and API probably have a lot in common. I think what winbox has extra is the capability to query the available commands and the corresponding dialog layout, and the icons. These are then stored in the version-dependent directory in the winbox application directory.
Unfortunately it seems that the winbox protocol itself (unlike the API) is not documented…
That basically is what winbox is doing as well.
Does WinBox effectively issue CLI commands to get/set changes?
Who knows?
I would think so. If you look at command history, it looks the same if its run from Winbox or from terminal.
No, it is more like API calls.
I would have expected some kind of API as that’s more efficient (no need to parse command line) and less prone to breaking changes.
All the config methods are abstractions over some internal config schema (see /console/inspect). So…I’m just not sure where efficiency comes in — once config change is made it’s stored internally in the same manner, regardless of the config method.
So is winbox less efficient? I guess it’s easier to have dozens of windows open (that are listen for changes), but like similar in impact as CLI+tmux+ssh with dozens of “print follow” running in background. But compared with continuous CPU needs of WG/IPSec/BGP/etc., configuration changes/monitoring is not very significant.
In terms of “breaking changes”, that’s the job of crossfig to migrate any config on upgrade to newer attributes. If that doesn’t work right, it’s a bug. But again how those changes got made, does not affect how they might break later.
Also think this has gone a bit off-topic…
Just saying,sweet to be able to have multiple winbox windows open, viewing rules being tripped, logs filling, sniffing ongoing, connections tracking shown etc…
Well, as people have noticed, when you use winbox to view some configuration in a panel, you change one or two items and hit OK, it will set ALL the configuration in that panel. Probably the same in webfig.
When using commandline, you would only set the items that you are really changing.
But, that is just a “winbox bug”, that could be fixed with some additional code in winbox. After all, it knows which items you have changed.
As someone who has noticed this behavior and already complained elsewhere: of course it is a bug IMHO. Mikrotik may see it differently.
I think winbox has always done this. It just only recent the attributes were logged, so it more visable.
But don’t forget that winbox does update attributes if changed elsewhere. So if a dialog box is open, and CLI changes something in it, winbox will reflect the new value within seconds. So chance of saving stale data is minimal.
Now should it log all them? Probably not.
Winbox, IMHO is the secret sauce, allowing non CLI trained folks to access and modify their configs and view all kinds of information. I had no RoS or CLI or networking training but do use Terminal from time to time as required and basic scripting as well. So CLI is just a fingertip away in winbox. Its a really decent gui and would leave MT if they took it away and would go back to zyxel or something similar. The ease of which I can view multiple devices and winbox over VPN, is really sweet. By the way, to troubleshoot a config, I read the config file, dont use winbox for that.
I do use winbox to view sniffs, connection tracking, actual routes,. traffic status, pinging of sites, etc.. ( and to see if any config issues are pointed out ( via colour or symbol indications, warnings ).
Agreed. If you BOTH CLI and winbox, or have potentially multiple users making updates, it is really well integrated. e.g. the “live update” of winbox dialogs is actually quite powerful and does avoid stale writes. I use both CLI and winbox, since it often easier to view things in winbox, but make changes in CLI.
It really is just the recent logging of attribute changes that’s caused confusion. And tend to agree that it should only update dirty fields and logs only those changes.
Now whether the log is message is even correct about the actual operation, IDK — it may just dump all the attribute in the dialog and the “set *XX” is just a log readability thing, not the actual command & internally only update changed ones. But even if updates all, they should all still be current when saved because of winbox’s “live update”.