Could version 7.25 mark the moment of the most radical enforcement of configuration attribute compliance?
From what little I’ve gathered so far about the MikroTik landscape—specifically the relationship between RouterOS and WinBox—my understanding is as follows:
WinBox retrieves a data model from the RouterOS instance it connects to; based on this model, it establishes preliminary validation rules enforced by the graphical interface.
Over the years, hundreds (perhaps thousands) of exceptions to this method have been created and hard-coded somewhere within this ecosystem—most likely inside WinBox itself.
P.S.: If these assumptions are incorrect, please help me understand how it actually works—ideally by pointing to public documentation on the subject.
So...
When you combine the fact that version 7.25 now mandates WinBox version 4.3 (or higher) for access...
With the message from @prawira in the WinBox 4.4 thread—where he described how WinBox 4 prevented him from entering a range attribute with positions in reverse order...
I found myself thinking:
Given that they are adopting a stricter methodology and enforcing a minimum WinBox version...
Wouldn't this be the perfect opportunity to clean up all those hard-coded if statements [2] and ensure that every configuration input method strictly adheres to the exact same attribute validation data model contained within RouterOS? Essentially clearing out the clutter and hard-coded exceptions...
Of course, there is a risk of touching a sore spot.
"Semi-incorrect" configurations—which users have been copying and pasting for years and which have worked fine all this time—might stop being accepted and instead trigger error alerts.
But I believe that by getting rid of all those hardcoded conditions, both RouterOS and Winbox4 itself will tend to become leaner—while also gaining overall consistency across all configuration input methods.
I don't agree in the "details" but I also see a lack of unified input validation. I always was quite confident that WinBox "does it" differently than CLI. a lot of "winbox" changelog items in most ROS releases. new features often cli-only. So the "brain" is probably ROS and Winbox is just a mvc like gui software. downloads the "model" from the router, builds "view" dynamically. And also does some own "if statements" (copyright fisherdouglas) in the Winbox controller. et voila!
RouterOS does that today, it's just a question of when from the POV of WinBox. Improving validation before apply in WinBox is what seems to be improving, since you could type something "invalid" that did not show up in red in many place.
But I'm not sure I've seen a case where if you hit "OK"/"Apply" in WinBox, you don't get an identical message to the CLI, with the same inputs from WinBox. So the only question is if Apply/OK is disallowed "early", which historically that has not been the case for all fields. Now open someone might be able to prove me wrong, but AFAIK the improvements are about what appears "in red" before OK, but validation of a actually change (via OK/Apply in Winbox, or enter in CLI, or "request" in REST) is the same regardless of protocol used (REST/API/SSH/WinBox/WebFig).
And, I think folk find that WinBox enforcement after OK/Apply closely tracks what CLI reports in "F1" help, for example:
/ip/address/add address=F1
Address -- Local IP address
Address ::= Address[/Netmask]
Address ::= A.B.C.D (IP address)
Netmask ::= IpNetmask | Num
Num ::= 0..32 (integer number)
IpNetmask ::= A.B.C.D
There still is the very grave bug in newest RouterOS + newest WinBox that when you have a configuration item that inherits values from a higher level, e.g. in BGP you configure a connection with Template and Instance, the values inherited from the higher level get COPIED into the item when you change something else.
You can remove the items in the config screen and they will remain inherited, but it is not as it should be. Inherited values should be displayed in a different color, and should not be saved unless they are altered in the item as well.
This also affects the WiFi settings where there is configuration per interface but also global configuration profiles. This bug has existed since v7 was introduced (for BGP) and since new WiFi was introduced.
Thanks for finally giving the poor little trailing dot some love.
It may look like a tiny detail, but it’s actually pretty fundamental DNS behaviour. That little dot tells the resolver that the name is an absolute FQDN, so it shouldn’t start appending search domains to it.
Unfortunately, yes. I just re-tested it with WinBox 4.4 and RouterOS 7.25beta5.
You can already see when you save the item that it now includes the inherited values in the log line, and indeed they then appear in the export as well.
WinBox already knows when you have changed some item, because then it changes the title to blue instead of black. It should only save the items that you changed, so in the log line you see only those. That would be an improvement for other reasons as well.
Yeah, but nobody is going to type a trailing dot after all their DNS names, and it is really useless that every DNS name is searched both bare and with the "search domain(s)" appended to it. It should only have been done when a name without embedded dot is entered.
And it is not only useless, it is a potential information leak when an external domain has been configured as the search domain, e.g. the domain of the ISP.
Fortunately it is not something that RouterOS supports, it only happens in end systems maybe based on the "domain name" offered in a DHCP network.
Entire protocols can rely on this.
Proxy auto-discovery is one example.
CAPWAP discovery, as well as many discovery mechanisms for SIP proxies and voice gateways.
Even domain controller discovery in an Active Directory domain.
In fact, any protocol capable of using DNS-SRV will first perform lookups via search domains if no specific FQDN has been declared for the query.
So, "getting rid of them" would break a lot of things... especially in corporate environments.
As said, it should only have been done when the requested name has no dots in it, and it should not have been a part of the generic DNS resolver but be implemented in those applications that require it.
Just like "path search" is not part of the generic execv() system call but only of the execvp().
Just noticed /tool/bandwidth-test (using the neterra btest server) causes a immediate router crash in beta5. Reported it as SUP-225003. Is it a me-issue or can anyone confirm?
What device did you use?
There are any device that can use hardware offload for btest? (this would be new for me)
I just did the test with a hAP AX s. No crash.
I have done it using Winbox4.4, tcp, udp, receive, send, both... all combinations... no crash.
What I Notice was when udp, traffic was zero... But it is probably related to something else.
Nobody's saying people should type a trailing dot after every DNS name. The point is that when an absolute name is used, ROS should understand standard DNS syntax.
This isn't about search domains. The trailing dot is standard DNS syntax for the root label, and RFC 1034 3.1 calls such names absolute. ROS has no search list, so it already treats "host.example.com" as absolute, and "host.example.com." is the same name in canonical form. Returning "bad name" is a parser bug, not a design choice, so rejecting that form is a regression that breaks existing scripts.
And that is exactly where it bites us. Our config manager and network monitor run scripts on the routers through the API, and some of them use absolute FQDNs. We were lab testing ahead of an upgrade, and all of a sudden ROS just started rejecting them.
With all the DNS regressions and fixes lately, basic standards-compliant DNS is something we need to be able to count on.
Anyways, great to see a fix listed in 7.25beta4, though we haven't tested it yet.
