Changelog Question

Hi All,
Is anyone aware of the different meaning of ! and * in the change log entries.
Below is an example the first 2 entries start with ! but the rest start with *
Does this mean different things?
Thanks
Mark

What’s new in 7.14beta10 (2024-Feb-06 15:47):

!) rose-storage - moved SMB service in the RouterOS bundle;
!) smb - removed legacy SMB service (replaced with newer and faster ROSE SMB service);
*) arp - added ARP status;
*) console - improved stability when using autocomplete with “export”;
*) defconf - fixed configuration script on KNOT devices if “ppp-out” interface is removed;

Yes, ! is important change. The rest are sorted by order

I see clear now!

*) defconf - fixed firewall rule for IPv6 UDP traceroute;

Wasn’t important change. :+1:

or back in 6.49.7:

*) system - improved handling of user policies;

Wasn’t important as well.

:+1:

At least these lines are IN changelog.

Every line in there is important to somebody. Every line is a fix or a new feature that somebody was waiting for.
We incude !) with lines that you should pay special attention to, if some config has changed or a new menu has appeared. It is not meant to say one fix is better than another fix.

All changes are equal, but some are more equal than others

Sound to me like: “you can be glad that we even list changes in the changlog, ingrateful user!”

Of course any line is of interest. But why is a change to a default firewall rule not a special attention required?

Here some samples of changelog entries that are of interest, but do not require special attention by a major audience, because they are informative and require no user-intervention. Mostly any entry “fixing a bug” is not of any special attention. Users that experience bugs and wait for a fix - they look out for their bugfix changelog entry.

You need to read/see a changelog from the point of view: imagine you are the device admin. You read the changelog to see what you can expect from the update. The positive aspects (bugfixes, features) as well as the negative aspects (breaking changes) and really important changes (security related) when you can’t postpone the update.

*) supout - added PTP section;
*) leds - added "dark-mode" functionality for hAP ax3 and Chateau ax series devices;
*) leds - fixed modem LED indication for SXT LTE 3-7 (introduced in v7.13);

But there are changelog entries, they are in fact “breaking changes” (behaviour changes, call it how you like). An example:

*) fetch - require "ftp" user policy;

Of course this may affect not the majority of users, but this change broke scripts of several users. Just a regular change - not special attention required according to the “*” marking.

*) defconf - fixed firewall rule for IPv6 UDP traceroute;

Just informative? No diff. How should someone know from this changelog entry, that a potential firewall leak was closed? It isn’t marked as “!” nor does it communicate the severity or the actual change. Just “fixed something”. Could be an inefficient rule as well or a non-working rule. The rule was working, but it was too loose. Kind of important. don’t you think?

*) system - improved handling of user policies;

I like to take this example from 6.49.7. Because I think it shows the root problem of these changelogs. Though the issue, that was fixed here, required admin rights on the device, and normis compared it to “thats like rooting your own phone when you already are the owner”.

No it is not.

With 6.49.7: some bad person can have/gain admin rights and any change this user/admin makes is getting logged. Of course the user can “wipe” the traces by flushing/clearing the log and history. But if you have remote logging you would realize. And even then, the admin is limited to make ROS “allowed” changes to the system. Can mess up configs and so on. But once you identify the intruder, you change the password or disable the user and restore a config-backup. Done.

Before 6.49.7: one with admin user can gain access to the underlying system. Can place any binary on the device and make it run as a service. Can be of any type. Used to spy on your network or even hijack the device for a botnet.
All we possibly would see in log if at all: “user x logged in from IP”. maybe that’s all the traces we would see. But system compromised. No reset-configuration helps. Netinstall the only way to decontaminate. But how should we know about this dramatic severity? We can’t - because it was disguised in a “improved handling” changelog entry.

I hope you get the feel for it now.

In other words, usually changes with “!” describe that behaviour will change in the RouterOS after an upgrade. For example, here SMB is removed from one package and mover to other one. As for the importance of fixes - yes, they are indeed all equal. Because what is something very important to someone, is irrelevant for someone else. We do not judge what is important and what is not - simple alphabetically sorted changelog.

But why is a change to a default firewall rule not a special attention required?

I don’t understand why you think this change is somehow more important than others.
Default config does not change operation of your device, does not make new entries in your config and does not introduce new menus.

Because it required manual intervention by the device admin. Any other change is: “ah, ok. good to know. Thanks for letting me know. Hit upgrade button and done”

The firewall rule change is like: “dear user. If you ignore this changelog line, you won’t ever get the updated firewall rule. you live on with the old one”

You should have your own firewall. The change affects the default one, which is loaded onto a new device or after reset. It is only the base template and every responsible admin should secure their network manually.

Normis, I do not disagree. I know I argued this way in another topic (auto-update the firewall rule).

It boils down to: changelog entries are too vague. They are all equally important and forget the ! and *. I need to read the changelog line by line and judge for myself. But the entries lack the necessary details to classify their importance for myself.

Is it really on purpose and your intention to skip the details first. But then someone asks on forum and sometimes there is a response.

e.g. http://forum.mikrotik.com/t/v7-13-5-stable-is-released/171923/806

Isnt that a waste of time and resources? Now we know the details to a single changelog line. It is available as a comment in the forum. But the next user reading/reviewing the changelog at https://mikrotik.com/download/changelogs won’t get that information.

Yes, that are downfalls of analog changelog, that it is limited to the special symbols (with only few exception) , on another hand it makes it more simple as different colours, different topics would make it more comprehensive.
In case there is a better way for the current changelog, we are always open to consideration.

It would be helpful when there was a separate commend/button to “reset firewall to default” (for IPv4 or IPv6) without having to reset the entire config to default.
Of course this includes actions that the firewall depends on, like creation and populating the interface lists that the firewall started using at some point.

We quite often see people fight with firewall problems, either due to having an old default or having experimented with the rules without understanding them, that are easily fixed by just resetting them to defaults. But asking the user to reset the entire device to defaults is often a step too far.

Actually it would be good to have option to “reset to defaults” any configuration subsection. In 7.13 ability to reset /interface/wifi to defaults would be welcome for all WiFi5 devices previously running legacy wireless driver.

Actually, it does exist.

interface/wireless/reset wlan1

Just tested on mAP with 7.14b6. It works.
But … nowhere to be found in the documentation.

Great. But the command name is non-descriptive. Does it reset all the profiles as well?

??
There are no profiles with legacy wireless ?
Or are you referring to legacy capsman here ?

I’m saying that reset to defaults would be great … and I’ve only mentioned wifi as an example why other parts of config (apart from firewall) would benefit from it as well. One case is to get anything (other than nothing and disabled interfaces), the other case is to start over with configuration … but not everything, just a specific part of config. Which in case of wifi means removing profiles etc. …

Ah, I see, it was more a conceptual remark.
I fully agree there.