{ /ipv6 fire filter remove [find where comment="defconf: fasttrack6"] add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack6" :local idone [find where comment="defconf: fasttrack6"] :local idtwo [find where comment="defconf: accept established,related,untracked" and chain=forward] :put $idone :put $idtwo move $idone destination=$idtwo }For full default firewall rules:
$ diff -ruN 7.18rc2.sort 7.18.sort | grep -P '^[\-+]'
--- 7.18rc2.sort 2025-02-24 16:34:05.762863405 +0100
+++ 7.18.sort 2025-02-24 16:31:51.441714374 +0100
-*) fetch - fixed IPv6 handling in URL (introduced in v7.18beta2);
-*) file - fixed missing meta information from special files such as packages (introduced in v7.18beta2);
-*) file - hide store directories, such as container (introduced in v7.18beta2);
-*) lte - fixed R11eL-EC200A-EU modem RAT mode selection (introduced in v7.18beta2);
-*) lte - fix R11e-4G modem initialization (introduced in v7.18beta4);
-*) poe-out - added new modes "forced-on-a" and "forced-on-bt", where old "forced-on" mean "forced-on-bt" (CLI only);
+*) poe-out - added new modes "forced-on-a" and "forced-on-bt" (CLI only);
-*) poe-out - fixed invalid poe-in status detection for RB5009 (introduced in v7.18beta2);
-*) poe-out - fixed PoE-out not working on first boot after upgrade for CRS354 (introduced in v7.18beta2);
-*) qos-hw - fixed wred-threshold (introduced in v7.18beta2);
-*) wifi-qcom - fixed potentially lowered throughput for station interfaces if channel.width property is set (introduced in v7.18beta2);
-*) winbox - fixed usb power-reset bus selection for RB924iR-2nD-BT5&BG77 (introduced in v7.18beta2);
+1 - I can just feel zerotrust cloudflare tunnel, in an options package, is right around the corner. ;-), and of course amnezia wireguard in an options package.Well, I'm glad you're working on it so hard.
I think they skipped everything introduced and fixed within the same development cycle.Do I see right some of RC2 chages are skipped?
Would be very useful to have this changelog present in the last post before locking the rc thread. I agree it should not pollute the main release topic.Stable release changelog has always been a list of changes since previous stable - bugs introduced and resolved within beta/rc are not in this list.
As it should be.bugs introduced and resolved within beta/rc are not in this list.
It would be nice when new bugs introduced in a stable release would be added to the changelog (as a separate section) once they become known, so it is easier to watch for them in later releases to see if they have been fixed.Stable release changelog has always been a list of changes since previous stable - bugs introduced and resolved within beta/rc are not in this list.
It would be possible if Mikrotik had transparency level of any other vendor which is able to keep a record of known issues and would publish them as a part of release notes. Without that we have no way to know the real state of things what comes to development...It would be nice when new bugs introduced in a stable release would be added to the changelog (as a separate section) once they become known, so it is easier to watch for them in later releases to see if they have been fixed.
(and also to know beforehand that it is better to wait, e.g. when some functionality is critical for you)
$ stat --format="%n: %s" *
container-7.16.2-arm.npk: 98449
routeros-7.16.2-arm.npk: 11608772
wifi-qcom-ac-7.16.2-arm.npk: 2740369
$ stat --format="%n: %s" *
container-7.18-arm.npk: 118929B
routeros-7.18-arm.npk: 12076474B
wifi-qcom-ac-7.18-arm.npk: 2744465B
free-hdd-space: 396.0KiB
No, this is just spectacular bad communication from MikrotikAfter updating several devices, I see that this update automatically installs extra packages that were not installed on the router before the update?
Thanks for the clarification. How do we know which packages are locally hosted and disabled? I have selected the greyed out packages and after uninstalling and restarting the router they have disappeared from the list. In The Dude they also appeared as installed (That's why I noticed the "error").No, this is just spectacular bad communication from MikrotikAfter updating several devices, I see that this update automatically installs extra packages that were not installed on the router before the update?
In previous releases, "greyed" packages meant "the .npk is stored locally in flash, but not loaded at boot" (status = "disabled")
To remove them and free flash space, one would perform the action "uninstall"
from 7.18, all possible available packages are listed in greyed-out form, to be fetched "automagically" from "the clouds" if one selects "action=install"
It does not necessarily mean (as was once true), that there is a kludge of .npk 's in the local storage
I am not seeing much difference but then again I am lucky enough not to have those problems with disconnects like some others do.holvoe, can you comment on the wifi changes, good bad ugly??
Looks like Mikrotik doesn't test their releases on 16MB devices at all. My hAP AC2 has 0MB free after update to ROS 7.18 and now Ican't even reboot it... Forced will go to do netinstall...With 16Mb flash device you can only watch new release notes and cry :)= 14447590 bytesCode: Select all$ stat --format="%n: %s" * container-7.16.2-arm.npk: 98449 routeros-7.16.2-arm.npk: 11608772 wifi-qcom-ac-7.16.2-arm.npk: 2740369
= 14939868 bytesCode: Select all$ stat --format="%n: %s" * container-7.18-arm.npk: 118929B routeros-7.18-arm.npk: 12076474B wifi-qcom-ac-7.18-arm.npk: 2744465B
------------------------
14939868 - 14447590 = 492278 bytes (480.74 KiB)
Free space after 7.16.2 netinstall with imported config (not backup):Code: Select allfree-hdd-space: 396.0KiB
Ok, I see how it works. So the only problem then is that Dude shows all the packages, both installed and "available" to install.Depends which packages you've seen.
The new feature from 7.18 it works like this:
* After reboot, the list of packages contains only what is installed.
* After you run the "check online for updates" option, it not only tells you if ROS can be upgraded, but downloads full list of package names and shows them grayed out with "XA" flags (disabled, available for download).
* If you try to enable one of those, it gets downloaded.
If you saw packages with just "X" disabled flag, not "XA", those were on-disk and disabled, and that normally doesn't happen.
(Mind, good chance Dude being barely-on-life-support can't show up the new flag.)
If you saw /enabled/ packages, then it matters what old version you've upgraded from; due to split/merge of some features between the main ROS package and external ones, upgrading across some specific versions installs extra packages to make sure the feature that was there before is still available.
Main example is the legacy "wireless" package showing up even on devices without wifi.
At least this change was already in 7.17 stable:Stable release changelog has always been a list of changes since previous stable - bugs introduced and resolved within beta/rc are not in this list.
*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
...With 16Mb flash device you can only watch new release notes and cry :)
Free space after 7.16.2 netinstall with imported config (not backup):Code: Select allfree-hdd-space: 396.0KiB
Looks like Mikrotik doesn't test their releases on 16MB devices at all. My hAP AC2 has 0MB free after update to ROS 7.18 and now Ican't even reboot it... Forced will go to do netinstall...
I disagree, this bug was fixed in 7.17.2.There was a bug in 7.17 where even with device-mode locking down RouterBOARD, people were able to change the CPU frequency once.
I disagree, this bug was fixed in 7.17.2.There was a bug in 7.17 where even with device-mode locking down RouterBOARD, people were able to change the CPU frequency once.
Yes! Small think, but very helpful...thanks Mikrotik!*) winbox - fixed locked input fields when creating new certificate template;
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.
I disagree, this bug was fixed in 7.17.2.
It has been like that since forever. The changelog of the stable c.d release contains changes since the previous a.b release. Version a.b might have additional patch versions a.b.x or a.b.y that already include the same fix, but the fix will still be listed in the changelog of c.d. Just look at https://mikrotik.com/download/changelogs. For example, let's me pick some random excepts:
* Both 7.17 and 7.16.2 have *) certificate - do not download CRL if there is not enough free RAM; among others.
* Both 7.14 and 7.13.4 have *) bridge - fixed MLAG connection after peer-link flap (introduced in v7.13);
*) 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: viewtopic.php?t=215049Thank 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.
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.Kinda related to the discussion we had over there: viewtopic.php?t=215049Thank 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.
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.
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]
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
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.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:" ?
ipv6 - fixed an issue where bridge, IP, IPv6 and discovery settings were lost after upgrade due to conflicting IPv6 properties (introduced in v7.17);
Is it about using PPPOE-CLIENT with the cable port, causing intermittent UP/DOWN of all ports?*) tile - improved system stability;
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
Here Name field should be Clock or NTP.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
mhh... i have an issue since 7.17, percent variables in branding maker doesn't transform anymore, leading my branded skins like this:
Screenshot 2025-02-25 at 00-24-44 %host% - AlbiTik.png
this message is taken from RouterOS logs and goes with tags, that are assigned to specific entry, that as well displayed at /log print.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. viewtopic.php?t=124291
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:
Code: Select all2025-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:Here Name field should be Clock or NTP.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
What in the hell does critical,info mean.
1. This is severity field and should be in Severity place of the CEF message.
2. 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.
Level Severity Keyword Description
0 Emergency emerg System is unusable
1 Alert alert Action must be taken immediately
2 Critical crit Critical conditions
3 Error err Error conditions
4 Warning warning Warning conditions
5 Notice notice Normal but significant condition
6 Informational info Informational messages
7 Debug debug Debug-level messages
DeviceEventClassID Name
73 bridge,stp
16 dhcp,info
65 dns
61 interface,info
9 script,info
10 system,info,account
81 wireguard,info
23 wireless,info
DeviceEventClassID Name
73 bridge
16 dhcp
65 dns
61 interface
9 script
10 system
81 wireguard
23 wireless
Thank you for the information. Yes, SIEM was not implemented in 7.18, and still RouterOS logging format is being sent by CEF.It does not matter from where it comes from. For 10 years I have asked for cleaning up the log message from RouterOS. It will simplify use of SIEM tools like Splunk.
Default Severity:
So when you are using Critical and Info in same message, how should you know if its a big problem, or just info?Code: Select allLevel Severity Keyword Description 0 Emergency emerg System is unusable 1 Alert alert Action must be taken immediately 2 Critical crit Critical conditions 3 Error err Error conditions 4 Warning warning Warning conditions 5 Notice notice Normal but significant condition 6 Informational info Informational messages 7 Debug debug Debug-level messages
Is there a list of all "Device Event Class ID"?
Here are some:
This should be if cleaned up:Code: Select allDeviceEventClassID Name 73 bridge,stp 16 dhcp,info 65 dns 61 interface,info 9 script,info 10 system,info,account 81 wireguard,info 23 wireless,info
Code: Select allDeviceEventClassID Name 73 bridge 16 dhcp 65 dns 61 interface 9 script 10 system 81 wireguard 23 wireless
As far as I remember backup is only for same version, so you need to upgrade or do a import of config.
Try to upgrade from 7.17.2 to 7.18 instead of netinstal.
Or export config from 7.17.2 and import it to 7.18
Not confirmed, hap ac2 upgrade was successful here.WARNING: Do not install this on RB450G or HAP AC2
Both has been repeatedly bricked,[...]
> /system/resource/print
uptime: 1m26s
version: 7.18 (stable)
build-time: 2025-02-24 08:47:02
factory-software: 6.41.3
free-memory: 157.4MiB
total-memory: 256.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 597MHz
cpu-load: 1%
free-hdd-space: 268.0KiB
total-hdd-space: 16.0MiB
write-sect-since-reboot: 24
write-sect-total: 1692350
architecture-name: arm
board-name: hAP ac^2
platform: MikroTik
> /system/package/print
Columns: NAME, VERSION, BUILD-TIME, SIZE
# NAME VERSION BUILD-TIME SIZE
0 routeros 7.18 2025-02-24 08:47:02 11.5MiB
1 wifi-qcom-ac 7.18 2025-02-24 08:47:02 2680.1KiB
*) wifi - implement steering parameters to delay probe responses to clients in the 2.4GHz band;
/interface/wifi/steering/ 2g-probe-delay=yes
/container> config/print
ram-high: 128.0MiB
registry-url: https://lscr.io
2025-02-25 09:19:42 container,info,debug [cont] not ok registry auth response: 400
If the backups are incompatible it should warn that it is and simply reboot. Bricking is not an acceptable outcome.
I have emailed through the backup, a supout and the config files to support @ mikrotik . com
This works only for manually setup neighbor groupsCode: Select all*) wifi - implement steering parameters to delay probe responses to clients in the 2.4GHz band;
Code: Select all/interface/wifi/steering/ 2g-probe-delay=yes
/interface/wifi/configuration/set [find] steering.2g-probe-delay=yes
The issue is that the opening of another topic (even to add to the topic of feature suggestions) is a no-op.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.
I never do. If i see an problem i'm coming here to aware users about problem. How do we know that version specific problems if everyone send problems to closed system? I'm not gonna jump and update my devices either for unnecessary things with new bugs. That's why we need open bug tracker. Thanks god that most of users reporting problems in forum thus we know most of it..."then submit it as a ticket or mail to support"
Please write to support and add a supout.rif file.pulling images from registry-url seems to not working:
Code: Select all/container> config/print ram-high: 128.0MiB registry-url: https://lscr.io 2025-02-25 09:19:42 container,info,debug [cont] not ok registry auth response: 400
The same reason you set a password.Why is this relevant? You don't have the WinBox port (or any management port) open on an untrusted network without at least address constraints, do you?
.Got a RB750Gr3 that did not came back after update from v7.17.2 to v7.18. Will have to reach the unit for further analysis and trying to get it back online.
It was running only the core "routeros" package, no extra packages installed at all. It had hotspot enabled, which creates some files on the flash filesystem, but that's about 40-50k, not much difference on the storage usage anyway.
/interface ovpn-client add certificate=cliente-<CERT-NAME> cipher=aes256-cbc connect-to=<VPNHOSTNAME> mac-address=FE:D1:A4:68:B2:B1 name=ovpn-management password=password port=11945 user=user
Actually on my hEX-S I didn't have any issue after installing Ros 7.18, so as indicated in some post above, it's not a specific model issue, but the combination of your setup and situation.FFS Mikrotik, how could you release ROS without proper testing on MMIPS based routers which you have in constant sell! Routers which crashed has simple configuration no additional software installed. ARM and ARM64 works fine.
.
UPDATE: the actual upgrade to v7.18 seems to have completed fine, routers are online, however rebooting a few seconds after booting, and kept on this constant reboot loop. On a VERY quick troubleshoot, seems that disabling my OpenVPN management instance (OpenVPN client instance) restored the RB750Gr3 to its working condition, it's not rebooting anymore. Enabling the OpenVPN client instance makes the router crash a few seconds after VPN is established, no messages displayed on '/log print follow' however.
2025-02-25 09:18:21 ovpn,info ovpn-management: using encoding - AES-256-CBC/SHA1
2025-02-25 09:18:21 ovpn,info ovpn-management: connected
(10 seconds)
2025-02-25 09:18:31 ovpn,info ovpn-management: disconnected <peer disconnected>
2025-02-25 09:18:31 ovpn,info ovpn-management: terminating... - peer disconnected
2025-02-25 09:18:31 ovpn,info ovpn-management: disconnected
2025-02-25 09:18:31 ovpn,info ovpn-management: initializing...
2025-02-25 09:18:31 ovpn,info ovpn-management: connecting...
2025-02-25 09:18:32 ovpn,info ovpn-management: using encoding - AES-256-CBC/SHA1
2025-02-25 09:18:32 ovpn,info ovpn-management: connected
(10 seconds)
2025-02-25 09:18:42 ovpn,info ovpn-management: disconnected <peer disconnected>
2025-02-25 09:18:42 ovpn,info ovpn-management: terminating... - peer disconnected
(and router crashes, reboots, and on next connection to it I can see:)
2025-02-25 11:33:33 system,error,critical kernel failure in previous boot
.I have to report that three of my RB760 (HexS) constantly rebooting. After checking terminal i saw that last reload was caused by kernel problem. On two routers i was able to log in (routers crashing after 1 minute) download 7.17.2 and force to downgrade. They are working now. Problem is device which is very far. I don't have enough time to copy image before crash.
Yes i have OpenVPN set up. Problem is that i cant switch it off, because router is far away (like few thousand kilometer from me).I have to report that three of my RB760 (HexS) constantly rebooting. After checking terminal i saw that last reload was caused by kernel problem. On two routers i was able to log in (routers crashing after 1 minute) download 7.17.2 and force to downgrade. They are working now. Problem is device which is very far. I don't have enough time to copy image before crash.
Are you, by any chance, running any OpenVPN instance on these routers? I'm facing problems clearly isolated, to me, to a openvpn client instance on the routers. Once disabled, everything works just fine!
.Yes i have OpenVPN set up. Problem is that i cant switch it off, because router is far away (like few thousand kilometer from me)
.UPDATE: the actual upgrade to v7.18 seems to have completed fine, routers are online, however rebooting a few seconds after booting, and kept on this constant reboot loop. On a VERY quick troubleshoot, seems that disabling my OpenVPN management instance (OpenVPN client instance) restored the RB750Gr3 to its working condition, it's not rebooting anymore. Enabling the OpenVPN client instance makes the router crash a few seconds after VPN is established, no messages displayed on '/log print follow' however.
.i tried to connect to this router but it's reloading to fast and lag (250ms) is not helping. I need to configure new router and send it with older software.
Was thinking the exact same thing, not to mention installing it on devices you don't have local access to......@LordNikkon you can only cry on your own.
No matter who the vendor is, putting a newly released software into production without even testing it for a month is irresponsible.
So you did a remote upgrade on a router first day after a new release?Yes i have OpenVPN set up. Problem is that i cant switch it off, because router is far away (like few thousand kilometer from me)
I think there is some kind of buffering already. But messages can not be kept infinitely to make sure a missing log server does not cause resource exhaustion on all network devices.Regarding remote logging. Currently, if a connection between a router and log server is lost for some period, all records appeared during this period are not transferred to the server. Please consider implementing some kind of "buffering" such records, so they can be automatically transferred, when connection restores.
.I think there is some kind of buffering already. But messages can not be kept infinitely to make sure a missing log server does not cause resource exhaustion on all network devices.
I don't see any buffering. If there is no connection, records are not transferred at all. I was testing it, just made a script, that adds a test log record periodically and disabled connection for a short period. All records, that appeared during no connection period, were not transferred.I think there is some kind of buffering already. But messages can not be kept infinitely to make sure a missing log server does not cause resource exhaustion on all network devices.Regarding remote logging. Currently, if a connection between a router and log server is lost for some period, all records appeared during this period are not transferred to the server. Please consider implementing some kind of "buffering" such records, so they can be automatically transferred, when connection restores.
Yeah, but for UDP you could have an option to test its availability by pinging prior to sending. Stupid method probably, just an idea.That will be clearly easier with TCP, which syslog supports. But to my experience, UDP is much more commonly used while exporting logs.
It crashes only with AES-256-CBC. Works fine with AES-256-GCM..UPDATE: the actual upgrade to v7.18 seems to have completed fine, routers are online, however rebooting a few seconds after booting, and kept on this constant reboot loop. On a VERY quick troubleshoot, seems that disabling my OpenVPN management instance (OpenVPN client instance) restored the RB750Gr3 to its working condition, it's not rebooting anymore. Enabling the OpenVPN client instance makes the router crash a few seconds after VPN is established, no messages displayed on '/log print follow' however.
UPDATE 3: Actually it seems that as soon as some traffic hits the OpenVPN client instance, on the RB750Gr3, it crashes and reboots. On my previous test I wasn't trying to use the OpenVPN client instance, just had it connected. The 10 second interval I was seeing are likely the OpenVPN server heartbeats only. But with a ping to the IP that ovpn client instance interface will receive, as soon as it connects, RB750Gr3 crashes and reboots, it's just immediately.
Also tried netinstalling to the device, to really "clean" old updates gargage that might have been left behind, but no changes. As soon as traffic hits the ovpn client instance, RB750Gr3 crashes and reboots.
.It crashes only with AES-256-CBC. Works fine with AES-256-GCM.
2025-02-25 15:46:10 wireless,info E4:B3:18:**:**:**@wifi10 reconnecting, signal strength -68
2025-02-25 15:46:11 wireless,info 90:09:DF:**:**:**@wifi1 disconnected, not responding, signal strength -60
2025-02-25 15:46:12 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -46
2025-02-25 15:46:14 wireless,info E4:B3:18:**:**:**@wifi10 connected, signal strength -68
2025-02-25 15:51:17 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, not responding, signal strength -42
2025-02-25 15:51:31 wireless,info 90:09:DF:**:**:**@wifi1 connected, signal strength -58
2025-02-25 16:03:09 wireless,info E4:B3:18:**:**:**@wifi10 reconnecting, signal strength -69
2025-02-25 16:03:10 wireless,info 90:09:DF:**:**:**@wifi1 disconnected, not responding, signal strength -56
2025-02-25 16:03:12 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -49
2025-02-25 16:03:17 wireless,info E4:B3:18:**:**:**@wifi10 connected, signal strength -73
2025-02-25 16:08:17 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, not responding, signal strength -42
2025-02-25 16:08:17 wireless,info 90:09:DF:**:**:**@wifi2 connected, signal strength -46
2025-02-25 16:13:27 wireless,info 90:09:DF:**:**:**@wifi2 disconnected, not responding, signal strength -44
2025-02-25 16:13:42 wireless,info 90:09:DF:**:**:**@wifi1 connected, signal strength -59
Thanks for the answer.The %version% and %host% variables are deprecated and are no longer supported.
Sorry for the inconvenience caused.
[admin@ccr2116] > /ipv6/settings/print
disable-ipv6: no
forward: yes
multipath-hash-policy: l3
accept-redirects: yes-if-forwarding-disabled
accept-router-advertisements: yes-if-forwarding-disabled
disable-link-local-address: no
stale-neighbor-detect-interval: 30
stale-neighbor-timeout: 60
min-neighbor-entries: 4096
soft-max-neighbor-entries: 8192
max-neighbor-entries: 16384
allow-fast-path: yes
ipv6-fast-path-active: yes
ipv6-fast-path-packets: 0
ipv6-fast-path-bytes: 0
ipv6-fasttrack-active: yes
ipv6-fasttrack-packets: 1862750
ipv6-fasttrack-bytes: 2576286552
The behavior with the incremented prefix was always there. If the interface (bridge, vlan, etc...) gets the address with the prefix from a pool, and you make any modifications to the interface (for instance toggling IGMP Snooping on the bridge interface or changing ARP mode on a VLAN interface), the current allocated prefix is released and a new prefix is retrieved from the pool to be used on the interface.
And if fasttrack is working correctly then it's normal that the fast path counters are all zeroes. If you see non-zero FP counters and zero FT counters, then Fasttrack was not enabled correctly.
I am currenlty trying out ipv6 multicast. Is that supposed to work with ipv6 and a crs3xx switch? https://help.mikrotik.com/docs/spaces/R ... D+snooping says it should work and ipv6 should not interfere with ipv4 and ff02::1 is aways forwarded.I got past the boot loop after some effort and power cycling :O
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?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!Code: Select allver 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]
From the RIF log:Code: Select alladd 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
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
We had a 2116 that went into a boot loop. We were unable to recover it via netinstall older than 7.18I 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
There are no buffer on logging, All logs that are generated at boot are not sent since there are no network up and running. Logs will only be tried sent once, and if that does not work, they are not sent (UDP/TCP).Regarding remote logging. Currently, if a connection between a router and log server is lost for some period, all records appeared during this period are not transferred to the server. Please consider implementing some kind of "buffering" such records, so they can be automatically transferred, when connection restores.
Yes, and it is not something that can be solved easily.There are no buffer on logging, All logs that are generated at boot are not sent since there are no network up and running. Logs will only be tried sent once, and if that does not work, they are not sent (UDP/TCP).
I am pretty sure this is before wireguard connection is up, and also before OSPF established any routes. So there must be what ever kind of buffering, no?system,info MikroTik: router rebooted by ssh:eworm@10.171.215.2/shutdown
Log servers are mostly passive. To me the best course of action would be to create a memory buffer (a small one, say 1MiB) and send log messages to it. In fact, we already have: it's the "log to memory option".Probably when someone is interested in the logs after boot, they should send a trigger message at boot (have a scheduled job at startup that checks if the connection to logserver is already up, or does a simple delay) and on the logserver have some action that recognizes this message and fires a program that contacts the router using API and retrieves the log from memory.
I saw exactly the same on hap ac, 600 kb left after that. Even uninstalled packages came back after resetting the router and the reason Is I got locked by no rules. First rule in the FW filter list to filter incoming dhcp-offers disappeared somewhere. It was fine until I simplified some Address Lists (combined them) using WInBox.After updating several devices, I see that this update automatically installs extra packages that were not installed on the router before the update?
This is not really constructive.They forgot to test again, I suppose.
Can't imagine people overseeing such a thing, can you?Starting from 7.18, this list has both the packages that are installed, and those that are optional to install.
Well, I have often commented that the changelog is inadequate and should be replaced with something that has more info, links to documentation, etc.Can't imagine people overseeing such a thing, can you?Starting from 7.18, this list has both the packages that are installed, and those that are optional to install.
The device supports RouterOS software with version v7.18 or above.
.OVPN related issues are fixed, if you still have problems with this version, send us supout.
https://box.mikrotik.com/d/c2fc960065ed49b78214/
Probably only on RouterOS 7.20_ab22+ (didn't you notice the shared files versions have, and my comment)?.OVPN related issues are fixed, if you still have problems with this version, send us supout.
https://box.mikrotik.com/d/c2fc960065ed49b78214/
Great news, thanks for the quick fix on this one. Can we expect a v7.18.1 fixing this, or it will be published on v7.19 only, for example?
.OVPN related issues are fixed, if you still have problems with this version, send us supout.
https://box.mikrotik.com/d/c2fc960065ed49b78214/
.Probably only on RouterOS 7.20_ab22+ (didn't you notice the shared files versions have, and my comment)?
Thanks for telling me obvious things... I was talking about changing this behavior.There are no buffer on logging, All logs that are generated at boot are not sent since there are no network up and running. Logs will only be tried sent once, and if that does not work, they are not sent (UDP/TCP).Regarding remote logging. Currently, if a connection between a router and log server is lost for some period, all records appeared during this period are not transferred to the server. Please consider implementing some kind of "buffering" such records, so they can be automatically transferred, when connection restores.
Could you please do me a favor? Just to satisfy my curiosity.Tested ab23 and, in a quick lab test, and it solved connections issues for AES-256-CBC. I also tested AES-256-GCM and it worked just fine. Tested on RB750Gr3 only.
/system/resource/usb/print
.Could you please do me a favor? Just to satisfy my curiosity.Code: Select all/system/resource/usb/print
[admin@MikroTik] > /system/resource/print
uptime: 43m35s
version: 7.20_ab23 (development)
build-time: 2025-02-26 10:03:54
[ .... ]
architecture-name: mmips
board-name: hEX
platform: MikroTik
[ .... ]
[admin@MikroTik] > /system/resource/usb/print
Columns: DEVICE, VENDOR, NAME, SPEED
# DEVICE VENDOR NAME SPEED
0 1-0 Linux 5.6.3 xhci-hcd xHCI Host Controller 480
1 2-0 Linux 5.6.3 xhci-hcd xHCI Host Controller 5000
[admin@MikroTik] >
Just open the file with 7-zip or similar for see routeros-7.20_ab23-arm64.npk\lib\modules\5.6.3Could you please do me a favor? Just to satisfy my curiosity.
I have problem with hEX S device and RouterOS 7.18 too. In my case there is only ipsec in play, but it uses "aes-256 cbd" for Encr. too. As the router reboots it self after a while, i had to quickly downgrade to 7.17.2, will support.rif be of any use from router that has the problem, but is downgraded to 7.17.2?OVPN related issues are fixed, if you still have problems with this version, send us supout.
https://box.mikrotik.com/d/c2fc960065ed49b78214/
I have a problem, after updating to 7.18 voltage reporting shows 0V
At 7.17 it worked just right
<snip>
Starting from v7.18 can't use private HTTP registry without SSL. I've got*) container - allow HTTP redirects when accessing container registry;
*) container - allow specifying registry using remote-image property;
unexpected response from container registry: SSL: ssl: record overflow (6)
.I have problem with hEX S device and RouterOS 7.18 too. In my case there is only ipsec in play, but it uses "aes-256 cbd" for Encr. too. As the router reboots it self after a while, i had to quickly downgrade to 7.17.2, will support.rif be of any use from router that has the problem, but is downgraded to 7.17.2?
Using BTRFS's RAID finctionality in enterprise environment is a kamikaze solution. I'm curious what solution they use if there is any RAID function in it. I hope it is battery backed HW RAID controller...Yes, that would be great!
But I fear that once the Rose Data Server really hits the street, we will see lots of requests for (in itself) reasonable requests around data server functionality.
(some of them in software not written by MikroTik but becoming their responsibility when used as part of such a product. e.g. I am using BTRFS myself on my home system, and I can tell it is a REAL PAIN when you are running RAID-1 and one of the disks goes offline. It is NOT like in a typical RAID-1 controller where you can just pull the disk and plug the same or another one back in)
Thanks for the answer.The %version% and %host% variables are deprecated and are no longer supported.
Sorry for the inconvenience caused.
Is there still a way to get version number and host address from branding webpage without using rest API? maybe in /assets/script.js ?
(rest api requires login, hence my question for authless alternative usable in branded webpage)
const iconSrcDir = 'https://cdn.mt.lv/marketing/bth/folder.svg';
const iconSrcFile = 'https://cdn.mt.lv/marketing/bth/file.svg';
const iconMissing = 'https://cdn.mt.lv/marketing/bth/missing.svg';
How does 2g-probe-delay practically work and when should be used?*) wifi - implement steering parameters to delay probe responses to clients in the 2.4GHz band
dhcp-snooping (yes | no; Default: no)
Enables or disables DHCP Snooping on the bridge.
Enabling the DHCP snooping feature will turn off bridge fast-path, which in turn affects the ability to fasttrack connections going over that bridge.
Doesn't Fasttrack have to come after the connection is established or related?In regards to IPv6 fasttrack: I've enabled it based on suggestions but counters always show "0". This doesn't look normal to me. IPv4 counters works properly (as expected).
I'm on a hAP ax2 by the way and the device has been rebooted after enabling the feature.
Speculation:How does 2g-probe-delay practically work and when should be used?*) wifi - implement steering parameters to delay probe responses to clients in the 2.4GHz band
It is unclear if the RAID function uses Linux block-level RAID or the BTRFS balance profile "raid1".Using BTRFS's RAID finctionality in enterprise environment is a kamikaze solution. I'm curious what solution they use if there is any RAID function in it. I hope it is battery backed HW RAID controller...
Yes rebooted. I will try again. I believe it will repro soon.Besides marking for uninstall, was the device rebooted to complete uninstall @nipfel?
And did you create supout to inform support?
This is not really constructive.They forgot to test again, I suppose.Can't imagine people overseeing such a thing, can you?Starting from 7.18, this list has both the packages that are installed, and those that are optional to install.
Same here. Voltage 0v and working OK on 7.17.Same issue here on HexPoE - health stats in webui and cli show zero Volts. Worked with previous version.
Upgrade path - stable versions only 7.17.2 (working) direct to 7.18 (stable)
I have a problem, after updating to 7.18 voltage reporting shows 0V
At 7.17 it worked just right
<snip>
[:foreach a in=[/ipv6/neighbor find where status=failed] do={:if ([/ipv6/neigh
bor get number=$a mac-address] = []) do={/ipv6/neighbor/remove numbers=$a}}]
Here is the proof: after downgrading to RouterOS 7.17.2 again, the problem is goneI can see a massive increase in latency spikes and loss after upgrading to v7.18 on multiple CCR2004-1G-12S+2XS
Why would MikroTik need to release 7.18 to stable in order to announce the rds2216?This is what happens when MikroTik rushes a release to "Stable", they did this to themselves. Pushed it out the door so they could make the RDS hardware announcement.
file="email.backup"
[admin@ccr2116] > /interface/ethernet/switch/l3hw-settings/print
autorestart: no
fasttrack-hw: yes
ipv6-hw: yes
icmp-reply-on-error: yes
hw-supports-fasttrack: yes
OVPN still in trouble here on RB4011GS+ / ARM. aes256cbc working fine, aes256gcm results in permanent disconnects as soon as data is transmitted.
Seeing this too. I think it's due to the limitation still around how many IPv6 routes can be offloaded?Should the ipv6 fasttrack support make it as fast as ipv4 now? On my ccr2116, 10gbps on ipv4 barely shows a 1% blip, if anything, on the cpu. But the same on ipv6 seems to show up to 250% total cpu usage spread across multiple cores.
All of the hw offload seems to be enabled:Code: Select all[admin@ccr2116] > /interface/ethernet/switch/l3hw-settings/print autorestart: no fasttrack-hw: yes ipv6-hw: yes icmp-reply-on-error: yes hw-supports-fasttrack: yes
Unpublished!
- Rose Data Server Confluence page was published 1 hour ago.
- https://help.mikrotik.com/docs/spaces/U ... ata+Server
Code: Select allThe device supports RouterOS software with version v7.18 or above.
Prophecy?Yes, that would be great!
But I fear that once the Rose Data Server really hits the street, we will see lots of requests for (in itself) reasonable requests around data server functionality.
(some of them in software not written by MikroTik but becoming their responsibility when used as part of such a product. e.g. I am using BTRFS myself on my home system, and I can tell it is a REAL PAIN when you are running RAID-1 and one of the disks goes offline. It is NOT like in a typical RAID-1 controller where you can just pull the disk and plug the same or another one back in)
Well in the Newsletter #123 topic it already begins... "we want ZFS, not BTRFS".Prophecy?
We DON'T WANT any FS on a ROUTER!Well in the Newsletter #123 topic it already begins... "we want ZFS, not BTRFS".Prophecy?
You need install rose package so its already optional.... I don't see where issue is.We DON'T WANT any FS on a ROUTER!
Well in the Newsletter #123 topic it already begins... "we want ZFS, not BTRFS".
Please make this whole file-sharing cr*p optional on a ROUTER.
Thank you!
I wish it were so, but experience shows that it isn't. If I open a ticket about dynamic routing or MPLS issue, it takes months to react. If I am the only one about this issue then there is not so big the problem is.No it does not IMHO.
Different type of developers so there should be no conflict.
There have been several people here complaining about the BGP issues, and I also opened a ticket half a year ago, but nothing happens.I wish it were so, but experience shows that it isn't. If I open a ticket about dynamic routing or MPLS issue, it takes months to react. If I am the only one about this issue then there is not so big the problem is.No it does not IMHO.
Different type of developers so there should be no conflict.
I guess nobody's replied because this is a terrible, terrible idea. Nobody wants Wireguard plus some proprietary Russian "improvements" on top running anywhere near their networks. Shipping this would be the end of Mikrotik.and of course amnezia wireguard in an options package.
The amount of money companies spend on developers is finite.No it does not IMHO.
Different type of developers so there should be no conflict.
Please make a support ticket!I wanted to check if anyone else has experienced this issue on their CCR2216 running v7.16.2. Every now and then, routing seems to stop working properly, and when I go to Routing → BGP, the display is completely blank and unresponsive.
Thank you for the feedback, you had similar issues and when you downgraded to 7.15.3 the issue have gone away permanently?Please make a support ticket!I wanted to check if anyone else has experienced this issue on their CCR2216 running v7.16.2. Every now and then, routing seems to stop working properly, and when I go to Routing → BGP, the display is completely blank and unresponsive.
When the support tickets about BGP keep coming in, maybe someone at MikroTik realizes that they broke something in 7.16 and it needs to be fixed.
When you require it to be fixed quickly, downgrade to 7.15.3 (download from the archive).
Thank you for the feedback, I am going to wait for Mikrotik to respond before updating as it might introduce other issues and downgrading might not fix the issues that I am having where pings to a PPPoE client stops working and my frontend goes blank etc.I have all kinds of BGP issues that were introduced with 7.16, reported, but not yet fixed.
In version 7.15.x it worked much better. But I cannot downgrade because I require other fixes.
And there is a good reason for this. I using BTRFS only where there is no need FS level RAID or at most I using RAID0 for data and RAID1 for metadata if data loss is accepted. As I read correctly, NVMe disks connected directly to the PCIe fabric so there is no HW RAID controller in this pizza-box. I don't know ROSE storage solution, what kind of possibilities we have if we would like to use RAID like operation? BTRFS RAID is unfortunately a dead end however RAID0 or RAID1 us usable with some constraints, but if I need RAID5 or RAID6 for some reason, how could I do that without ZFS? For comparison, I have a NAS at home, with four 8TB disks in RAID5 setup. I was clingy for BTRFS for a long time till I started a scrub on it and it tells me it will take more than a week. I copied all data from that volume, recreate it with ZFS RAIDZ and copied all data back. Now, if I start a scrub, it take 9 hours on the same HW. Not to mention that ZFS is much more mature.Well in the Newsletter #123 topic it already begins... "we want ZFS, not BTRFS".Prophecy?
I don't KNOW what ROSE uses, but I do know that the Linux kernel have support for software RAID (mdraid) for quite some time already. It's stable, it's mature and it's dependable. Can't say if they use it, but it's (would be?) an easy "turn key" solution.I don't know ROSE storage solution, what kind of possibilities we have if we would like to use RAID like operation?
@pe1chl, I have an idea. How many peers do your routers have?I have all kinds of BGP issues that were introduced with 7.16, reported, but not yet fixed.
In version 7.15.x it worked much better. But I cannot downgrade because I require other fixes.
I stand corrected and validated regarding the point I made surrounding the rush release of v7.18 in support of their RDS hardware announcement.v7.18 "stable" published and with this:
[*]Rose Data Server Confluence page was published 1 hour ago.
- https://help.mikrotik.com/docs/spaces/U ... ata+Server
Code: Select allThe device supports RouterOS software with version v7.18 or above.
I managed to repro issue with locking.Yes rebooted. I will try again. I believe it will repro soon.Besides marking for uninstall, was the device rebooted to complete uninstall @nipfel?
And did you create supout to inform support?
This is not really constructive.
Can't imagine people overseeing such a thing, can you?
I also had 100% CPU usage because I decided to clear DF and IP options somewhere in prerouting. Additionally I managed to drop Martian Addresses and RFC1918 from/to WAN using AddressLists (And also one Turkish subnet who wanna be fonts cdn for me).
Maybe in that case saving or modifying fw filter rules may have such result. Who knows, who knows...
Yes, it needs hotplug, but I dunno if it is supported in RDS. An enterprise storage has hotplug support, so crew can replace faulty disks on-the-fly.But you cannot replace a disk with the same disk, that is the problem.
I think that you understood perfectly what I wanted to say.sinisa said "file sharing". "*) cloud - added "Back To Home Files" feature;" is a feature in routeros main package. True, the storage features are part of rose extra package. Regarding the shoutout "We DON'T WANT any FS on a ROUTER!". Every device needs to support at least one file system for the root partition. So the thing of "we don't want any FS on a router" is impossible.
I could be wrong, but I think you need to upgrade to 7.13 first, then to 7.18. There were some major changes to the way packages were handled requiring the step to 7.13 first. Maybe someone could correct me if I'm wrong.Client (CubePRO) 7.12.1 -> upgrade to 7.18. Client does not boot
*) bgp - make NO_ADVERTISE, NO_EXPORT, NO_PEER communities work;
set/append bgp-communities no-export/no-advertise/no-peer
@oskarsk - Can I assume this fix will be part of 7.20 stable and not 7.19?This is fixed, please try
https://box.mikrotik.com/d/c2fc960065ed49b78214/
And please send us supout files to us so we can deal with issues faster.
OVPN still in trouble here on RB4011GS+ / ARM. aes256cbc working fine, aes256gcm results in permanent disconnects as soon as data is transmitted.
Feb 27 22:23:53 unifi openvpn[314096]: cliente-XXXXXX-01/177.xx.xx.xx:49625 AEAD Decrypt error: cipher final failed
Feb 27 22:23:53 unifi openvpn[314096]: cliente-XXXXXX-01/177.xx.xx.xx:49625 AEAD Decrypt error: cipher final failed
Feb 27 22:23:53 unifi openvpn[314096]: cliente-XXXXXX-01/177.xx.xx.xx:49625 AEAD Decrypt error: cipher final failed
Feb 27 22:23:53 unifi openvpn[314096]: cliente-XXXXXX-01/177.xx.xx.xx:49625 AEAD Decrypt error: cipher final failed
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 1550 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 1550(1578) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 36 received, 28% packet loss, time 646ms
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 1550 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 1550(1578) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 37 received, 26% packet loss, time 652ms
(eventually, no loss occurs, but that seems to be really exception)
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 1550 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 1550(1578) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 667ms
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 1550 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 1550(1578) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 35 received, 30% packet loss, time 640ms
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 1550 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 1550(1578) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 29 received, 42% packet loss, time 624ms
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 30000 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 30000(30028) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 611ms
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 30000 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 30000(30028) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 730ms
[root@unifi openvpn-mikrotik]# ping 172.30.1.94 -s 30000 -c 50 -q -f
PING 172.30.1.94 (172.30.1.94) 30000(30028) bytes of data.
--- 172.30.1.94 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 685ms
1. This has nothing to do with 7.18This script is not working, Please check
:global Var1
:global Var2
:set Var1 "$[/system routerboard get upgrade-firmware]"
:set Var2 "$[/system routerboard get current-firmware]"
:if ($Var1>$Var2) do={/system routerboard upgrade;
:delay 8s;
/system reboot;
}
{
:local Var1
:local Var2
:set Var1 "$[/system routerboard get upgrade-firmware]"
:set Var2 "$[/system routerboard get current-firmware]"
:if ($Var1>$Var2) do={
/system routerboard upgrade
:delay 8s
:put "upgrade $Var1"
:put "current $Var2"
}
}
Script Error: cannot compare if string is more than string
I hate to continue the discussion on this offtopic, but the referenced post shows how to update ROS - and not the routerboard firmware.The simplest, if you really like shooting yourself in the foot, is this:
viewtopic.php?t=214886#p1127217
:if ($Var1 != $Var2) do
I did not post the solution, just pointed out what was wrong, to help the poster to try to figure out how to fix it and learn some from it ;)Code: Select all:if ($Var1 != $Var2) do
It's not the script that doesn't work, it's you who are unable to write it correctly.This script is not working, Please check
[...]
/system routerboard settings set auto-upgrade=yes
My main issues with BGP involve a network within a company with a headoffice and 4 branches.@pe1chl, I have an idea. How many peers do your routers have?I have all kinds of BGP issues that were introduced with 7.16, reported, but not yet fixed.
In version 7.15.x it worked much better. But I cannot downgrade because I require other fixes.
What are you using for monitoring?I can see a massive increase in latency spikes and loss after upgrading to v7.18 on multiple CCR2004-1G-12S+2XS
![]()
This is no mystery anymore. It is this change causing it:Warning for people using this metrics exporter : https://github.com/akpw/mktxp/issues/229
Since 7.18, something is broken...
But the main question is why routeros don't provide it's own metrics endpoint...???
*) console - put !empty sentence when API query returns nothing;
Heads-up - breaking changes for management and monitoring:
*) console - put !empty sentence when API query returns nothing;
Please read previous replies to a release thread before adding another.After the update, openvpn is rebooting the rb on each external connection made.
Tks
This is the other thing that stands out to me. Some of my providers are set at lower preferences than others. But I don't use local pref internally.
@pe1chl, I have an idea. How many peers do your routers have?
Observations starting from 7.16 but still occurring in 7.18:
- the backup paths, that have a route filter that sets local preference 90, are often not stored in the route table at all.
/interface ovpn-server server add mac-address=AA:BB:CC:DD:EE:FF name=ovpn-server1
Does this include the Realtek 8126 updates to the 8169 driver, from kernel 6.12? I've got a couple of Realtek 5G M.2 NICs that show up in the PCI list, but the driver doesn't load for them.*) chr/x86 - Realtek r8169 updated driver;
/ip/ipsec/policy/set src-address=0.0.0.0/0 dst-address=0.0.0.0/0 numbers=0
I opened a ticket for this. Try disable HW option in your interface and also confirm the ports are the new default if you are using VTEP.Hey guys. VXLAN is broken\changed again with 7.18
I have vxlan bridged untagged on both sides and esxi with the same tagged vlan in the same bridge. After update couldn't reach VCenter VM to ESXi interface with the same vlan over vxlan. Had to enable local-proxy-arp on vlan interface of CCR.
*) l3hw - remove VLAN tag before VXLAN encapsulation (fixes pvid behavior for bridged VXLAN);Hey guys. VXLAN is broken\changed again with 7.18
I have vxlan bridged untagged on both sides and esxi with the same tagged vlan in the same bridge. After update couldn't reach VCenter VM to ESXi interface with the same vlan over vxlan. Had to enable local-proxy-arp on vlan interface of CCR.
I'm also concerned about RouterOS 7.18+'s footprint on 16MB flash devices with the wifi-qcom-ac package. One of the objections raised is that having 3 "wifi-qcom" packages instead of 2 would be more complicated. It would be, but I don't think it's necessary. In fact, I think the current split could be made LESS complicated. Continue offering only 2 packages, but instead there'd be a "skinny" package called wifi-ipq401x and a "fat" package called wifi-qcom. The wifi-ipq401x package would include ONLY the drivers and firmware for IPQ4018 and IPQ4019 devices -- all that's needed but no more than what's needed for the 16MB flash devices. The new wifi-qcom would include everything that's in today's wifi-qcom-ac and wifi-qcom packages. Owners of >16MB flash IPQ401x devices such as the hAP ac3 could run either wifi-ipq401x or (new) wifi-qcom, as they prefer.I am linking to my old posts in the 7.18 beta thread:
viewtopic.php?t=214071&start=300#p1125166
viewtopic.php?t=214071&start=300#p1125183
MikroTik does have the possibility to free up at least 565KB (38KB from the useless .woff2 font files) for those AC devices with 16MiB flash if they care.
*) wifi - implement steering parameters to delay probe responses to clients in the 2.4GHz band;
2025-03-03 11:22:21 system,error upgrade failed, free 13 kB of disk space
2025-03-03 11:22:21 system,error GENERAL: upgrade failed, free 13 kB of disk space
version: 7.17.2 (stable)
free-hdd-space: 168.0KiB
total-hdd-space: 16.0MiB
architecture-name: arm
board-name: D53G-5HacD2HnD
platform: MikroTik
version: 7.17.2 (stable)
free-hdd-space: 408.0KiB
total-hdd-space: 16.0MiB
board-name: cAP ac
platform: MikroTik
version: 7.18.1 (stable)
free-hdd-space: 292.0KiB
total-hdd-space: 16.0MiB
board-name: cAP ac
platform: MikroTik
Exactly... I have the checkbox enabled,@ chiem My understanding is that fast-path is only used if many conditions are met, one of which is no firewall filter rules.
My counters show similar 0 ipv6-fast-path-packets and bytes values.
Doesnt work for me - nor in 7.18.1. still need to disable HW option in vlan*) l3hw - remove VLAN tag before VXLAN encapsulation (fixes pvid behavior for bridged VXLAN);Hey guys. VXLAN is broken\changed again with 7.18
I have vxlan bridged untagged on both sides and esxi with the same tagged vlan in the same bridge. After update couldn't reach VCenter VM to ESXi interface with the same vlan over vxlan. Had to enable local-proxy-arp on vlan interface of CCR.
Just saw this fix in the beta 7.19 release
Just netinstalled this device. 7.18.1 is now running, but flash-space is tight.Today was the day I thought, 7.18.1, now I can upgrade. But it did not upgrade:
Well yeah, before upgrade I checked system resources:Code: Select all2025-03-03 11:22:21 system,error upgrade failed, free 13 kB of disk space 2025-03-03 11:22:21 system,error GENERAL: upgrade failed, free 13 kB of disk space
Yeah, 168kib is not much. But again: yet another major release consuming more space. 7.14 was a disaster (space wise). 7.15 regained quite a lot of space. Since 7.16 decreasing space again. Now 7.18.1 - and my device can't upgrade. Leaves me puzzled.Code: Select allversion: 7.17.2 (stable) free-hdd-space: 168.0KiB total-hdd-space: 16.0MiB architecture-name: arm board-name: D53G-5HacD2HnD platform: MikroTik
version: 7.18.1 (stable)
free-hdd-space: 44.0KiB
total-hdd-space: 16.0MiB
board-name: D53G-5HacD2HnD
platform: MikroTik
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:39:54 system,error,critical could not save configuration changes, not enough storage space available.
2025-03-04 00:40:41 system,error,critical could not save configuration changes, not enough storage space available.
version: 7.18.1 (stable)
free-hdd-space: 0
total-hdd-space: 16.0MiB
architecture-name: arm
board-name: D53G-5HacD2HnD
platform: MikroTik
/system/reboot
Reboot, yes? [y/N]:
y
system will reboot shortly
action timed out - try again, if error continues contact MikroTik support and send a supout file (13)
manager, debug !---> DEBUG: >>> DROP rx from [127.0.0.1]:34974, reason: unknown router IP
> /user-manager/router/print
Flags: X - disabled
/user-manager> print
enabled: yes
authentication-port: 1812
accounting-port: 1813
certificate: none
use-profiles: no
require-message-auth: yes-access-request
In such cases support will advise to connect a computer to the serial port and run a terminal application with logging.Just as an fyi for anyone here (I did create a support ticket, SUP-181012). I have a CCR2116-12G-4S+, with two partitions, each running 7.17.2 (they failover to the other if something breaks). When attempting to update to 7.18.1, via the Webfig, the system downloads the update, reboots and after about 5-8 minutes, it eventually reboots/fails over to the other partition.
It looks like your use-case is finished, and you need to either remain on a lower version or remove one of the packages.Just netinstalled this device. 7.18.1 is now running, but flash-space is tight.
Code: Select allversion: 7.18.1 (stable) free-hdd-space: 44.0KiB total-hdd-space: 16.0MiB board-name: D53G-5HacD2HnD platform: MikroTik
It seems to me that someone at MT forgot to compress few binaries in 7.18.1 ARM package like login, graphing, trafficgen etc. so they are now using much more of already pretty limited 16MB storage space...Code: Select allversion: 7.18.1 (stable) free-hdd-space: 44.0KiB total-hdd-space: 16.0MiB board-name: D53G-5HacD2HnD platform: MikroTik
16MB devices support it. Look at my free-space report to "cap ac". This little device is capable of running 7.18.1 and still has enough free space. But there is a clear trend.Also 16MB devices just cannot support wifi-qcom-ac which is almost 1MB larger than old wireless package, not to mention OOM issues...
11431552 routeros-7.13-arm.npk
11755104 routeros-7.14-arm.npk
11553008 routeros-7.15-arm.npk
11608756 routeros-7.16-arm.npk
11887342 routeros-7.17-arm.npk
12076474 routeros-7.18-arm.npk
12158782 routeros-7.19beta2-arm.npk
12171054 routeros-7.20_ab57-arm.npk
Maybe you'll like SuperQ's Smokeping Prober https://github.com/SuperQ/smokeping_proberPing Exporter: https://github.com/czerwonk/ping_exporter
Yes I think that could be part of the reason, but what I observe is that on our main office network where there is lots of equipment running 24h/day I see this message immediately after the reboot (and I considered the same thing as you), however on other locations I see the message when the people come in during the morning. E.g. this was logged after a scheduled reboot last night at 01:01 to update to 7.18.1:I think the reason this has a high probability of appearing at reboot is because while the router is being rebooted, clients in the network are still firing DNS queries at it ...