Thank you for pointing this out. I have noticed these “duplicates” before, but the one regarding the device-mode CPU fix particularly caught my attention, as I had already reported this bug to Mikrotik and tested the fix in version 7.17.2. Could someone clarify why identical changelog items are listed multiple times, especially within the same stable branch? Does this serve a specific purpose? This way of presenting changelogs can be confusing for users who are upgrading. For instance, someone concerned about device mode might think the fix is only in 7.18 and choose to upgrade unnecessarily, even though it was already resolved in 7.17.2.
Duplicates (already contained in 7.17.1 or 7.17.2):
*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
*) device-mode - fixed feature and mode update via power-reset on PPC devices;
*) disk - fixed showing free space on tmpfs (introduced in v7.17);
*) disk - improved system stability when SMB interface list is used (introduced in v7.17);
*) dns - do not show warning messages for DNS static entries when they are not needed;
*) hotspot - fixed an issue where extra "flash/" is added to html-directory for devices with flash folders (introduced in v7.17);
*) sfp - improved system stability with some GPON modules for CCR2004 and CCR2116 devices;
*) smb - fixed connection issues with clients using older SMB versions (introduced in v7.17);
*) switch - fixed dynamic switch rules created by dot1x server (introduced in v7.17);
*) system - fixed a potential memory leak that occurred when resetting states after an error;
*) bgp - improved system stability when printing BGP advertisements;
*) bridge - fixed endless MAC update loop (introduced in v7.17);
*) dhcpv4-server - fixed lease assigning when server address is not bind to server interface (introduced in v7.17);
*) igmp-proxy - fixed multicast routing after upstream interface flaps (introduced in v7.17);
*) ipsec - fixed chacha20 poly1305 proposal;
*) ipsec - fixed installed SAs update process when SAs are removed;
*) ovpn - added requirement for server name when exporting configuration;
*) ppc - fixed HW encryption (introduced in v7.17);
*) queue - improved system stability when many simple queues are added (introduced in v7.17);
*) resolver - fixed static FQDN resolving (introduced in v7.17);
*) system,arm - automatically increase boot part size on upgrade or netinstall (fixed upgrade failed due to a lack of space on kernel disk/partition);
*) winbox - show warning messages for static DNS entries;
Kinda related to the discussion we had over there: Why are threads for previous major releases being locked?
Short version:
- 7.17 released, developers start working on 7.18 dev/alpha/beta
- bug is discovered, fixed in 7.18 dev, fix is put in changelog of 7.18 as “fixed after 7.17”
- bug is decided to be important enough and easy-to-backport enough, it is backported into a hotfix for 7.17
- hotfix 7.17.2 released, including fix, so fix is put in a changelog
Think of the hotfix “third number” versions as branching to the sides of the main development train, so needing their own changelogs.
7.18.nothirdnumber comes after 7.17.nothirdnumber, not after 7.17.2.
I have a problem, after updating to 7.18 voltage reporting shows 0V
At 7.17 it worked just right
[admin@MikroTik_Switch] > system/routerboard/print
routerboard: yes
board-name: hEX PoE
model: RB960PGS
revision: r2
serial-number: HD1086861FK
firmware-type: qca9550L
factory-firmware: 6.48.6
current-firmware: 7.18
upgrade-firmware: 7.18
[admin@MikroTik_Switch] > system/health/print
Columns: NAME, VALUE, TYPE
NAME VALUE TYPE
0 voltage 0 V
1 temperature 61 C
mhh… i have an issue since 7.17, percent variables in branding maker doesn’t transform anymore, leading my branded skins like this:
Since MikroTIk mods are now locking prior RC threads.
now that 7.17 is “stable”. Will MikroTik return their focus on routing and switching? When will you all realize your identity as a company and become laser focused on software quality. Need to better align your focus and priorities - figure out what MikroTik’ identity is. Become laser focused on producing quality software releases. The hardware isnt the problem - MikroTik has quite good hardware engineers [routing, switching] Wireless still needs work [cost cutting on sheilding and antenna designs].
Fork ROSE to separate project for a MikroTik NAS. Work on separating management, control-plane, processing. it’s wild to see bug fixes for “ROSE” in v7.18 stable. This should be a separate package release and its own focus.
Why are you still bringing storage technology into RouterOS? Yeah, brb - I’ll go convert my NAS to a router, and my Router to a NAS.
I just upgraded to 7.18 and now it’s stuck in a boot loop 
why?
I can’t even hit DEL or Control+E
I feel as if the testing portion of releases is a bit lacking
RouterBOOT booter 7.18
CCR2116-12G-4S+
CPU frequency: 2000 MHz
Memory size: 16 GiB
NAND size: 128 MiB
Press Ctrl+E to enter etherboot mode
Press <delete> key within 2 seconds to enter setup..
loading kernel... OK
setting up elf image... OK
jumping to kernel code
Starting...
Starting services...
stage2_loader v3.63.2
Memory repair completed within 226 uSecs
DDR ECC static poisoning address: (0x1e0000)
DDR ECC static poisoning address: (0x1e1100)
SPD I2C Address: 52, offset 0000(0)
DRAM ch 0: 8GB
SPD I2C Address: 53, offset 0000(0)
DRAM ch 1: 8GB
DRAM total size: 16GB
Executing next at 0x01000000!
agent_wakeup v3.53
RouterBOOT booter 7.18
This is a simplified explanation of how a Version Control System (VCS) works: you make a bugfix commit on the main branch and then cherry-pick that commit to the next patch-release branch. However, this is not the right way to write changelogs. I don’t know of any software that writes changelogs like this. It doesn’t make sense, especially for someone who reads the changelog in the stable branch in chronological order.
Would you be happier if instead of “What’s new in 7.18 (2025-Feb-24 10:47):” the caption would say “Version 7.18 (2025-Feb-24 10:47). Changes since 7.17:” ?
I got past the boot loop after some effort and power cycling 
Did a fresh net install to 7.18 and formatted the hard drive. It boots with no config 
First thing I noticed is that the PPP profile now needs a queue statement with 2 values.
Why break our configs with silliness like that?
ver 7.17.2 and below
add bridge=router-bridge bridge-port-vid=30 change-tcp-mss=yes name=private-encryption use-encryption=yes use-upnp=no [b]queue=default[/b]
ver 7.18
add bridge=router-bridge bridge-port-vid=30 change-tcp-mss=yes name=private-encryption use-encryption=yes use-upnp=no [b]queue=default/default[/b]
Second thing, this is what was probably causing the initial boot loop was enabling IGMP snooping. I tested it on the clean install and kernel panic!
add name=router-bridge comment="Site Master Bridge" frame-types=admit-only-vlan-tagged ingress-filtering=no port-cost-mode=short protocol-mode=none pvid=4094 igmp-snooping=yes
From the RIF log:
Feb/24/2025 17:35:19 system,error,critical router was rebooted without proper shutdown, probably kernel failure
Feb/24/2025 17:35:19 system,error,critical router was rebooted without proper shutdown, probably kernel failure
So be careful out there if you’re using IGMP snooping on v7.18
No, that would just be window dressing. If I upgrade from 7.17.2 to 7.18, I want to see the changes at a glance - specifically compared to the exact previous stable version. I don’t want to have to extract every changelog line from multiple patch versions (e.g., 7.13 had 5 patch versions). As I mentioned earlier, changelogs are meant to be read chronologically. If I upgrade from, say, 7.14.2 to 7.18, I want to be able to read the changelog from 7.14.3 up to 7.18 in order, without constantly encountering repetitive or duplicate changelog entries.
This changelog item is in 7.17.1 changelog, but is not in 7.18 changelog. So it is either a fluke in changelog of 7.18 or it is not contained in 7.18 at all.
ipv6 - fixed an issue where bridge, IP, IPv6 and discovery settings were lost after upgrade due to conflicting IPv6 properties (introduced in v7.17);
It’s unlikely that anything about the changelog will change at this point. But now, back to the topic. Since this time the testing cycle was extremely short (just 1 week of RC phase), I’ll at least wait for 7.18.1 this time - if not 7.18.2.
How to use IPv6 dhcp-relay? need some detail document, Thx.
What does this fix?
*) tile - improved system stability;
Is it about using PPPOE-CLIENT with the cable port, causing intermittent UP/DOWN of all ports?
WARNING: Do not install this on RB450G or HAP AC2
Both has been repeatedly bricked, and even brick directly after restoring backup config onto freshly netinstalled 7.18
I am rolling back to 7.17.2 and will wait for the next release
It’s working on hapac2
I just had an odd crash on my RB5009 after I removed a Cake Queue Type that was assigned to a disabled rule in the Queue Tree, after removing the Queue Type the system crashed immediately. After that I couldn’t boot the system anymore and NetInstall was necessary.
grusu, vivoras, pe1chl, Miyuki, Albirew, icosasupport - Thank you for your report, we will look into this!
Chaosphere64, ksoze, szaboistvan007, xgalsax1, Wyz4k - Please send supout file from your router to support@mikrotik.com
Everyone #1 - Please remember now and always - if you did find a bug, report it to the support@mikrotik.com. Send supout files and any other materials that might be useful. This is a user forum and even though we monitor version release topics, support@mikrotik.com would be the proper channel for reporting bugs. Especially when these topics so often go off-topic.
Everyone #2 - Please do not turn this version release topic again unrelated to the release itself and talking about how changelogs might be better, testing might be better, etc. Please open new forum topics for such discussions and let us keep these release topics related to RouterOS not management. If not for us, then at least for other colleagues users.
Everyone #3 - Each and every RouterOS release is well tested in countless setups, tests and different router models. However, routers are like levers with millions of possible setting combinations, and not just settings to make things even more interesting - router models, used algorithms, connected devices, etc. If you experience problems, then most likely the problem on your device appeared because “a combination of things” caused the issue. For example, a single specific network packet from some unusual/unpopular network client can call processes on the router which can not be simply simulated or predicted. This is how any software is developed - we do our best and after release find out about unpredicted edge cases. Please report these cases to support@mikrotik.com so we can improve as smoothly as possible. If you report them already within beta/rc stage, then we can address them before the stable release, but no lab in the world will be able to simulate everything.
I am glad MT has added CEF to the logging with UDP/TCP and ISO8601 time format, but it seem that this is the only changes and the logging mess do continue. http://forum.mikrotik.com/t/logging-prefix-is-a-mess-sup-105353-sup-144261-waiting-for-mt-to-support-rfc-5424/111067/1
Repeatedly I asked for fixing the double name in beta and RC, still not fixed. It do add some unneeded bytes to all package.
How CEF message are created:
2025-02-25T06:38:34.986+0100 RB951-test
Cef version CEF:0|
Device Vendor MikroTik|
Device Product RB951Ui-2HnD|
Device Version 7.18 (stable)|
Device Event Class ID 65|
Name dns|
Severity Unknown|
[Extension] dvchost=RB951-test msg=serial\=5581045XXXX MikroTik: done query: #194 settings-win.data.microsoft.com. 51.104.136.2
2025-02-25T06:38:34.986+0100 > RB951-test > CEF:0|MikroTik|RB951Ui-2HnD|7.18 (stable)|65|dns|Unknown|dvchost=> RB951-test > msg=serial=5581045XXXX MikroTik: done query: #194 settings-win.data.microsoft.com. 51.104.136.2
Look at this message:
2025-02-25T05:33:10.918+0000 RB951-Jobb CEF:0|MikroTik|RB951Ui-2HnD|7.18 (stable)|10|> system,clock,critical,info> |Very-High|dvchost=RB951-Jobb msg=serial=5581045C386A MikroTik: ntp change time Feb/25/2025 05:33:10 => Feb/25/2025 05:33:32
Here Name field should be Clock or NTP.
What in the hell does critical,info mean.
- This is severity field and should be in Severity place of the CEF message.
- Is it Critical or Info, It can not be both.
Severity= Unknown for DNS is wrong, it should be Informational, not Unknown.
Lets hope 7.19 will get this correct.
The %version% and %host% variables are deprecated and are no longer supported.
Sorry for the inconvenience caused.
https://help.mikrotik.com/docs/spaces/ROS/pages/69664784/Branding
Client (CubePRO) 7.12.1 → upgrade to 7.18. Client does not boot