Page 2 of 2
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 04, 2025 8:34 pm
by bajodel
either way, I'd like to be able to tune this checks. Since they are in place, why not using them directly and tune them for our needs.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 12:47 am
by pe1chl
What type of package manager introduces such a significant storage overhead? OpenWRT has been using "opkg" for years without issues. However, OpenWRT also provides board-specific builds - perhaps this is the key to addressing flash storage limitations on 16MB devices.
The "packages" in RouterOS are said to be separate filesystems that are loop-mounted into the root filesystem at boot.
As each package filesystem is "compressed", more compression can be gained by having everything together than by putting them all in separate filesystems (compression is based on coding repeatedly occurring patterns as a shorter sequence).
Also, a filesystem has overhead like a superblock, directories, etc. But I think that is quite small for squashfs, which I think they are using.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 12:49 am
by pe1chl
either way, I'd like to be able to tune this checks. Since they are in place, why not using them directly and tune them for our needs.
Assuming this is still about the "possible SYN flooding on tcp port 53": YES. When having hundreds of clients on the local network, there can be enormous bursts of DNS requests. The CCR2004 should be able to handle that. I have configured 10000 concurrent requests and 1000 TCP connections and I do not appreciate that the service would then be temporarily cut off due to "SYN flooding"...
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 1:14 am
by loloski
We have seen this behavior as well with winbox, but port 8291 was only exposed to management vlan and I'm the only one accessing the device during that time so this SYN flooding warning is just a fluke at least for me
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 3:36 am
by cmasi
Avoid this command in this version, your device will crashed and put the device on boot loop.
/queue/type/remove [find default =no]
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 10:35 am
by rextended
Avoid this command in this version, your device will crashed and put the device on boot loop.
/queue/type/remove [find default =no]
just done, nothing happen.
C52iG-5HaxD2HaxD
These things written so haphazardly and without the slightest context are worthless.
Provide the
supout.rif to
support@mikrotik.com so they can test if it's true.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 11:59 am
by asiobob
I have an HEX (not refresh edition) that works fine on 7.17.2 but crashes on 7.18 and 7.18.1.
Recovery requires reset button to wipe config, after which 7.18.1 boots, I then downgrade to 7.17.2 and apply the backup and everything is fine.
As this is a 'production' router, in the sense I can't have it down for too long, I'm unsure how to troubleshoot this. I do have the /export output so maybe I need to apply it step by step. I have submitted a Mikrotik Support Ticket with config from 7.17.2 that crashes 7.18.1 but haven't heard for a week (I understand its a busy time)
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 12:13 pm
by S8T8
Avoid this command in this version, your device will crashed and put the device on boot loop.
/queue/type/remove [find default =no]
Can confirm, couple weeks ago my RB4001 crashed with /queue/type/remove [find], I had to reset it due to a boot loop.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 12:40 pm
by pe1chl
We have seen this behavior as well with winbox, but port 8291 was only exposed to management vlan and I'm the only one accessing the device during that time so this SYN flooding warning is just a fluke at least for me
I don't mind that it logs a bogus message, but I worry that when it detects the condition (also later during operation, without logging the warning again) it will temporarily disallow new connections on that port.
In case of DNS that would cause users to experience delays e.g. when loading a webpage, and that is precisely what we observe.
I lately get those helpdesk tickets "the internet sometimes is soooo sloooow!!!" and it isn't reproducible, but it could well be this.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 12:41 pm
by infabo
Well, "/queue/type/remove [find]" sounds a little bit more destructive. cmasi wants to only delete custom (default=no) queue types.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 1:53 pm
by rextended
Ok, with remove [find default=no] also my device is locked... probably the command is used before deleting existing queue simple/tree that use the type.....
A manual reboot solved, not go on loop. NO. Must netinstall. after some seconds locks again.
/queue type
add kind=cake name=queue1
/queue simple
add name=queue1 target="" total-queue=queue1
/queue tree
add name=queue1 parent=global queue=queue1
Probably For sure removing the queue type before removing existing queue that use the type is the problem....
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 2:12 pm
by rextended
BUG:
Removing not default queue type used on queue simple or queue tree before removing/changing the existant queue cause
permalock.
How to replicate:
/queue type
add kind=cake name=queue1
/queue simple
add name=queue1 target="" total-queue=queue1
/queue tree
add name=queue1 parent=global queue=queue1
/queue type
remove [find where default=no]
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 2:16 pm
by nmt1900
This is major fundamental issue with Mikrotik - any object can be removed even if it is used somewhere else. One example - on Fortinet devices every object has all references marked and can be removed only after all references to it are removed. This can avoid many similar configuration breakdowns...
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 2:21 pm
by infabo
Oh, okay - if even Fortinet gets it right, that certainly says something. š
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 2:29 pm
by rextended
Like removing or disabling bridge for error on untouched router cause permalock
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 5:30 pm
by Jotne
Is this only on 7.18.1?
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 5:32 pm
by nmt1900
Oh, okay - if even Fortinet gets it right, that certainly says something. š
This is just an example how it can be done right way. I have seen enough headaches with Fortinet just as with Mikrotik, but this is beside the point. The point is lacking this kind of basic sanity checks on configuration changes. Even if some bug will cause this and there's no sanity check stopping it from happening and you are up to netinstall.
My first encounters with Fortinet made me furious because of this exact feature but one would quickly understand the value behind it, because with Mikrotik you end up searching manually for all these references which are shown to you in Fortinet GUI to help you and to avoid this kind of a situation from happening.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 6:41 pm
by pe1chl
The point is lacking this kind of basic sanity checks on configuration changes. Even if some bug will cause this and there's no sanity check stopping it from happening and you are up to netinstall.
It is not as bad as you suggest. Yes, sometimes you can remove an object and leave something else dangling, but usually you will just get an "unknown" or some HEX number at the place where it was referred, and nothing bad happens.
This problem with queue deletion is apparently touching something more fundamental and causes a kernel crash.
That is bad, but it will likely be fixed ad-hoc and not by enforcing referential integrity at the basic level (which Fortinet apparently has).
There is always something to be said about the configuration mechanism.
Some people prefer a system where all config is only done in RAM and a "save" is required to commit it to nonvolatile memory.
Some systems have a "transaction" mechanism where you can change different parameters and "commit" the whole transaction in a single config change. Sometimes useful when you want to change things and the intermediate situation is not working or conflicting.
But every method has its advantages and disadvantages, and its overhead in software.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 05, 2025 6:50 pm
by infabo
There is always something to be said about the configuration mechanism.
Some people prefer a system where all config is only done in RAM and a "save" is required to commit it to nonvolatile memory.
Some systems have a "transaction" mechanism where you can change different parameters and "commit" the whole transaction in a single config change. Sometimes useful when you want to change things and the intermediate situation is not working or conflicting.
I believe that a (better) system should require a "commit" action to save changes. When making many configuration changes - such as adjusting firewall rules extensively - it is the final result that matters, not the many steps taken to get there. If the end result is just three changes to existing rules, the system should not save every intermediate step automatically.
When I updated four mangle rules today using "/ip/firewall/mangle/set connection-state=new [find where action=mark-connection]" it created four entries in the history. So far so good. Afterwards, I executed "/undo" four times, but only three changes were reverted. The first of the four mangle rules remained in its last state. "/system/history/print" told me: all 4 got reverted. In situations like this, I find these "auto-commits" quite frustrating.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 12:12 pm
by azerty
Hi guys,
You can use
safe mode Here.
You can undo all changes in one step.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 12:16 pm
by AlexandruL
Hi guys,
You can use
safe mode Here.
You can undo all changes in one step.
I was about to say that but it has a limit of 100 commands.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 1:36 pm
by rextended
It would be enough if the safe mode was automatic(*) and asked for confirmation of changes before exiting...
(*) Increased from 100 to ad libitum...
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 2:12 pm
by infabo
Hi guys,
You can use
safe mode Here.
You can undo all changes in one step.
I have to say: similar also happened approx. 1 or 2 years back while I was in safe mode. I enabled safe mode, did at max. 10 changes or like. Then I left safe mode. It did undo most - but not all changes I have made while I was in safe mode. I guess it is because safe-mode utilizes the undo/history system to accomplish the task. This is why I do not use safe-mode. I was so baffled by this experience that I tried to find a "step by step" to reproduce this bug and report to Mikrotik support - but I was not able to find a simple command sequence to trigger the bug.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 3:18 pm
by fischerdouglas
Hi guys,
You can use
safe mode Here.
You can undo all changes in one step.
No way to compare commit, commit trial, commit dry-run, commit full, rollback... With that thing called "safe-mode".
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 3:26 pm
by AlexandruL
I used safe mode without any issues, but it has it's limitations, for example bridge changes that lead to short disconnects. However, if I have to do something that is really .... dicey , I make a full binary backup and then assign a restore via the scheduler with enough time in advance. Another way for very important systems is to use partitions and a fallback partition with a reboot task with enough time in advance to make the changes. ALWAYS backup before any significant change.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 3:28 pm
by nmt1900
Yes Safe mode can be seen as some kind of quasi-commit like system but not completely equal to this.
Fortinet-like configuration integrity enforcement creates obviously some overhead and with our package sizes constrained to ingenious "16 MB should be enough for everything" strategy it can be a problem. Typical Fortigate device install image can be up to 100 MB in size but then again Fortigate has many functionalities that basic router like Mikrotik does not have...
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 3:46 pm
by pe1chl
A crucial difference between "Safe mode" and also "apply changes only in RAM and require explicit save" and a transaction-like system is that with the latter you can apply a series of configuration changes and do an APPLY at the end of it.
It is possible in RouterOS cmdline mode, by typing a { and then entering multiple commands, close with } and then they are applied.
But in some other systems the same functionality is available in the GUI.
You change a couple of things, and there is a TEST button, when you click that all open changes are applied, and when you do not hit a KEEP button within 3 minutes they are all rolled back.
(so when you make a change that locks you out, they are discarded)
Better than the "Safe mode" of RouterOS, because that immediately rolls back changes when your session disconnects, which may be expected to happen e.g. when you change something in the VPN that you are using to access the device.
In the mentioned method you can re-connect and when that succeeds (within 3 minutes) you can save the changes.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 4:45 pm
by rextended
[..] I make a full binary backup and then assign a restore via the scheduler with enough time in advance.[...]
I was already giving the same advice a few years ago, it's how I work...
example code
0) If it's a bug like the one reported above(Ā¹), you're fuāed anyway...
1) Make a binary backup
2) Make one export
3) Schedule the reload on A) REBOOT and on B) after xx minutes
(It depends on how long you think it will take to make the changes, usually 10 minutes is enough)
NOTE: This do not do reboot-loop for reload the backup, since on binary backup reloaded is not present the scheduled reload at reboot.
4) Do the work
5) Make again one export
6) Compare prev/next export for review the differencies
7) If all is OK remove scheduled reload on point 3)
(Ā¹)
viewtopic.php?p=1131405#p1131111
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 5:20 pm
by pe1chl
Assuming this is still about the "possible SYN flooding on tcp port 53": YES. When having hundreds of clients on the local network, there can be enormous bursts of DNS requests. The CCR2004 should be able to handle that. I have configured 10000 concurrent requests and 1000 TCP connections and I do not appreciate that the service would then be temporarily cut off due to "SYN flooding"...
I have added a Linux VM with BIND9 as a resolver and offer it as a second DNS resolver to DHCP clients.
What I see on this machine is that while Windows machines usually use UDP queries, at some point a Windows machine decides to switch to TCP and sets up several (3 in most cases) TCP sessions to port 53 to do its queries. After a while they are disconnected again.
I guess that Windows does that when it receives no reply to a UDP query in time, which can happen in DNS for some domains (slow server).
Anyway, the resolver in the router has to be prepared to service a large spike in TCP queries, certainly after reboot, but it could occur at any time.
Please remove any restriction related to "possible SYN flooding on tcp port 53". I would say "on local networks", but of course that is difficult to determine.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 6:48 pm
by fischerdouglas
[..] I make a full binary backup and then assign a restore via the scheduler with enough time in advance.[...]
I was already giving the same advice a few years ago, it's how I work...
example code
0) If it's a bug like the one reported above(Ā¹), you're fuāed anyway...
1) Make a binary backup
2) Make one export
3) Schedule the reload on A) REBOOT and on B) after xx minutes
(It depends on how long you think it will take to make the changes, usually 10 minutes is enough)
4) Do the work
5) Make again one export
6) Compare prev/next export for review the differencies
7) If all is OK remove scheduled reload on point 3)
(Ā¹)
viewtopic.php?p=1131405#p1131111
This sounds as horrible as the old technique of operating old Cisco IOS without Commit, where you would schedule a reboot and if by the time of the reboot you didn't cancel that reboot or if you didn't do a "copy running-config startup-config" you might be saved by the scheduled reboot.
I also used scripts in TCL for situations where I needed to change interface IPs and would lose access during the commands... A huge
GAMBIARRA.
I think it's worth considering the possibility of having 2 options...
- The first being "safe-mode" centric, as most current MikroTik users are used to.
- The second being "commit/rollback" centric, as most users of more robust equipment are used to.
Just to give you an example, Arista's EOS gives you 2 options!
- configure terminal, where the commands take effect immediately after being applied.
- configure session, where the commands only take effect at the time of commit.
Why can't MikroTik consider a way to deliver both possibilities and leave it up to the operator?
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 10:07 pm
by RavenWing71
FYI for those using RSTP. There appears to be a bug in the Switch code for the QCA8337 switch used in the RB750Gr2. Since at least as early as v7.16.2 it has a habit of passing received BPDU packets through the switch to other connected devices. For v7.17 a work around is to disable hardware switching and use the software bridge and Fast Forwarding instead. This fix appears to break in v7.18.1 along with other related quirks.
I'm discussing this at length with MikroTik support in SUP-179002, but thought the community should know.
Update: see
search.php?author_id=45699&sr=posts
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 10:22 pm
by rextended
That switch is used on:
RB750Gr2 (hEX)
RB962UiGS-5HacT2HnT (hAP ac)
RB960PGS (hEX PoE)
RB960PGS-PB (PowerBox Pro)
RB3011 (all series)
RB OmniTik ac (all series)
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 10:38 pm
by RavenWing71
I have not made any attempt to see if it's an oversite exclusive to the RB750Gr2 or if the flaw is present on all QCA8337 based devices. But if you are using RSTP and having problems with ports flapping that are connected to any of the devices rextended mentioned above, you may be suffering the same problem I'm seeing. In my case, it was a RB2011 that was flapping the connection to a RB750Gr2. Wireshark proved that BPDU packets from the other side of the RB750Gr2 were reaching the RB2011 along with the proper BPDU packets originating from the RB750Gr2. When the RB2011 was running v7.13.5, this did not bother the RB2011. But once upgraded to v7.16.2 or higher, the mix of BPDU packets was causing the port on the RB2011 to fail to decide on a RSTP role.
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 06, 2025 10:40 pm
by infabo
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 12:14 am
by elico
I have a bunch of LTAP mini with EU200A modem which 7.18+7.18.1 broke.
I have couple setups and some of them use pap authentication to special APN.
when I am using the network default APN or without authentication the connection is fine.
However when I am trying to use LTE+APN+authentication The device cannot receive an IP address on 7.18.X
The last version which I consider to be stable is 7.16.2 and until now at least 20 devices in my stock got the same issue with 7.18.X while downgrading to 7.16.2 everything works as expected.
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 12:17 am
by taduikis
Can you explain why you dropped AGE property from /interface/bridge/host print in ROS v7.7?
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 12:59 am
by RavenWing71
Your D53G-5HacD2HnD logs look a lot like the kind of mess I was seeing in my logs on the RB2011. Note that the RB2011 was not directly to blame. By upgrading it to v7.16.2 or higher, it became intolerant of the problem that was actually in another box. Look at the hardware connected to ether2 on your D53G-5HacD2HnD.
More in your topic.
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 3:00 am
by cmasi
Is this only on 7.18.1?
I only experienced it in 7.18.1 using RB5009UG+S+IN, CCR2004-1G-12S+2XS and CCR2216-1G-12XS-2XQ.
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 6:02 am
by tryrtryrtryrt
After updating from 7.16.1 to 7.18.1 /export show-sensitive terse started showing new bogus interface
/interface ovpn-server server add mac-address=[...] name=ovpn-server1
While it's disabled by default, I would prefer default config and especially updates not to create bogus interfaces.
P.S. Somewhere before 7.16.1 similar thing happened with addition of
/zerotier set zt1 comment="ZeroTier Central controller -
https://my.zerotier.com/" disabled=yes disabled=yes name=zt1 port=9993
After updating from 7.16.1 to 7.18.1 it got removed again.
I think something similar happened with ovpn-server1.
(I track default config after each update to track my own modifications to it.)
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 9:33 am
by CGGXANNX
/interface ovpn-server server add mac-address=[...] name=ovpn-server1
While it's disabled by default, I would prefer default config and especially updates not to create bogus interfaces.
This happened because in 7.17 supports for multiple OVPN server instances were introduced. In previous version there were only one possible instance, so all settings applied to
/interface ovpn-server server. After
upgrading to 7.17 RouterOS has to migrate the setting of that old single default instance, and it creates the ovpn-server1 entry and copy over the old settings. If in the old setting OVPN server was not enabled, then the new entry is created in the disabled state (to reflect that old Enabled checkbox value).
You can use tangent's (constantly updated) article to clean up such setting entries introduced by upgrades
https://tangentsoft.com/mikrotik/wiki?n ... %20Flotsam
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 11:01 am
by cmasi
I'm wondering if some one is also experiencing limitation in adding adlist more than 32 entries? Even if I deleted all entries I will not able to add any more until I rebooted the router. I experience this since v7.17 and until now at v7.18.1 still experiencing the same problem.
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 1:36 pm
by grusu
Strange "Since" value in Netwatch:
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 1:53 pm
by rextended
You have time machine, Feb/7/2106...
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 2:03 pm
by andkar
Same here "Since" values all over the place.
Affected 2 x RB2011.
No problem on CHR .
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 07, 2025 11:17 pm
by RavenWing71
FYI for those using RSTP. There appears to be a bug in the Switch code for the QCA8337 switch used in the RB750Gr2. Since at least as early as v7.16.2 it has a habit of passing received BPDU packets through the switch to other connected devices. For v7.17 a work around is to disable hardware switching and use the software bridge and Fast Forwarding instead. This fix appears to break in v7.18.1 along with other related quirks.
I'm discussing this at length with MikroTik support in SUP-179002, but thought the community should know.
Mikrotik has gotten back to me. It appears that if you rig the QCA8337 or the Atheros 8327 for hardware bridging with VLANs, you need to enable independent-learning for VLAN 1 (my default/untagged VLAN) for the hardware RSTP functions to work correctly.
Hardware bridging with VLANs :
https://help.mikrotik.com/docs/spaces/R ... upExamples
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 11:33 am
by kuzma2000
I have a problem with SFP PON module on Heh S
For WAN, I use the SFP-PON module.
It was issued by the provider.
Model: RAISECOM
Name HT801-GSFP
Revision T.10
Other settings:
RX TX control - off
Auto Negotiation - enable
After updating to 7.18.1, a problem appeared.
After a hot reboot, the link on the SFP port is not raised.
If the provider reboot the module remotely, everything is ok.
If I warm reboot the Hex S - the link on the SFP port does not rise.
I noticed the problem on version 7.18.1
Prior to that, I was scheduled to update from the 6th line to 7.17.2.
Yesterday I updated from 7.17.2 to 7.18.1 and already thought that it was a brick, but no.
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 2:11 pm
by ela002
What will happen with 16MB devices? It's very hard to install updates. This means is the end of these devices?
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 2:31 pm
by kuzma2000
What will happen with 16MB devices? It's very hard to install updates. This means is the end of these devices?
It all depends on the architecture and processor.
The size of the root package, in which a lot of usually unnecessary things are now packed, is different.
On HAP AC2 (arm) I change the flash memory to 32 MB.
Now, on 7.18.1 it used 16.6 mb of 32 mb...
For the Hex S, such a trick did not work - it does not support more than 16 mb flash drive, but it has an SD Card.
But now 17% (used 13.1 of 16 Mb) is free on one of these devices (mmips).
On Cap Ac (ARM) access points, 6% of the space is free (root and Wireless packages).
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 3:06 pm
by ela002
What will happen with 16MB devices? It's very hard to install updates. This means is the end of these devices?
It all depends on the architecture and processor.
The size of the general package, in which a lot of usually unnecessary things are now packed, is different.
On HAP AC2 (arm) I change the flash memory to 32 MB.
Now, on 7.18.1 it used 16.6 out of 32 mb.
For the Hex S, such a trick did not work - it does not support more than 16 mb, but it has an SD Card
But now 17% (13.1 out of 16 Mb) is free on one of these devices (mmips)
On Cap Ac (ARM) access points, 6% of the space is free (only for the shared package and Wireless).
I have hap ac2 devices, how do you upgrade them to 32 MB ? I would like to keep upgrading them without the fear to brick them.
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 3:08 pm
by kuzma2000
It all depends on the architecture and processor.
The size of the general package, in which a lot of usually unnecessary things are now packed, is different.
On HAP AC2 (arm) I change the flash memory to 32 MB.
Now, on 7.18.1 it used 16.6 out of 32 mb.
For the Hex S, such a trick did not work - it does not support more than 16 mb, but it has an SD Card
But now 17% (13.1 out of 16 Mb) is free on one of these devices (mmips)
On Cap Ac (ARM) access points, 6% of the space is free (only for the shared package and Wireless).
I have hap ac2 devices, how do you upgrade them to 32 MB ? I would like to keep upgrading them without the fear to brick them.
viewtopic.php?p=1124163#p1124163
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 3:51 pm
by bratislav
What will happen with 16MB devices? It's very hard to install updates. This means is the end of these devices?
Back in RouterOS 6.x all_packages-xxx-6.x.x.zip used to actually contain all packages, both extra and the ones contained in the bundle, so you could choose to install from it only what is needed for your particular use case and not to install ppp, hotspot, mpls, ipv6 for example and save roughly 1MB which is pretty significant on a 16MB devices and avoids any lack of storage space issues... and upgrades wold only upgrade what is already installed.
Alas not anymore, what is bundled in routeros-7.x.x-xxx.npk is not available in all_packages-xxx-7.x.x.zip, is not visible in package manager and you cannot uninstall it even if you don't need it. Maybe MT could revert to 6.x packaging...
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 5:22 pm
by itimo01
What will happen with 16MB devices? It's very hard to install updates. This means is the end of these devices?
No as they released new devices with 16MB :D
And the 5 year claim still applies, no?
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 5:31 pm
by holvoetn
What will happen with 16MB devices? It's very hard to install updates. This means is the end of these devices?
No as they released new devices with 16MB

And the 5 year claim still applies, no?
Which would mean they will have to do something about current bloating of ROS base package.
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 5:49 pm
by itimo01
No as they released new devices with 16MB :D
And the 5 year claim still applies, no?
Which would mean they will have to do something about current bloating of ROS base package.
Well yeah definitely. You can't release a product that breaks on every 2nd update
Re: v7.18.1 [stable] is released!
Posted: Sat Mar 08, 2025 9:12 pm
by infabo
Sure you can do that. But you won't make friends.
Re: v7.18 [stable] is released!
Posted: Sat Mar 08, 2025 11:52 pm
by avacha
and of course amnezia wireguard in an options package.
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.
An what potential benefits would it bring? If you think your Wireguard traffic is at risk of DPI monitoring or attacks, run a box on your local network to run Amnezia - at least in that example you can get rooted by the FSB and the rest of us will stay safe.
If you need support you can go to Telegram! I'm going to be chuckling about that one for some time!
Well, let me tell you why no one's answering.
First of all, there is a separate topic about Amnezia VPN.
Secondly, Amnezia is open-source code. If you are so lame that you can't look through the code, that's your problem. And you haven't even learned how to use Google. Otherwise you would understand how it works - it changes some standart settings of Wireguard, for example, instead of a constant header length it uses a variable one for protocol obfuscation.
Thirdly, how can that scary FSB hack you if Amnezia comes as a separate installation package that is NOT installed by default on the router? Is Harry Potter going to wave his magic wand?
And lastly - some people are a few continents away from āFSBā, however hillbilly with pitchforks is near and in the White House.
As for you personally - no respect for you. In the good old days you would have to provide proofs or the moderators would do their job, but for now hillbillys like you can post any crap, rumors and propaganda without risk of being banned. Shame on you!
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 2:45 am
by dokacoimbra
Hello everyone,
I'm using the stable version 7.18.1 on my hAP acĀ², where I started using a USB flash drive to save files to avoid taking up space in the RB's internal memory, which is only 16 MB.
This led to the following issue: the flash drive I initially used was a SanDisk 3.2Gen1 128GB, which became defective. I had to replace it with the same model but with a smaller capacity, a SanDisk 3.2Gen1 32GB.
I discovered a possible bug: when I insert the new 32GB flash drive, the RB still recognizes the previous 128GB flash drive, even though it is not mounted or inserted in the RB. It detects it as usb1, and the inserted 32GB flash drive as usb1-part1.
If I try to eject and remove usb1, it also removes usb1-part1, and vice versa. It seems like the system is recognizing both drives as one.
I have already tried a factory reset, reboot, and downgrade, but the issue persists.
For reference, I'm using the FAT32 file system.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 6:59 am
by itimo01
Hello everyone,
I'm using the stable version 7.18.1 on my hAP acĀ², where I started using a USB flash drive to save files to avoid taking up space in the RB's internal memory, which is only 16 MB.
This led to the following issue: the flash drive I initially used was a SanDisk 3.2Gen1 128GB, which became defective. I had to replace it with the same model but with a smaller capacity, a SanDisk 3.2Gen1 32GB.
I discovered a possible bug: when I insert the new 32GB flash drive, the RB still recognizes the previous 128GB flash drive, even though it is not mounted or inserted in the RB. It detects it as usb1, and the inserted 32GB flash drive as usb1-part1.
If I try to eject and remove usb1, it also removes usb1-part1, and vice versa. It seems like the system is recognizing both drives as one.
I have already tried a factory reset, reboot, and downgrade, but the issue persists.
For reference, I'm using the FAT32 file system.
usb1 is the device while usb1-part1 is just a partition on the device.
Reformat usb1 if you just want a device with a file system instead of a partition.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 11:46 am
by markwien
Today was the day I thought, 7.18.1, now I can upgrade. But it did not upgrade:
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
Well yeah, before upgrade I checked system resources:
version: 7.17.2 (stable)
free-hdd-space: 168.0KiB
total-hdd-space: 16.0MiB
architecture-name: arm
board-name: D53G-5HacD2HnD
platform: MikroTik
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.
Just netinstalled this device. 7.18.1 is now running, but flash-space is tight.
version: 7.18.1 (stable)
free-hdd-space: 44.0KiB
total-hdd-space: 16.0MiB
board-name: D53G-5HacD2HnD
platform: MikroTik
And after a reboot I now see:
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.
No space is left.
version: 7.18.1 (stable)
free-hdd-space: 0
total-hdd-space: 16.0MiB
architecture-name: arm
board-name: D53G-5HacD2HnD
platform: MikroTik
Now, not even /system/reboot is possible. It times out.
/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)
hi i have the same problem
could not save configuration changes, not enough storage space available.
cant upgrade .. have u found a solution without netinstall the device ?
br
mark
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 11:58 am
by mkx
cant upgrade .. have u found a solution without netinstall the device ?
There is no other solution. No free space ... game over. It's not possible even to cleanly reboot/shutdown device.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 1:25 pm
by dokacoimbra
It worked, thank you very much.
Hello everyone,
I'm using the stable version 7.18.1 on my hAP acĀ², where I started using a USB flash drive to save files to avoid taking up space in the RB's internal memory, which is only 16 MB.
This led to the following issue: the flash drive I initially used was a SanDisk 3.2Gen1 128GB, which became defective. I had to replace it with the same model but with a smaller capacity, a SanDisk 3.2Gen1 32GB.
I discovered a possible bug: when I insert the new 32GB flash drive, the RB still recognizes the previous 128GB flash drive, even though it is not mounted or inserted in the RB. It detects it as usb1, and the inserted 32GB flash drive as usb1-part1.
If I try to eject and remove usb1, it also removes usb1-part1, and vice versa. It seems like the system is recognizing both drives as one.
I have already tried a factory reset, reboot, and downgrade, but the issue persists.
For reference, I'm using the FAT32 file system.
usb1 is the device while usb1-part1 is just a partition on the device.
Reformat usb1 if you just want a device with a file system instead of a partition.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 2:42 pm
by infabo
Just netinstalled this device. 7.18.1 is now running, but flash-space is tight.
version: 7.18.1 (stable)
free-hdd-space: 44.0KiB
total-hdd-space: 16.0MiB
board-name: D53G-5HacD2HnD
platform: MikroTik
And after a reboot I now see:
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.
No space is left.
version: 7.18.1 (stable)
free-hdd-space: 0
total-hdd-space: 16.0MiB
architecture-name: arm
board-name: D53G-5HacD2HnD
platform: MikroTik
Now, not even /system/reboot is possible. It times out.
/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)
hi i have the same problem
could not save configuration changes, not enough storage space available.
cant upgrade .. have u found a solution without netinstall the device ?
br
mark
Solution: netinstall 7.17.2. This 7.18.1 was a running zombie. While up and running, I was unable to reboot by /system/reboot. It was not possible to downgrade. Uninstall extra packages as well not possible. Not even deleting all installed certificates did regain a single byte. Nothing. All these actions seem to have one common requirement: save configuration. If this fails, you're out of luck.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 2:49 pm
by holvoetn
And yet I have a wAP AC running 7.18.1 without any problems, incl. wave2 drivers.
Only 300K left on storage but it hasn't experienced unexpected reboots yet.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 2:53 pm
by infabo
292kib, cap ac + wifi-qcom-ac.
viewtopic.php?t=215048#p1130419
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 2:58 pm
by elcano89
If someone could hear us out... We are in deep trouble with Mikrotik. We bought 12 CCR2216's to replace our aging 1072 fleet (we are a mid sized FTTH/Wireless ISP). We took the leap because of the ASIC L3hw-off capabilities on this new generation, which is a standard approach on most vendors like Juniper. Out of 3 deployed so far, we have only been able to run L3HW offloading on the Edge (very simple BGP only config), and it works awesome at +18Gbit/s traffic with the full internet IPv4 and IPv6 table. But on the other 2 AGG/BNG routers deployed, we haven't been able to turn on the L3HW offloading. As soon as we turn it on, a lot of stuff breaks. The config is correct for single linux bridge approach, and as long as we keep it running on CPU, no issues, but they run at +40% CPU usage. When offloading is enabled, CPU drops as expected, everything seems alright, but a lot of routes break, like they are incorrectly offloaded to the ASIC. We have a downstream AC router that contains over 2,100 pppoe connections, so lots of /32 routes there, and a LOT of those routes become unreachable from the upstream CCR2216 BNG as soon as L3HW is turned on. Turn it off back to CPU, problems solved. There is another weirdness going on with the fasttrack offloading also, but it is too much stuff to detail here. We opened up a ticket with Mikrotik, but it hasn't even been seen yet. We are kind of screwed here, because going back to the 1072's is a no-no, the config was heavily modified to accommodate the single vlan filtered bridge approach. These BNG routers run a lot of carrier stuff like MPLS, VPLS transports for commercial customers, OSPF, BFD, CGNat, dhcpv6 with ND, etc. So whatever is breaking L3HW-offloading is a combination of our carrier setup with something going on in RouterOS. We upgraded to this version in hopes that the bridge and l3hw stuff included would fix it, but nope. I'm at a loss here. Maybe someone here at Mikrotik could hear us out? We are HEAVILY invested in top end MikroTik equipment, and it would be devastating for us to have to scrap it to jump over to Juniper or some other vendor. Thank you!!
Re: v7.18 [stable] is released!
Posted: Sun Mar 09, 2025 3:01 pm
by xakep7
I can see a massive increase in latency spikes and loss after upgrading to v7.18 on multiple CCR2004-1G-12S+2XS
Same problem at CCR1072 and v7.18.1

Problems: Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 7:06 pm
by WhileECoyote
Hi,
I have "funny Problem" with cAPGi-5HaxD2HaxD and the 7.18.1 and the latest 7.17.2 Version, Only the 7.18 Version works flawlessly:
Some Android devices (mainly with Mediatek AC or AX Chipset, but also some Linux machines with Intel 210 AX Wifi Nics) have tthe Problem that they
don't see the SSID of the 5 GHz Band, when 7.18.1 or 7.17.2 Version.
After rescanning several time, sometimes they are able to "see" it but still unable to connect, because they say in the logs the SSID disappears.....
ONLY the 7.18 Work fine regarding this issue - don't know why.
First I thoght it is a simpley "country setting" issu, but no, it has nothing to do with dhe channel or country selection, even I I use only the Channel 36-42 the issue is absolutely the same .
I am a bit disappointed that the issure re-occured with the last Update 7.18.1 though.....
The Other Problem which exists with ALL Versions so far, my Linux machine with Intel 210AX does only connect on 5 GHz in 300N Mode, not AC and not AX.... but Just for the record, I didn't examine that problem too deep yet...
Cheers
4920441
Re: Problems: Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 7:52 pm
by itimo01
Hi,
I have "funny Problem" with cAPGi-5HaxD2HaxD and the 7.18.1 and the latest 7.17.2 Version, Only the 7.18 Version works flawlessly:
Some Android devices (mainly with Mediatek AC or AX Chipset, but also some Linux machines with Intel 210 AX Wifi Nics) have tthe Problem that they
don't see the SSID of the 5 GHz Band, when 7.18.1 or 7.17.2 Version.
After rescanning several time, sometimes they are able to "see" it but still unable to connect, because they say in the logs the SSID disappears.....
ONLY the 7.18 Work fine regarding this issue - don't know why.
First I thoght it is a simpley "country setting" issu, but no, it has nothing to do with dhe channel or country selection, even I I use only the Channel 36-42 the issue is absolutely the same .
I am a bit disappointed that the issure re-occured with the last Update 7.18.1 though.....
The Other Problem which exists with ALL Versions so far, my Linux machine with Intel 210AX does only connect on 5 GHz in 300N Mode, not AC and not AX.... but Just for the record, I didn't examine that problem too deep yet...
Cheers
4920441
Intel AX210 has some quite limited frequency range on 5ghz.
Got my own experience with that and BE200.
Try changing it to something like 5500mhz.
Up to channel 128 works fine tho
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 10:44 pm
by Davis
Regarding the small diskspace on devices with 16 MB flash, I really hope that MikroTik will split the
routeros package in several smaller packages for RouterOS 7.x like it is done for RouterOS 6.x.
Likely this would be the right thing to do, especially after reassuring the users that 16 MB flash won't have issues with updates (e.g.
in this thread back from RouterOS 6 era when the 16 MB flash devices were introduced).
I think absence of
planned obsolescence is one of the things keeping MikroTik users loyal to the brand (having the inertia not to explore/evaluate/investigate alternatives).
And for the users having this issue I suggest considering clearing the console history. If console (SSH) is used a lot and history never has been cleared, then it could consume some disk space. The console history can be cleared with:
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 10:52 pm
by mkx
/console/clear-history
I tried this on my hAP ac2 running 7.18.1 (without wifi or wireless). The effect: free-hdd-space went from 2492.0KiB to 2556.0KiB ... so 64KiB freed ... not too bad.
Re: v7.18.1 [stable] is released!
Posted: Sun Mar 09, 2025 11:11 pm
by infabo
On my cap ac - which I very rarely log in - it went from 407KiB to 472KiB. And from 220KiB to 284KiB on my D53G-5HacD2HnD (this device was netinstalled with keep-configuration a few days ago). This is awesome! I did not even know that history can be cleared. There should be an option: "enable volatile history" which is saved in RAM only.
@Davis Thank you for this brilliant tip!
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 6:20 am
by sirbryan
If someone could hear us out... We are in deep trouble with Mikrotik. We bought 12 CCR2216's to replace our aging 1072 fleet (we are a mid sized FTTH/Wireless ISP).
This warrants its own ticket to support and/or its own thread. There's too much to unpack here to address it in the 7.18.1 release thread.
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 9:16 am
by fibracapi
I'm having issues with IoT and smartlife devices since I upgraded to 7.18.1
Automations don't work as they should using Hap ac2 as AP capsman and AX2 lite as router.
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 9:52 am
by erlinden
What does "Automations don't work as they should" mean?
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 9:52 am
by LordNikkon
I installed 7.18.1 on L009 and i noticed that after some time (day maybe two) of transfering data over IPsec, router is rebooting with such information - "router was rebooted without proper shutdown, probably kernel failure" and next "kernel failure in previous boot". As i can see 7.18.1 maybe soved problem with Open VPN on MMIPS routers but add someting new.
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 10:00 am
by infabo
If someone could hear us out... We are in deep trouble with Mikrotik. We bought 12 CCR2216's to replace our aging 1072 fleet (we are a mid sized FTTH/Wireless ISP).
@elcano89 you surely bought the 12 CCR2216 units directly from an official MikroTik distributor. Since you have already created a MikroTik support ticket, I would recommend contacting your distributor as well, explaining the issue and providing your SUP number. A distributor might have a better chance of being heard by MikroTik than just being one of many support requests.
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 11:56 am
by dibatech
Back to Home missing after upgrading to 7.18.1
L41G-2axD arm hAP ax lite
Not in CLI or Winbox Latest
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 2:46 pm
by erlinden
What does /ip/cloud/print say?
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 4:07 pm
by dibatech
[admin@xxx-AP3] > /ip cloud/print
ddns-enabled: yes
ddns-update-interval: none
update-time: yes
public-address: 212.xx.xx.xx
dns-name: he80xxxxx.sn.mynetname.net
status: updated
warning: Router is behind a NAT. Remote connection might not work.
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 4:17 pm
by erlinden
That is weird, @dibatech! I would expect a line mentioning BTH. And as your router is ARM based, no reason AFAIK why it is not there.
What version were you running befor the upgrade? Did BTH work on that version?
Last resort: netinstall:
https://help.mikrotik.com/docs/spaces/R ... Netinstall
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 4:32 pm
by dibatech
Reset the router.
Back to Home options are back.
Thanks for the help.
Re: v7.18.1 [stable] is released!
Posted: Mon Mar 10, 2025 5:16 pm
by infabo
I would have created a supout.rif and sent it to Mikrotik support. Too late unfortunately. This could have been very interesting. Maybe you were at 7.8.1 and not 7.18.1?
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 9:43 am
by Splash
hi i have the same problem
could not save configuration changes, not enough storage space available.
cant upgrade .. have u found a solution without netinstall the device ?
br
mark
Solution: netinstall 7.17.2. This 7.18.1 was a running zombie. While up and running, I was unable to reboot by /system/reboot. It was not possible to downgrade. Uninstall extra packages as well not possible. Not even deleting all installed certificates did regain a single byte. Nothing. All these actions seem to have one common requirement: save configuration. If this fails, you're out of luck.
I have the same issue. (WAPAC) Deleting files does not free any disk space, console cleared, and cant reboot the device remotely. I find it truly shocking you cant reboot a device if there is no free disk available? I think there is an internal OS Partition which has filled up, and there is no way to clear out the usage such as temp files.
uptime: 6d19h56m24s
version: 7.18.1 (stable)
build-time: 2025-02-28 11:31:28
factory-software: 6.44.6
free-memory: 31.7MiB
total-memory: 128.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 672MHz
cpu-load: 1%
free-hdd-space: 0
total-hdd-space: 16.0MiB
write-sect-since-reboot: 29625
write-sect-total: 388563
architecture-name: arm
board-name: wAP ac
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 11:52 am
by kuzma2000
Solution: netinstall 7.17.2. This 7.18.1 was a running zombie. While up and running, I was unable to reboot by /system/reboot. It was not possible to downgrade. Uninstall extra packages as well not possible. Not even deleting all installed certificates did regain a single byte. Nothing. All these actions seem to have one common requirement: save configuration. If this fails, you're out of luck.
I have the same issue. (WAPAC) Deleting files does not free any disk space, console cleared, and cant reboot the device remotely. I find it truly shocking you cant reboot a device if there is no free disk available? I think there is an internal OS Partition which has filled up, and there is no way to clear out the usage such as temp files.
uptime: 6d19h56m24s
version: 7.18.1 (stable)
build-time: 2025-02-28 11:31:28
factory-software: 6.44.6
free-memory: 31.7MiB
total-memory: 128.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 672MHz
cpu-load: 1%
free-hdd-space: 0
total-hdd-space: 16.0MiB
write-sect-since-reboot: 29625
write-sect-total: 388563
architecture-name: arm
board-name: wAP ac
I had a similar problem.
This is a consequence of the RoOs successive upgrade.
At some point, RoOS does not partition the disk correctly when upgrading from version 6 to version 7.
Mikrotik mentioned this in one of the descriptions for the 7th line.
The only option for you is to export the configuration to the console, copy and save it as a script.
Next, NetInstall 7.18.1 and loading the configuration through the console or script.
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 2:59 pm
by Splash
I have the same issue. (WAPAC) Deleting files does not free any disk space, console cleared, and cant reboot the device remotely. I find it truly shocking you cant reboot a device if there is no free disk available? I think there is an internal OS Partition which has filled up, and there is no way to clear out the usage such as temp files.
uptime: 6d19h56m24s
version: 7.18.1 (stable)
build-time: 2025-02-28 11:31:28
factory-software: 6.44.6
free-memory: 31.7MiB
total-memory: 128.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 672MHz
cpu-load: 1%
free-hdd-space: 0
total-hdd-space: 16.0MiB
write-sect-since-reboot: 29625
write-sect-total: 388563
architecture-name: arm
board-name: wAP ac
I had a similar problem.
This is a consequence of the RoOs successive upgrade.
At some point, RoOS does not partition the disk correctly when upgrading from version 6 to version 7.
Mikrotik mentioned this in one of the descriptions for the 7th line.
The only option for you is to export the configuration to the console, copy and save it as a script.
Next, NetInstall 7.18.1 and loading the configuration through the console or script.
Thanks for the advice, It seems based on this that it is recommended to netinstall when moving from v6 to v7.
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 3:21 pm
by pe1chl
Thanks for the advice, It seems based on this that it would be recommended to netinstall when moving from v6 to v7.
Yes, that certainly is the case. Netinstall and import an export made just before (not a restore of a backup).
That will free up space, and prevent unexplainable problems as well.
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 4:00 pm
by Maggiore81
But we have some 2116 that were born with 7.8, that crashed brutally (bootloop) from 7.17.2 to 7.18
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 4:16 pm
by noradtux
I was already giving the same advice a few years ago, it's how I work...
example code
0) If it's a bug like the one reported above(Ā¹), you're fuāed anyway...
1) Make a binary backup
2) Make one export
3) Schedule the reload on A) REBOOT and on B) after xx minutes
(It depends on how long you think it will take to make the changes, usually 10 minutes is enough)
4) Do the work
5) Make again one export
6) Compare prev/next export for review the differencies
7) If all is OK remove scheduled reload on point 3)
(Ā¹)
viewtopic.php?p=1131405#p1131111
This sounds as horrible as the old technique of operating old Cisco IOS without Commit, where you would schedule a reboot and if by the time of the reboot you didn't cancel that reboot or if you didn't do a "copy running-config startup-config" you might be saved by the scheduled reboot.
I also used scripts in TCL for situations where I needed to change interface IPs and would lose access during the commands... A huge
GAMBIARRA.
I think it's worth considering the possibility of having 2 options...
- The first being "safe-mode" centric, as most current MikroTik users are used to.
- The second being "commit/rollback" centric, as most users of more robust equipment are used to.
Just to give you an example, Arista's EOS gives you 2 options!
- configure terminal, where the commands take effect immediately after being applied.
- configure session, where the commands only take effect at the time of commit.
Why can't MikroTik consider a way to deliver both possibilities and leave it up to the operator?
The ticket system allows submitting feature requests ;)
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 5:03 pm
by pe1chl
Besides that, RouterOS already offers a "configure session" in terminal mode! Most people do not know it...
When you enter a { in terminal mode, you enter a "block" (as in scripting) and you can enter commands, and when you enter } the block is closed and the commands are executed.
Only:
- it is not available in the GUI
- when a command has an error (other than a parsing error) it will not roll back the commands before it automatically
- there is no "test" mode other than the "safe mode".
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 8:19 pm
by Fif
I have a problem with SFP PON module on Heh S
After updating to 7.18.1, a problem appeared.
After a hot reboot, the link on the SFP port is not raised.
If the provider reboot the module remotely, everything is ok.
If I warm reboot the Hex S - the link on the SFP port does not rise.
I'm seeing similar problems with several different CRS devices using S+RJ10 SFP+ modules.
When running 7.18 and 7.18.1 , the links using S+RJ10 very often never complete autonegotation and the links never come up. Other links using DA cables or other SFP+ modules work fine.
Sometimes, bouncing the port down and up will establish the links.
The links always come up with RouterOS 7.17.2 and lower.
SFP info:
sfp-type: SFP/SFP+/SFP28/SFP56
sfp-connector-type: RJ45
sfp-link-length-copper-active-om4: 1m
sfp-vendor-name: MikroTik
sfp-vendor-part-number: S+RJ10
sfp-vendor-revision: 2.16
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 11:12 pm
by kuzma2000
I'm seeing similar problems with several different CRS devices using S+RJ10 SFP+ modules.
When running 7.18 and 7.18.1 , the links using S+RJ10 very often never complete autonegotation and the links never come up. Other links using DA cables or other SFP+ modules work fine.
Sometimes, bouncing the port down and up will establish the links.
The links always come up with RouterOS 7.17.2 and lower.
SFP info:
My ISP advised me to set the speed on the port manually.
Also I want to try to enable the "Ignore Rx Lose" option. But remotely I don't want to play this game :)
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 11, 2025 11:24 pm
by jbl42
The links always come up with RouterOS 7.17.2 and lower.
From 7.18 change log:
*) sfp,qsfp - improved initialization and linking;
Seems like the improvement is not so much an improvement for S+RJ10.
And it also seems MT does not test test their own SFP modules with their own ROS releases on their own devices.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 12, 2025 5:55 am
by Fif
I'm seeing similar problems with several different CRS devices using S+RJ10 SFP+ modules.
When running 7.18 and 7.18.1 , the links using S+RJ10 very often never complete autonegotation and the links never come up. Other links using DA cables or other SFP+ modules work fine.
Sometimes, bouncing the port down and up will establish the links.
The links always come up with RouterOS 7.17.2 and lower.
SFP info:
My ISP advised me to set the speed on the port manually.
Also I want to try to enable the "Ignore Rx Lose" option. But remotely I don't want to play this game :)
S+RJ10 are only supposed to run with auto-negotiation on.
I've tried to trim the advertised rates, but that didn't help.
Ignore Rx Loss seems to help, but I will not want to run an interface with that option enabled.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 12, 2025 10:22 am
by shlee
I've upgraded, and notice that my ipv4 NAT is masq to the same IP regardless of my srcnat rules.
The BTH dynamic NAT seems to be marked as "unknown" interface and it eating all of the masq?
I'm going to create a backup/regular wireguard user with full access.. disable the BTH and re-enable it.. see if the issue is fixed without me losing access via my primary BTH.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 10:23 am
by EdPa
What's new in 7.18.2 (2025-Mar-11 13:59):
*) console - fixed issue with file-name completion (introduced in v7.18);
*) container - fixed repository name handling to prevent redirect issues when basic authentication is used;
*) lte - additional fixes for eSIM management support;
*) lte - AT modems, improved redialing when modem lost connectivity without notifying host about APN status change;
*) netinstall - fixed socket reset (introduced in v7.18);
*) queue - fixed system failure when CAKE kind queue was configured but queue type definition does not exist anymore (introduced in v7.18);
*) wifi - improved stability for wifi interfaces;
*) winbox - improve graphing efficiency when communicating with WinBox;
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 11:19 am
by pe1chl
*) queue - fixed system failure when CAKE kind queue was configured but queue type definition does not exist anymore (introduced in v7.18);
Was the instability of CAKE that you previously mentioned really limited to having an interface with a CAKE queue and then deleting the queue type?
In the mention it seemed to be more complicated than that. Was it reduced to only this?
(i.e. can I go back to using CAKE in 7.18.1 without worry when I do not delete the type)
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 11:35 am
by ivicask
Updated HAP AX3 to 7.18.2 i just noticed this in log on boot
DoH server connection error: SSL: ssl: no trusted CA certificate found (6)
DoH server connection error: SSL: ssl: no trusted CA certificate found (6) [ignoring repeated messages]
DoH server connection error: SSL: ssl: no trusted CA certificate found (6)
DoH server connection error: SSL: ssl: no trusted CA certificate found (6) [ignoring repeated messages]
Im not using DoH in DNS settings (Use DoH is empty) and never used it, anybody knows whats this about?
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 11:43 am
by matiss
ivicask
Please send the supout.rif file from your device to
support@mikrotik.com
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 11:43 am
by erlinden
Im not using DoH in DNS settings (Use DoH is empty) and never used it, anybody knows whats this about?
Can you share your config? Just to be sure...
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:25 pm
by markonen
The folks reporting increased latency and packet loss with 7.18 have really dampened my enthusiasm to upgrade. Anyone gotten to the bottom of that yet?
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:31 pm
by ivicask
Im not using DoH in DNS settings (Use DoH is empty) and never used it, anybody knows whats this about?
Can you share your config? Just to be sure...
ip dns
set cache-max-ttl=5d cache-size=5000KiB doh-max-concurrent-queries=5000 max-concurrent-queries=5000 max-concurrent-tcp-sessions=50 servers=192.168.2.2 verify-doh-cert=yes
@matiss sent supout
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:34 pm
by wispmikrotik
Can you share your config? Just to be sure...
ip dns
set cache-max-ttl=5d cache-size=5000KiB doh-max-concurrent-queries=5000 max-concurrent-queries=5000 max-concurrent-tcp-sessions=50 servers=192.168.2.2 verify-doh-cert=yes
@matiss sent supout
Hi,
If you don't use DoH why do you have it enabled? I understand that it will be a bug, because it won't let you configure it if you don't set use-doh to yes.
Regards,
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:53 pm
by ivicask
ip dns
set cache-max-ttl=5d cache-size=5000KiB doh-max-concurrent-queries=5000 max-concurrent-queries=5000 max-concurrent-tcp-sessions=50 servers=192.168.2.2 verify-doh-cert=yes
@matiss sent supout
Hi,
If you don't use DoH why do you have it enabled? I understand that it will be a bug, because it won't let you configure it if you don't set use-doh to yes.
Regards,
I already did that, i enabled it and entered random letter "a" and then set verify-doh=no then disabled it and looks good.
export
/ip dns
set cache-max-ttl=5d cache-size=5000KiB doh-max-concurrent-queries=5000 max-concurrent-queries=5000 max-concurrent-tcp-sessions=50 servers=192.168.2.2
But then reboot router, its back to verify-doh-cert=yes and error messages.
But regardless seams as bug, if field use DoH is empty it should not check certificates.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:55 pm
by rextended
Open separate topics, don't mix everything in here, it's already hard to understand anything.
When you've done it elsewhere, write the results here.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:57 pm
by itimo01
The folks reporting increased latency and packet loss with 7.18 have really dampened my enthusiasm to upgrade. Anyone gotten to the bottom of that yet?
Well my pingtest is only in local net but i don't see any issues here.
The other ones aren't updated yet.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 12:58 pm
by matiss
Can you share your config? Just to be sure...
ip dns
set cache-max-ttl=5d cache-size=5000KiB doh-max-concurrent-queries=5000 max-concurrent-queries=5000 max-concurrent-tcp-sessions=50 servers=192.168.2.2 verify-doh-cert=yes
@matiss sent supout
We reviewed the received supout.rif file.
One of the netwatch probes calls the script which configure DoH client. A DoH certificate verification is enabled, a certificate that can validate DoH server certificate is not imported.
A few seconds before you logged into the device, the DNS settings were changed again, and the DoH client was removed.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 1:14 pm
by ToTheFull
All good here so far latency/DoH wise!
Edit: Updated router @ 11:04 today, I don't see anything out of the ordinary.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 1:17 pm
by ivicask
All good here now i had to reinstall certificates, but it seams update deleted DOH certificates for me, i have it only as failover, im not using it, it got me confused with message after update.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 2:16 pm
by ela002
With 1472 KiB free space can I upgrade from 7.16.2 without problems?
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 2:22 pm
by lilianmoraru
Getting a lot of these error logs since the update to 7.18.1, from 7.17, on LHG LTE18:
š“ļø 2025-03-06 14:48:04 lte;error lte1 mbim: >>> E #46 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:04 lte;error lte1 mbim: >>> E #47 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:04 lte;error lte1 mbim: >>> E #48 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:04 lte;error lte1 mbim: >>> E #49 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:05 lte;error lte1 mbim: >>> E #50 - ms uicc: 2, error: MS_SELECT_FAILED
š“ļø 2025-03-06 14:48:27 lte;error lte1 mbim: >>> E #51 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:27 lte;error lte1 mbim: >>> E #52 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:27 lte;error lte1 mbim: >>> E #53 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:27 lte;error lte1 mbim: >>> E #54 - ms uicc: 3, error: MS_INVALID_LOGICAL_CHANNEL
š“ļø 2025-03-06 14:48:28 lte;error lte1 mbim: >>> E #55 - ms uicc: 2, error: MS_SELECT_FAILED
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 4:02 pm
by fragtion
With 1472 KiB free space can I upgrade from 7.16.2 without problems?
Should be fine IMO. the difference is nowhere near that much. even 500k would surprise me
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 12, 2025 4:14 pm
by kuzma2000
I'm seeing similar problems with several different CRS devices using S+RJ10 SFP+ modules.
When running 7.18 and 7.18.1 , the links using S+RJ10 very often never complete autonegotation and the links never come up. Other links using DA cables or other SFP+ modules work fine.
Sometimes, bouncing the port down and up will establish the links.
The links always come up with RouterOS 7.17.2 and lower.
SFP info:
My ISP advised me to set the speed on the port manually.
Also I want to try to enable the "Ignore Rx Lose" option. But remotely I don't want to play this game :)
Manually setting the speed on the SFP PON helped me.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 4:50 pm
by xakep7
The folks reporting increased latency and packet loss with 7.18 have really dampened my enthusiasm to upgrade. Anyone gotten to the bottom of that yet?
By now i downgraded to 7.17.2 and packet loss gone, latency returned to stable and normal.
7.18.2 i'm not testing yet.
By the way it may be because of CRS317 LACP which connected to CCR1072, but problem is strange.
Problem starting from updating to 7.18.1 and solved by downgrading to 7.17.2, rebooting CRS317.
The folks reporting increased latency and packet loss with 7.18 have really dampened my enthusiasm to upgrade. Anyone gotten to the bottom of that yet?
Well my pingtest is only in local net but i don't see any issues here.
The other ones aren't updated yet.
The problem appears when traffic through CCR1072 is more than 2-3 Gbps duplex at 7.18.1.
CPU load less than 3%, highest core - 50%.
CCR1072 used only for BGP (3 x FW + 2 x IX + 1 x IPv6 FW) and some RAW rules.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 4:59 pm
by Maggiore81
At the moment I upgraded all my routers to 7.18.1 with no issue (except a 2116 that went into a reboot loop and needed netinstall).
The 7.18.1 at the moment is running fine, with visible benefits thanks to IPv6 fast-track.
I have a mix of 326 with l3-hw working fine, some CCR2004 dont upgrade for the error of lack of space... the other went fine.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 8:58 pm
by inazmul
Great release Thank you Mikrotik Team
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 9:28 pm
by RedOnion
*) wifi - improved stability for wifi interfaces;
As an AX3 user I have my fingers crossed!
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 12, 2025 9:55 pm
by S8T8
Is possible to have a list of know issues with the latest v7.18.2 release?
Increase in latency spikes is confirmed?
Don't know if this is possible but for low memory devices with USB port, connecting small USB drive could be used to extend main flash drive?
Should be nice to have an option to format and aggregate archive.
Re: v7.18.1 [stable] is released!
Posted: Wed Mar 12, 2025 11:29 pm
by Fif
I'm seeing similar problems with several different CRS devices using S+RJ10 SFP+ modules.
When running 7.18 and 7.18.1 , the links using S+RJ10 very often never complete autonegotation and the links never come up. Other links using DA cables or other SFP+ modules work fine.
Same problem with 7.18.2.
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 3:25 am
by TMS1
Is the upgrade packages are really downloaded via http? Why? And took very long time to download 7.18.2 few minutes ago.
Upgrade_download_via_http_small-2025-03-13 021326.jpg
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 4:56 am
by nichky
why OVPN-Client doesn't show remote address?
also , probably we need one parameter at the client site, to tell us whether we are running tun or tap.
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 8:23 am
by Jotne
Is the upgrade packages are really downloaded via http? Why? And took very long time to download 7.18.2 few minutes ago.
Why not? I can confirm its http (not https). There are no sensitive data in those data.
For my test RB951 it just tok some seconds to download the latest 7.19beta4
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 8:29 am
by mkx
Is the upgrade packages are really downloaded via http? Why?
Why not?
If https is used, then client can verify authenticity of server it's talking to.
Yes, npk files do have some verification built in (I believe that packages are digitally signed by MT so it's not trivial to alter the contents). But two layers of security are better than one. And we definitely don't want to install some hacked versions of ROS, do we?
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 9:09 am
by wispmikrotik
Hi,
Many issues with the SFP in hexS, constant down/up.
It had to be downgraded after 10 minutes.
Regards,
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 13, 2025 9:37 am
by shlee
I've upgraded, and notice that my ipv4 NAT is masq to the same IP regardless of my srcnat rules.
The BTH dynamic NAT seems to be marked as "unknown" interface and it eating all of the masq?
I'm going to create a backup/regular wireguard user with full access.. disable the BTH and re-enable it.. see if the issue is fixed without me losing access via my primary BTH.
1. I can recreate this by disabling BTH and re-enabling it.. same issue
2. The bandaid fix is to move the broken dynamic rule down, and create a manual fixed rule for the correct interface.
Created bug ticket SUP-182348

Re: v7.18.1 [stable] is released!
Posted: Thu Mar 13, 2025 10:09 am
by oreggin
Regarding the small diskspace on devices with 16 MB flash, I really hope that MikroTik will split the
routeros package in several smaller packages for RouterOS 7.x like it is done for RouterOS 6.x.
Likely this would be the right thing to do, especially after reassuring the users that 16 MB flash won't have issues with updates (e.g.
in this thread back from RouterOS 6 era when the 16 MB flash devices were introduced).
Hereās the legend: at a computer trade show in 1981, Bill Gates supposedly uttered this statement, in defense of the just-introduced IBM PCās 640KB usable RAM limit: ā640K ought to be enough for anybody.ā
If MTik have apply a diet on routeros and makes separate builds for some kind of usage types (wireless, other) then that would not resolve this issue just win some time. These 16M flash devices mainly wireless stuffs, maybe skipping unrelated functions from this kind of build win some space and time. It is uncomfortable only for endusers, yet...
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 3:04 pm
by Fif
Many issues with the SFP in hexS, constant down/up.
It had to be downgraded after 10 minutes.
Which SFP modules are having issues?
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 4:11 pm
by pe1chl
Why not?
If https is used, then client can verify authenticity of server it's talking to.
Yes, npk files do have some verification built in (I believe that packages are digitally signed by MT so it's not trivial to alter the contents). But two layers of security are better than one. And we definitely don't want to install some hacked versions of ROS, do we?
Digitally signed by MT provides the same protection as having https on the connection, but additionally it protects agains other methods of getting bad packages.
There does not appear to be anyone outside MT who can create packages that work under RouterOS. So the http downloading is not a weakness, and in fact it is the base for having local repositories with cached packages. (System->Package->Local Package Sources).
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 4:48 pm
by dynek
Has anyone been able to run an haproxy container on 7.18 ?
No matter what I do it always fails with:
[cont] failed to extract layer
was unable to import, container ......
Re: v7.18 [stable] is released!
Posted: Thu Mar 13, 2025 5:01 pm
by anav
holvoe, can you comment on the wifi changes, good bad ugly??
I am not seeing much difference but then again I am lucky enough not to have those problems with disconnects like some others do.
You have the only ax3 made in Latvia then. ;-)
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 5:23 pm
by wispmikrotik
Many issues with the SFP in hexS, constant down/up.
It had to be downgraded after 10 minutes.
Which SFP modules are having issues?
For example:

Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 5:34 pm
by spippan
Why not?
If https is used, then client can verify authenticity of server it's talking to.
Yes, npk files do have some verification built in (I believe that packages are digitally signed by MT so it's not trivial to alter the contents). But two layers of security are better than one. And we definitely don't want to install some hacked versions of ROS, do we?
there is no real safety issue or problem downloading routeros packages via HTTP instead HTTPS...
ever upgraded a linux server? nearly every package is also downloaded via HTTP (e.g. in "apt upgrade"...)
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 5:55 pm
by rextended
Anyone can make a certificate these days.
It's all become so trivial...
The purpose of https is to encrypt the connection between two points, not to certify what passes through it...
However, yes, .npk files have 32 bit of signature at the end (and also .dpk, and also .fwf) so they can't be tampered with.
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 6:47 pm
by mkx
ever upgraded a linux server?
A milion times (literally).
nearly every package is also downloaded via HTTP (e.g. in "apt upgrade"...)
Not on my servers, I always edit sources.list and change http to https.
Just to be clear: personally I don't see any issue with http for fetching packages. I was simply stating one (and possibly only) reason to use https (I thought that my second paragraph cleared things, but it obviously didn't).
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 7:25 pm
by pe1chl
Windows Update uses http as well... (it uses https to determine what updates to download, and then downloads the actual updates over http)
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 7:27 pm
by rextended
The fles are signed, why uselessly use cpu power to encrypt/decrypt what is already signed?
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 7:28 pm
by itimo01
(e.g. in "apt upgrade"...)
Thats why i use EL-Based :)
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 8:52 pm
by gavopp
HOW I DOWNGRADE TO 7.18.1?
I just update and i got tons of drops on network.
I use VLAN tagged network for split regular network from audio low latency network.
7.18.1 was just fine.
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 8:58 pm
by itimo01
HOW I DOWNGRADE TO 7.18.1?
I just update and i got tons of drops on network.
I use VLAN tagged network for split regular network from audio low latency network.
7.18.1 was just fine.
Just upload npk files and downgrade.
Google is your friend
https://help.mikrotik.com/docs/spaces/R ... g+RouterOS
Re: v7.18.1 [stable] is released!
Posted: Thu Mar 13, 2025 9:09 pm
by ToTheFull
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 ...
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:
2025-03-04T01:01:17+01:00 MikroTik HeadOffice possible SYN flooding on tcp port 53
2025-03-04T06:06:52+01:00 MikroTik Branch3 possible SYN flooding on tcp port 53
2025-03-04T08:24:20+01:00 MikroTik Branch4 possible SYN flooding on tcp port 53
2025-03-04T08:52:10+01:00 MikroTik Branch2 possible SYN flooding on tcp port 53
I get this when just 1 PC boots up, did you find a reason for it ?
My thoughts were some kind of game lobby or game server search tool spamming the local DNS
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 13, 2025 11:17 pm
by udotirol
after upgrading three Audience Mesh (RBD25G-5HPacQD2HPnD) from 7.16 to 7.18.2, I am no longer able to login, neither using the web interface nor WinBox.
The web interface shows "Authentication failed: invalid username or password.", even though those credentials were the ones I used just a couple of minutes ago to trigger the update. Not sure how to proceed now, because I can't access the devices any longer and so I can't produce supout.rif for example.
Apparently, all the rest appears to be working, basic networking, WIFI, RADIUS, CAPsMAN, ...
For what it matters, the passwords I'm using there is very strong and come with a very special characters, so maybe the upgrade didn't appreciate some of those special characters ...
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 12:10 am
by TMS1
Anyone can make a certificate these days.
It's all become so trivial...
The purpose of https is to encrypt the connection between two points, not to certify what passes through it...
However, yes, .npk files have 32 bit of signature at the end (and also .dpk, and also .fwf) so they can't be tampered with.
Yes! Maybe I don't want to share info with my ISP or anyone else about what I downloaded...
Thanks for the clarification, it gives a fairly strong protection against tampering to the downloaded files.
Re: v7.18.1 [stable] is released!
Posted: Fri Mar 14, 2025 12:44 am
by pe1chl
2025-03-04T01:01:17+01:00 MikroTik HeadOffice possible SYN flooding on tcp port 53
2025-03-04T06:06:52+01:00 MikroTik Branch3 possible SYN flooding on tcp port 53
2025-03-04T08:24:20+01:00 MikroTik Branch4 possible SYN flooding on tcp port 53
2025-03-04T08:52:10+01:00 MikroTik Branch2 possible SYN flooding on tcp port 53
I get this when just 1 PC boots up, did you find a reason for it ?
My thoughts were some kind of game lobby or game server search tool spamming the local DNS
For now I fixed it by having a dedicated Linux VM serve as the DNS resolver for the network.
But of course I would prefer it when MikroTik solve this problem.
I configured a max of 1000 TCP connections to the DNS resolver, it did not issue an error or warning about that, but clearly it is by far not able to handle that many parallel TCP connections because it disables the TCP port long before that because of "possible SYN flooding".
Re: v7.18 [stable] is released!
Posted: Fri Mar 14, 2025 6:15 am
by shlee
I can see a massive increase in latency spikes and loss after upgrading to v7.18 on multiple CCR2004-1G-12S+2XS
Same problem at CCR1072 and v7.18.1
edited: Nevermind. Likely not related.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 8:41 am
by mkx
For what it matters, the passwords I'm using there is very strong and come with a very special characters, so maybe the upgrade didn't appreciate some of those special characters ...
It could be the issue between GUI and ROS regarding character coding. IIRC MT is doing some minor tweaks in this regard (switching from not taking care about character coding at all towards UTF-8).
So I recommend you to try using different UI options (winbox, webfig, CLI). If everything else fails, you can netinstall to previously running version ... and make sure you select "Keep old configuration". After that, change passwords to something not using non-ASCII characters as using those can cause problems (as you found out).
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 11:20 am
by pe1chl
In any system that involves things like scripting languages, web interfaces, etc I at least avoid these characters all the time:
@ % " $ & # + < > (space)
That never hurts even when it is not really necessary.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 2:35 pm
by mkx
In any system that involves things like scripting languages, web interfaces, etc I at least avoid these characters all the time:
@ % " $ & # + < > (space)
That never hurts even when it is not really necessary.
And I'd say that all multi-byte characters (UTF-8 or any other multi-byte encoding) are problematic as well.
All characters which occupy different byte-values depending on character set used; example: Ć has byte value of 0xC4 in ISO-8859-1 and Windows-1250, 0x8E in CP437 and CP850, 0x80 in Mac OS Roman (and U+00C4 in UTF-8).
Not to mention even fancier characters, which don't exist in all the different character sets, such as Latvian Å : ISO-8859-4 (ISO character set to be used in Latvia) has it at byte value of 0xA9, ISO-8859-2, Windows 1250 and Windows 1252 have it at 0x8A, ISO-8859-1, Mac OS roman, CP850 and CP437 don't have it, UTF-8 code is U+0160.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 3:59 pm
by TMS1
after upgrading three Audience Mesh (RBD25G-5HPacQD2HPnD) from 7.16 to 7.18.2, I am no longer able to login, neither using the web interface nor WinBox.
:
For what it matters, the passwords I'm using there is very strong and come with a very special characters, so maybe the upgrade didn't appreciate some of those special characters ...
Thanks for the heads-up on passwords containing very special characters.
Are you sure you are trying to login from an authorized IP address via authorized network?
If you have the password in a pw manager did you try to copy & paste the the password?
Did you try WinBox MAC also?
Do you have the opportunity to login via SSH key-authentication?
Or MikroTik mobile app?
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 4:09 pm
by TMS1
In any system that involves things like scripting languages, web interfaces, etc I at least avoid these characters all the time:
@ % " $ & # + < > (space)
That never hurts even when it is not really necessary.
And I'd say that all multi-byte characters (UTF-8 or any other multi-byte encoding) are problematic as well.
Guys do you have a comprehensive list about it?
I would add the not-disclosed password length limitation to that :).
A system accepted my long password when I created, then during the authentication I had to specify a shorter, truncated version of the password.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 4:58 pm
by rpingar
in 7.18-7.18.2 we are observing some irresponsivnes of rotuer where there have several hundreds pppoe clients autenticated.
we are not able to get snmp info, the pppoe clients get disconnected, not all, just around 90% and after 5-10mins the router come back to normal where there are simple queue and dhcp-ipv6 applied to unknown interfaces. So the only way to receover the full functionality (delete queues and dhcp-ipv6) is to reboot.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 5:36 pm
by mkx
And I'd say that all multi-byte characters (UTF-8 or any other multi-byte encoding) are problematic as well.
Guys do you have a comprehensive list about it?
Regarding characters: just take the basic US ASCII characters ... and exclude the characters mentioned by @pe1chl ... and you should be safe. As to passphrase length ... it's up to each system and its requirements.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 14, 2025 6:36 pm
by pe1chl
Well, there may be an issue with 7.18.2 after all... I netinstalled a wAP ac (old MIPBE version), I could connect it via MAC-TELNET, setup a password for admin (8 ASCII alphanumeric characters), could still login, then I added the wireless package (netinstall was only base package) and did a reset-configuration with keep-users=yes and now I can't login anymore, both blank password and my set password no longer work.
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 9:08 am
by bbs2web
We've logged a query with support (SUP-182534), in that RADIUS accounting packets sent by RouterOS 7.18.2 formats the MAC address as xx-xx-xx-xx-xx-xx, instead of the configured method (xx:xx:xx:xx:xx:xx). This results in identity awareness not being enriched and forwarded to firewalls when users are connected to 802.1X WiFi (EAP-TLS) networks.
RADIUS accounting MAC format is wrong.png
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 11:10 am
by qbic
QQ: is it safe to upgrade routerboard firmware to v7.18.2 in RB4011? In the past I've had stability issues and I've found that "firmware" 7.7 to be behaving okay.
QQ2: Is there any changelog to routerboard firmware?
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 11:24 am
by mkx
QQ: is it safe to upgrade routerboard firmware to v7.18.2 in RB4011? In the past I've had stability issues and I've found that "firmware" 7.7 to be behaving okay.
I don't see too many reports regarding instability of recent ROS/routerboard versions on RB4011 ... so your observations might be related to your particular configuration (either configuration is marginalky wrong or it triggers some obscure bug). In which case you'll have to make some effort to identify (as precisrly as possible) the condition triggering the problem ... and communicate it directly to Support. Without doing it the problem might bever be corrected.
QQ2: Is there any changelog to routerboard firmware?
There isn't a dedicated changelog for routerboard firmware. Occasionally there are changes, mentioned in ROS changelog. But that doesn't mean there aren't other changes in firmware which aren't important (to MT at least) to be mentioned. OTOH I remember that changes in firmware were not frequent already in times when routerboard firmware version was unrelated to ROS version ... and I'd expect that routerboard firmware for mature devices (such as RB4011) doesn't change very often (apart from version number).
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 11:37 am
by bajodel
QQ: is it safe to upgrade routerboard firmware to v7.18.2 in RB4011? In the past I've had stability issues and I've found that "firmware" 7.7 to be behaving okay.
QQ2: Is there any changelog to routerboard firmware?
QQ1 >> Yes, I think so. I've been using a RB4011 for my lab setup in the last 2 years upgrading w/o any issue. I switched to RB5009 just recently (a couple of weeks ago).
QQ2 >> not really, but using some grep magic you can extract some info from changelog:
What's new in 7.18 (2025-Feb-24 10:47):
*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
*) routerboot - disable packet switching during etherboot for hEX refresh ("/system routerboard upgrade" required);
*) routerboot - improved stability for IPQ8072 ("/system routerboard upgrade" required);
What's new in 7.17.2 (2025-Feb-06 11:10):
*) device-mode - do not allow changing CPU frequency if "routerboard" is not allowed by device mode (introduced in v7.17);
What's new in 7.17 (2025-Jan-16 10:19):
!) device-mode - after upgrade, mode "enterprise" is renamed to "advanced" and traffic-gen, partition (command "repartition"), routerboard and install-any-version features will be disabled;
*) device-mode - added routerboard, install-any-version and partitions features;
*) ethernet - improved linking after reboot for hAP ax lite devices ("/system routerboard upgrade" required);
*) routerboot - fixed boot MAC for devices with Alpine CPU ("/system routerboard upgrade" required);
*) routerboot - fixed boot MAC for MIPSBE CRS3xx and CRS5xx switches ("/system routerboard upgrade" required);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used ("/system routerboard upgrade" required);
*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices ("/system routerboard upgrade" required);
What's new in 7.16.2 (2024-Nov-26 14:09):
*) ethernet - improved linking after reboot for hAP ax lite devices ("/system routerboard upgrade" required);
*) routerboot - improved stability for IPQ8072 and IPQ6010 when flash-boot is used ("/system routerboard upgrade" required);
What's new in 7.16.1 (2024-Oct-10 17:03):
*) sfp - improved initialization for certain SFP modules on CRS309 and CRS317 devices ("/system routerboard upgrade" required);
What's new in 7.16 (2024-Sep-20 16:00):
*) routerboard - improved Etherboot stability for CRS320-8P-8B-4S+ device ("/system routerboard upgrade" required);
*) routerboard - improved Etherboot stability for IPQ-40xx devices ("/system routerboard upgrade" required);
*) routerboot - improved boot process ("/system routerboard upgrade" required);
*) system - set flash-boot mode as "boot-device" after system reset initiated by reset button ("/system routerboard upgrade" required);
What's new in 7.15.3 (2024-Jul-24 13:36):
*) routerboard - improved Etherboot stability for CRS320-8P-8B-4S+ device ("/system routerboard upgrade" required);
What's new in 7.14 (2024-Feb-29 09:10):
*) routerboard - added "reset-button" support for RBwAPR-2nD device;
What's new in 7.13.2 (2024-Jan-12 11:51):
*) routerboard - added "reset-button" support for RBwAPR-2nD device;
What's new in 7.12 (2023-Nov-09 09:45):
*) routerboard - added "reset-button" support for RB800, RB1100 and RB1100AHx2 devices;
*) routerboard - fixed "reset-button" support for wAP ac and wAP R ac devices;
What's new in 7.11 (2023-Aug-15 09:33):
*) routerboard - fixed "gpio-function" setting on RBM33G ("/system routerboard upgrade" required);
*) routerboard - improved RouterBOOT stability for Alpine CPUs ("/system routerboard upgrade" required);
*) routerboard - removed unnecessary serial port for netPower16P and hAP ax lite devices ("/system routerboard upgrade" required);
*) routerboot - increased etherboot bootp timeout to 40s on MIPSBE and MMIPS devices ("/system routerboard upgrade" required);
What's new in 7.10 (2023-Jun-15 08:17):
*) routerboard - fixed memory test on CCR2116-12G-4S+ ("/system routerboard upgrade" required);
*) routerboard - improved RouterBOOT stability for Alpine CPUs ("/system routerboard upgrade" required);
*) routerboot - increased "preboot-etherboot" maximum value to 30 seconds ("/system routerboard upgrade" required);
What's new in 7.9.2 (2023-May-30 16:49):
*) routerboard - improved RouterBOOT stability for Alpine CPUs ("/system routerboard upgrade" required);
What's new in 7.9 (2023-May-02 08:35):
*) routerboot - added "preboot-etherboot" and "preboot-etherboot-server" settings ("/system routerboard upgrade" required) (CLI only);
What's new in 7.8 (2023-Feb-24 11:03):
*) lte - LtAP improved modem detection in lower mini-PCie slot ("/system routerboard upgrade" required);
*) routerboot - fixed format storage for RBM33G device ("/system routerboard upgrade" required);
*) routerboot - fixed protected routerboot for RBM33G device ("/system routerboard upgrade" required);
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 12:30 pm
by BrateloSlava
QQ: is it safe to upgrade routerboard firmware to v7.18.2 in RB4011?
I have several 4011's in maintenance. No problems with 7.18.2 firmware.
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 1:56 pm
by qbic
Thanks for replies!
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 15, 2025 5:52 pm
by udotirol
after upgrading three Audience Mesh (RBD25G-5HPacQD2HPnD) from 7.16 to 7.18.2, I am no longer able to login, neither using the web interface nor WinBox.
:
For what it matters, the passwords I'm using there is very strong and come with a very special characters, so maybe the upgrade didn't appreciate some of those special characters ...
Thanks for the heads-up on passwords containing very special characters.
Are you sure you are trying to login from an authorized IP address via authorized network?
If you have the password in a pw manager did you try to copy & paste the the password?
Did you try WinBox MAC also?
Do you have the opportunity to login via SSH key-authentication?
Or MikroTik mobile app?
As explained in my post, I logged into the devices to update them with the very same credentials that don't work now after the update. Nothing else has changed, no IP address or whatever. In my case, the passwords were stored in Firefox, but to be entirely sure I also tried the ones I had stored in my keepass file, all to no avail. Tried via web and WinBox and SSH (haven't set up public key authentication, unfortunately ...), nothing worked. I'll try to reproduce the problem with another device still on 7.16 and the same password and see what happens ...
Re: v7.18.2 [stable] is released!
Posted: Sun Mar 16, 2025 1:05 am
by TMS1
As explained in my post, I logged into the devices to update them with the very same credentials that don't work now after the update. Nothing else has changed, no IP address or whatever. In my case, the passwords were stored in Firefox, but to be entirely sure I also tried the ones I had stored in my keepass file, all to no avail. Tried via web and WinBox and SSH (haven't set up public key authentication, unfortunately ...), nothing worked. I'll try to reproduce the problem with another device still on 7.16 and the same password and see what happens ...
Just few more ideas:
- Attempt to log in using the default credentials via the web interface, WinBox, or SSH.
- Netinstall as last resort
Re: v7.18.2 [stable] is released!
Posted: Sun Mar 16, 2025 11:54 am
by gotsprings
As explained in my post, I logged into the devices to update them with the very same credentials that don't work now after the update. Nothing else has changed, no IP address or whatever. In my case, the passwords were stored in Firefox, but to be entirely sure I also tried the ones I had stored in my keepass file, all to no avail. Tried via web and WinBox and SSH (haven't set up public key authentication, unfortunately ...), nothing worked. I'll try to reproduce the problem with another device still on 7.16 and the same password and see what happens ...
Update your winbox?
Re: v7.18.2 [stable] is released!
Posted: Sun Mar 16, 2025 1:39 pm
by infabo
Well, he tried to login via webinterface and SSH. I guess updating Winbox will not change anything.
Re: v7.18.2 [stable] is released!
Posted: Sun Mar 16, 2025 2:13 pm
by dvdhngs
Hello everybody! sorry if it's wrong place, but i have a little bug on newer version on web/dude, when the map is big horizontaly, the page is cutted, and the bottom scrollbar dont show, so cannot see itens on right side, i make some tests and found out that putting "overflow: auto" on <div class="acc-cont" id="areaid-General" aria-labelledby="tabid-General">, fix the problem, its possible someone do this on next update?
Re: v7.18 [stable] is released!
Posted: Mon Mar 17, 2025 3:01 pm
by fouinix
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...
Same here... I am not at home and I can't connect to my router to try to fix it.
I am really surprised of Mikrotik decision to not split packages. I also have a chateau LTE12, it also has 16MB.
Many devices, have 16MB, even a 100Gb switch at 1600$
https://mikrotik.com/product/crs518_16xs_2xq
I hope Mikrotik will fix soon. Else, that mean many devices will be bricked....
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 17, 2025 4:37 pm
by nmt1900
It is about time to acknowledge the "almost-obvious" - 16 MB devices should not be used as routers any more. Except maybe in absolute barebones-configuration cases. They can mostly function OK as access points and switches.
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 17, 2025 6:55 pm
by mkx
16 MB devices should not be used as routers any more.
For me, hAP ac2 without wireless or wifi-qcom-ac works great as router. With around 2MB flash free. But with admittedly pretty simple config.
So it's not "not as router" or "not as AP", rather it's "pretty barebone" which makes it possible to still run.
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 17, 2025 7:26 pm
by pe1chl
hAP ac2 without wireless or wifi-qcom-ac is not a reasonably expected use of that device.
Normally you would buy a hEX for that use-case.
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 17, 2025 7:40 pm
by infabo
Of course. But you can give a second life to a ac2 which otherwise would be thrown into trash bin.
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 17, 2025 7:41 pm
by CGGXANNX
i am using the hAP acĀ² as a wired only router too, with neither wireless nor wifi-qcom-ac installed. As such it's much better at routing than both the hEX 750Gr3 (3x faster) and the hEx refresh E50UG (1.5x faster), by having true 4 ARM cores instead of 2. IPsec and WireGuard are faster on the hAP acĀ² too. It even works better if you want a full-5-port managed switch with hardware offload for VLAN (you just have to configure it the old way instead of with Bridge VLAN Filtering). As a switch the new hEX refresh cannot have all 5 ports hardware offloaded. And in case you need inter-VLAN routing hAP acĀ² is better than the old hEX because the link between CPU and switch chip is 2Gbps instead of just 1Gbps (and the CPU is much stronger).
It even runs a small container.
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 17, 2025 7:47 pm
by mkx
hAP ac2 without wireless or wifi-qcom-ac is not a reasonably expected use of that device.
Normally you would buy a hEX for that use-case.
Well, for 33% of price increase one gets 300% faster device (when comparing RBD52G and RB750Gr3) ... OK, with half of RAM, but mine is one of the early ones with 256MB RAM. And better internal interconnect topology.
I don't know why that would be a bad deal (even for 128MB RAM device).
Yes, I agree that using h
AP without wireless is not "according to design expectations", but it does make lots of sense to me. Definitely more than using CRS as (edge) router (specially if config doesn't allow L3HW offload) and yet people do it.
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 11:14 am
by Valerio5000
Sorry Mikrotik but I think you are seriously underestimating the problems of 16MB flash devices. This weekend happened to me with my beloved AC2. I purchased this device in 2021 when there was still ROS v6, when v7 arrived at something like 7.5 I simply upgraded without any particular problems. With 7.13 (or 7.12? I don't remember) the Wifi-Wireless packets were split and I still thank you for making the AC2 series with a serious wifi but I encountered memory problems and decided to proceed with Netinstall. Since then I have never had any particular problems with memory considering that it is a home router with default configuration, Capsman, 2-3 custom rules in the firewall and several Wireguard and SSTP VPNs that it manages very well. Once I got to 7.17.2 I waited for 7.18.2 to be released and when I rebooted I found myself with a working router but again with 0 Kb free and without any possibility of doing anything, even a simple reboot was impossible. I accidentally discovered on this forum the command "/console/clear-history" (but why is it not reported in any official document? a list of useful commands for ROS maintenance would not be bad) that initially gave me about 50 Kb but once I rebooted I found myself again with 0 Kb free and no way to free up memory. I had to waste a lot of time to make a backup and proceed with netinstall. It would be much appreciated if Mikortik once and for all explained whether once netinstall has been executed the user can simply restore the backup file without the risk of restoring any residues or it is advisable (which is what I did) to use the .RSC file which however does not import certificates for example. However, netinstall was useful and I find myself with the same configurations with 250-350 Kb free with the router operating, without any configuration I had 380 Kb free. However, I find it a bit negative that by moving from a stable to a stable (7.17. 2 > 7.18. 2) I found myself in these conditions that I could accept with alpha-beta versions but not on stable versions. I believe that we need to find a quick solution for these 16MB flash devices (you have to accept the fact that it was in 2021 and still today a serious mistake of underestimation to introduce such small devices to the market) as reading on the forum it is a growing problem. Either a way is found to reduce the size of ROS, as many propose by dividing the packages or perhaps a way to ensure that netinstall is not necessary to free up space, in the end it is not clear what happens in the flash for which the space is reduced to such an extent that it can no longer be freed up unless formatted. Personally I have understood two things: I will avoid any future purchase of Mikrotik devices that do not have at least 128 MB of flash (I will never understand, in 2013 the entire 951 home series had 128 MB of RAM, what logic in reducing it 10 years later?!) and go very easy with future ROS updates at least on 16 MB devices, but I wonder if before the release of a stable version they really do some tests or not... Oh little tip: the new features related to USB disks are very nice but please put those "Disk" settings in order because it's total chaos like this!
Re: v7.18.1 [stable] is released!
Posted: Tue Mar 18, 2025 12:33 pm
by savage
After updating from 7.16.1 to 7.18.1 /export show-sensitive terse started showing new bogus interface
/interface ovpn-server server add mac-address=[...] name=ovpn-server1
While it's disabled by default, I would prefer default config and especially updates not to create bogus interfaces.
Also noticed this. Lo (Loopback) interface is also not exported.
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 12:39 pm
by noradtux
Strange, my ltap-mini still has like 3 megs of storage available with 7.18.2.
> /system/resource/print
uptime: 5d21h43m20s
version: 7.18.2 (stable)
build-time: 2025-03-11 11:59:04
factory-software: 6.42.1
free-memory: 22.9MiB
total-memory: 64.0MiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 650MHz
cpu-load: 3%
free-hdd-space: 3316.0KiB
total-hdd-space: 16.0MiB
write-sect-since-reboot: 699
write-sect-total: 78019
architecture-name: mipsbe
board-name: LtAP mini
platform: MikroTik
> /system/package/print
Flags: X - DISABLED; A - AVAILABLE
Columns: NAME, VERSION, BUILD-TIME, SIZE
# NAME VERSION BUILD-TIME SIZE
0 wireless 7.18.2 2025-03-11 11:59:04 1468.1KiB
1 routeros 7.18.2 2025-03-11 11:59:04 10.5MiB
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 12:44 pm
by infabo
Space issue primarily concerns ARM platform.
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 1:29 pm
by noradtux
I shall check the wAP once I have access :)
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 1:42 pm
by massinia
Space issue primarily concerns ARM platform.
Yes and things don't seem to improve in the new versions...
Today, for curiosity, I tried out routeros-7.20_ab147-arm.npk and the free space decreased even more but I'm sure that MikroTik will find a solution.
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 2:44 pm
by fernaandogarcia
Today we noticed a problem with v7.18.1. An update to v7.18.2 is planned.
Some PPPoE connections dropped but remained ghost queues.
When the user tries to perform a new authentication, it is not possible because there is already a queue with the same name.
We worked around it by creating local authentications without bandwidth control.
CCR1036-8G-2S+
~460 active PPPoE connections
10 phantom queues
queue kind: sfq
ghostqueue.png
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 4:44 pm
by Larsa
Just for the record, in case this wasnāt reported to support: The Let's Encrypt DNS-01 challenge has stopped working. Ref:
viewtopic.php?p=1133904
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 6:01 pm
by Kevo
I have upgraded a PPC 1100AHx2 router to 7.18.2 from 7.13 and the login page is messed up. It looks like the 7.13 page except the images are broken and there are tags like %version% and %user% showing instead of the values that usually show up. Is there a way to fix this remotely, i.e. not netinstalling? I can log in and once I get logged in the interface looks fine. I've tried different browsers and emptied cache, and it always shows up broken, so I think it is something that didn't get upgraded properly when 7.18.2 installed. Any ideas?
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 6:22 pm
by dduck313
Just upgrade some rb to 7.18.2 (hap ac2, rb951ui, rb951g, omnitik, hap ac lite, hap lite, rb2011uias), all having the same problem:
after rb reboot, sometimes sstp client not auto connect to the server. But after few hours, it will suddenly connected.
No logs about sstp client trying to connect, and no login attempt in server logs. Revert to 7.16.2 fix the problem.
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 8:02 pm
by wispmikrotik
Hi,
L009 --> IKEv2 with aes256-CTR router reboot with kernel panic
Constantly in a boot loop. All LEDs light up, then reboot. Removing the WAN cable to prevent the IKEv2 peer from establishing itself resolves the issue.
Supout - SUP-182901
---------------------------------> UPDATE <----------------------------------------------
Testing all the settings, it doesn't seem to be AES-256-CTR, but using it together with Auth: sha256
-----> OK
add enc-algorithms=aes-256-ctr lifetime=1h name=pp_pha2_RemoteOffices pfs-group=ecp521
-----> NOK
add enc-algorithms=aes-256-ctr lifetime=1h auth-algorithms=sha256 name=pp_pha2_RemoteOffices pfs-group=ecp521
Failed with: auth-algorithms=sha256
Regards,
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 8:50 pm
by pe1chl
I have upgraded a PPC 1100AHx2 router to 7.18.2 from 7.13 and the login page is messed up. Any ideas?
Look on page 1 of this topic!
Re: v7.18.2 [stable] is released!
Posted: Tue Mar 18, 2025 10:47 pm
by noradtux
Space issue primarily concerns ARM platform.
Interesting.
> /system/resource/print
uptime: 1h29m37s
version: 7.18.2 (stable)
build-time: 2025-03-11 11:59:04
factory-software: 6.45.9
free-memory: 31.5MiB
total-memory: 128.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 896MHz
cpu-load: 1%
free-hdd-space: 148.0KiB
total-hdd-space: 16.0MiB
write-sect-since-reboot: 830
write-sect-total: 11616
architecture-name: arm
board-name: wAP R ac
platform: MikroTik
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 12:11 am
by Kevo
I have upgraded a PPC 1100AHx2 router to 7.18.2 from 7.13 and the login page is messed up. Any ideas?
Look on page 1 of this topic!
Are you referring to the posts about variables being removed from branding? This router has never had any branding applied AFAIK. It has been running regular Mikrotik firmware updated at various times from some version of 5 when it was installed brand new from the box.
I guess I should file a support request and see what they say if this isn't a known issue of some kind.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 12:11 pm
by pe1chl
When you have gone through so many updates, it is better to do a netinstall of 7.18.2.
Do a "/export show-sensitive file=myconfig" first and download the file, you can later import it to restore the config.
(although there usually are some unexpected hickups doing that)
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 10:12 pm
by fouinix
Sorry Mikrotik but I think you are seriously underestimating the problems of 16MB flash devices. This weekend happened to me with my beloved AC2. I purchased this device in 2021 when there was still ROS v6, when v7 arrived at something like 7.5 I simply upgraded without any particular problems. With 7.13 (or 7.12? I don't remember) the Wifi-Wireless packets were split and I still thank you for making the AC2 series with a serious wifi but I encountered memory problems and decided to proceed with Netinstall. Since then I have never had any particular problems with memory considering that it is a home router with default configuration, Capsman, 2-3 custom rules in the firewall and several Wireguard and SSTP VPNs that it manages very well. Once I got to 7.17.2 I waited for 7.18.2 to be released and when I rebooted I found myself with a working router but again with 0 Kb free and without any possibility of doing anything, even a simple reboot was impossible. I accidentally discovered on this forum the command "/console/clear-history" (but why is it not reported in any official document? a list of useful commands for ROS maintenance would not be bad) that initially gave me about 50 Kb but once I rebooted I found myself again with 0 Kb free and no way to free up memory. I had to waste a lot of time to make a backup and proceed with netinstall. It would be much appreciated if Mikortik once and for all explained whether once netinstall has been executed the user can simply restore the backup file without the risk of restoring any residues or it is advisable (which is what I did) to use the .RSC file which however does not import certificates for example. However, netinstall was useful and I find myself with the same configurations with 250-350 Kb free with the router operating, without any configuration I had 380 Kb free. However, I find it a bit negative that by moving from a stable to a stable (7.17. 2 > 7.18. 2) I found myself in these conditions that I could accept with alpha-beta versions but not on stable versions. I believe that we need to find a quick solution for these 16MB flash devices (you have to accept the fact that it was in 2021 and still today a serious mistake of underestimation to introduce such small devices to the market) as reading on the forum it is a growing problem. Either a way is found to reduce the size of ROS, as many propose by dividing the packages or perhaps a way to ensure that netinstall is not necessary to free up space, in the end it is not clear what happens in the flash for which the space is reduced to such an extent that it can no longer be freed up unless formatted. Personally I have understood two things: I will avoid any future purchase of Mikrotik devices that do not have at least 128 MB of flash (I will never understand, in 2013 the entire 951 home series had 128 MB of RAM, what logic in reducing it 10 years later?!) and go very easy with future ROS updates at least on 16 MB devices, but I wonder if before the release of a stable version they really do some tests or not... Oh little tip: the new features related to USB disks are very nice but please put those "Disk" settings in order because it's total chaos like this!
+10000
I am really afraid this will brick
many routers.
I am stuck with my Hap ac2, unable to perform netinstall....
I tried with :
ip addr show enp5s0
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 6c:24:08:0d:7f:16 brd ff:ff:ff:ff:ff:ff
altname enx6c24080d7f16
inet 192.168.88.2/32 scope global noprefixroute enp5s0
valid_lft forever preferred_lft forever
inet6 fe80::d8c5:3d72:c264:879/64 scope link noprefixroute
valid_lft forever preferred_lft forever
And two way with netinstall :
sudo ./netinstall-cli -v -i enp5s0 routeros-7.18.2-arm.npk
Version: 7.18.2(2025-03-11 13:07:03)
Waiting for Link-UP on enp5s0
Using client IP 192.168.88.3
Could not match client IP 192.168.88.3 to interface enp5s0
sudo ./netinstall-cli -v -a 192.168.88.2 routeros-7.18.2-arm.npk
Version: 7.18.2(2025-03-11 13:07:03)
Using interface enp5s0
Using interface enp5s0
Waiting for Link-UP on enp5s0
Server IP and client IP cannot be the same
Both way do not work....
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 10:23 pm
by itimo01
And two way with netinstall :
sudo ./netinstall-cli -v -i enp5s0 routeros-7.18.2-arm.npk
Version: 7.18.2(2025-03-11 13:07:03)
Waiting for Link-UP on enp5s0
Using client IP 192.168.88.3
Could not match client IP 192.168.88.3 to interface enp5s0
sudo ./netinstall-cli -v -a 192.168.88.2 routeros-7.18.2-arm.npk
Version: 7.18.2(2025-03-11 13:07:03)
Using interface enp5s0
Using interface enp5s0
Waiting for Link-UP on enp5s0
Server IP and client IP cannot be the same
Both way do not work....
Did you even read the manual of netinstall-cli? It doesn't seem like you did.
https://help.mikrotik.com/docs/spaces/R ... nsforLinux
1. You're using a /32 subnet
2. netinstall-cli doesnt have -v
3. -a defines the CLIENT IP
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 10:53 pm
by fouinix
1. I am not using a /32 subnet, but a /24
3. netinstall-cli have a -v option for verbose :
/netinstall-cli
Version: 7.18.2(2025-03-11 13:07:03)
No packages supplied
./netinstall-cli [-r] [-e] [-b] [-o] [-k <keyfile>] [-s <userscript>] {-i <interface> | -a <client-ip>} [PACKAGE]+
-r apply default configuration
-e apply empty configuration
-r and -e are mutually exclusive
by default existing configuration will be kept
-b remove branding
-o install devices only once
-v verbose mode
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 10:59 pm
by erlinden
1. I am not using a /32 subnet, but a /24
Are you sure?
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 11:18 pm
by spippan
netinstall HAS a -v flag on linux
and the problem here is wrong subnetting (/32)
set your interface ip subnet mask at least to /30
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 11:34 pm
by fouinix
I am sure I used a /24. It is weird, I had to disable NetworkManager service and perform many tests to be able to netinstall. I was not easy at all :(
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 19, 2025 11:49 pm
by itimo01
netinstall HAS a -v flag on linux
Then the docs page seems to be wrong.
My fault for not checking again on system :D
I am sure I used a /24. It is weird, I had to disable NetworkManager service and perform many tests to be able to netinstall. I was not easy at all :(
I see no use in disabling NetworkManager for netinstalling?
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 20, 2025 12:12 am
by patrikg
You have to disable NetworkManager service, and set the interface to static ip.
Maybe you can use NetworkManager if you set the Ethernet interface to static ip and disable all another interfaces like wifi.
And if you use NetworkManager you have another problem with the interface bringing up then the link being up, and then the NetworkManager sets the interface ip.
The best option in netinstall-cli is -i, so you can define the interface name.
You don't need to provide any ip, netinstall-cli will just add +1 from your pc ip to the device.
And the -a options defines the device ip:
Netinstall
If you dislike the ethernet interfaces names in Linux you can provide a command line to the kernel
and it goes back to it's original name 'eth0' 'eth1'
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 20, 2025 10:38 am
by eworm
Thanks to namespaces the
netinstall can be made bullet-proof on
Linux. I use this scripts as a wrapper:
https://aur.archlinux.org/cgit/aur.git/ ... netinstall
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 20, 2025 10:53 am
by fouinix
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 20, 2025 4:45 pm
by noradtux
Wait, that's not standard? I've ever only used the package from AUR, not the manual thing from Mikrotik download ĀÆ\_(ć)_/ĀÆ.
Re: Problems: Re: v7.18.1 [stable] is released!
Posted: Tue Mar 25, 2025 1:10 am
by chechito
Hi,
I have "funny Problem" with cAPGi-5HaxD2HaxD and the 7.18.1 and the latest 7.17.2 Version, Only the 7.18 Version works flawlessly:
Some Android devices (mainly with Mediatek AC or AX Chipset, but also some Linux machines with Intel 210 AX Wifi Nics) have tthe Problem that they
don't see the SSID of the 5 GHz Band, when 7.18.1 or 7.17.2 Version.
After rescanning several time, sometimes they are able to "see" it but still unable to connect, because they say in the logs the SSID disappears.....
ONLY the 7.18 Work fine regarding this issue - don't know why.
First I thoght it is a simpley "country setting" issu, but no, it has nothing to do with dhe channel or country selection, even I I use only the Channel 36-42 the issue is absolutely the same .
I am a bit disappointed that the issure re-occured with the last Update 7.18.1 though.....
The Other Problem which exists with ALL Versions so far, my Linux machine with Intel 210AX does only connect on 5 GHz in 300N Mode, not AC and not AX.... but Just for the record, I didn't examine that problem too deep yet...
Cheers
4920441
Intel AX210 has some quite limited frequency range on 5ghz.
Got my own experience with that and BE200.
Try changing it to something like 5500mhz.
Up to channel 128 works fine tho
previously i had hap ac2 without any problem (wifi-qcom-ac package) some days ago i have access to a hap ax2, i migrated keeping the same config (only bridge)
i only have 2 devices connected to 5ghz radio, both with windows 10, one with intel ac9260 wNIC the other with intel ax210 wNIC
since i have hap ax2 ax210 client have frequent disconnects, the 9260ac client also losses packets at the same time but just dont disconnect
i put a MK audience to make a wireless capture at problem moment and looks like hap ax2 radio just go to take a nap for some seconds, no beacons no nothing when the problem arises, capture shows clients retrying but without ap response
somebody with similar problem?
i started with 7.16.2 which hap ac2 had and worked flawlessly hap ax2 have the problem with 7.16.2, upgraded the hap ax2 to 7.18.2 but the problem stays
Problems is recurrent, happens at least 3 times per day
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 26, 2025 7:40 pm
by dokacoimbra
Hello,
When I format my pendrive in fat32, the last modification date of usb1 is Feb/07/2106.
If I format it in ext4, the modification date is correct as Mar/26/2025.
Does anyone know why?
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 26, 2025 7:45 pm
by grusu
Fat16 is from the future.
Re: v7.18.2 [stable] is released!
Posted: Wed Mar 26, 2025 9:54 pm
by sirbryan
Can a few people test built-in SMB performance? On two of my devices, SMB to macOS is really bad (11-20MB/s), but on 7.16.2 and 7.17.2 it's fine (200-900MB/s).
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 1:43 am
by h4xor1701
I just wanted to report a bug with latest 7.18.2 version
Using PIM as routing protocol, the default route is not correctly announced even with originate default: always
I have tested this behaviour with:
- CCR2004 and pfSense + FRR router
- CCR2004 and RB5009 (both on 7.18.2)
Testing on GNS3 the 7.15 seems like it was not affected by the bug
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 3:14 am
by itimo01
Can a few people test built-in SMB performance? On two of my devices, SMB to macOS is really bad (11-20MB/s), but on 7.16.2 and 7.17.2 it's fine (200-900MB/s).
Connecting an old 2008 Mac Pro with 15.3.2 installed to an AX3 SMB Server i get the following results
The Mac Pro is really struggling with the OS though and some features appear to be broken.
So i ran blackmagic disk speed test
Testing on 7.18.2:
Screenshot 2025-03-27 020033.png
On 7.19beta6 it got around the same results.
Windows to 7.19beta6 is like this:
Which is around the same numbers i got with 7.18.2
Screenshot 2025-03-27 021258.png
Both were connected to the AX3 with a 1G link
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 10:33 am
by merkkg
So it works as expected and is maxing out your 1Gbps link as the CrystalDiskMark is represented in MB/s vs Mbps which is a good thing
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 10:34 am
by mkx
So it works as expected and is maxing out your 1Gbps link as the CrystalDiskMark is represented in MB/s vs Mbps which is a good thing
... and it's a black magic (pun intended) as to why it only works at half speed when SMB client is MAC device. Personally I wouldn't consider 50MB/s (give or take) "a struggle" ... but there might be other problems (as hinted but not elaborated by @itimo01) when using a MAC.
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 10:45 am
by rpingar
7.18ab244pppoe seems much better on arm64, we don't have yet tested on x86
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 11:04 am
by grusu
7.18ab244pppoe
From where?
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 11:31 am
by rextended
missing space, is "7.18ab244"
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 1:43 pm
by rpingar
7.18ab244pppoe
From where?
ask mikrotik
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 3:04 pm
by itimo01
So it works as expected and is maxing out your 1Gbps link as the CrystalDiskMark is represented in MB/s vs Mbps which is a good thing
... and it's a black magic (pun intended) as to why it only works at half speed when SMB client is MAC device. Personally I wouldn't consider 50MB/s (give or take) "a struggle" ... but there might be other problems (as hinted but not elaborated by @itimo01) when using a MAC.
I was 100% sure that it was the mac cpu being the limiting factor ( i mean its almost 20 years old) BUT:
I just ran the test against my server and there I hit full link speed.
Untitled.png
EDIT: I also reran the test to the ROS SMB and its still the same result
Re: v7.18.2 [stable] is released!
Posted: Thu Mar 27, 2025 7:27 pm
by pe1chl
When doing a demo for my co-workers today, I noticed that you can use the "DHCP setup" wizard only once.
It creates the same name for the IP pool every time, so the second time you use it, it errors out with "pool already exists".
(I tried using it to create a new DHCP instance for a new VLAN that I had just created)
It would be better to include the interface name in the pool name, also for self-documenting the setup.
Re: Problems: Re: v7.18.1 [stable] is released!
Posted: Fri Mar 28, 2025 8:29 pm
by jimmyz
Intel AX210 has some quite limited frequency range on 5ghz.
Got my own experience with that and BE200.
Try changing it to something like 5500mhz.
Up to channel 128 works fine tho
previously i had hap ac2 without any problem (wifi-qcom-ac package) some days ago i have access to a hap ax2, i migrated keeping the same config (only bridge)
i only have 2 devices connected to 5ghz radio, both with windows 10, one with intel ac9260 wNIC the other with intel ax210 wNIC
since i have hap ax2 ax210 client have frequent disconnects, the 9260ac client also losses packets at the same time but just dont disconnect
i put a MK audience to make a wireless capture at problem moment and looks like hap ax2 radio just go to take a nap for some seconds, no beacons no nothing when the problem arises, capture shows clients retrying but without ap response
somebody with similar problem?
i started with 7.16.2 which hap ac2 had and worked flawlessly hap ax2 have the problem with 7.16.2, upgraded the hap ax2 to 7.18.2 but the problem stays
Problems is recurrent, happens at least 3 times per day
Hello,
I'm on the same boat here.
/system/resource/print
uptime: 1w6d9h3m49s
version: 7.18.2 (stable)
build-time: 2025-03-11 11:59:04
factory-software: 7.5
free-memory: 636.7MiB
total-memory: 1024.0MiB
cpu: ARM64
cpu-count: 4
cpu-frequency: 864MHz
cpu-load: 3%
free-hdd-space: 87.7MiB
total-hdd-space: 128.0MiB
write-sect-since-reboot: 331737
write-sect-total: 7227970
bad-blocks: 0%
architecture-name: arm64
board-name: hAP ax^2
platform: MikroTik
This is just my home router, mostly it carries on it's wifi, 3-4 android cell phones and 1-2 laptops, one with windows and one with kubuntu 24.04
The wireless crash happens mostly (not always) when my son's POCO-M4-Pro with andoid 13 is present.
system/package/print
Columns: NAME, VERSION, BUILD-TIME, SIZE
# NAME VERSION BUILD-TIME SIZE
0 user-manager 7.18.2 2025-03-11 11:59:04 332.1KiB
1 wifi-qcom 7.18.2 2025-03-11 11:59:04 10.2MiB
2 rose-storage 7.18.2 2025-03-11 11:59:04 3136.1KiB
3 routeros 7.18.2 2025-03-11 11:59:04 12.3MiB
4 zerotier 7.18.2 2025-03-11 11:59:04 836.1KiB
5 container 7.18.2 2025-03-11 11:59:04 100.1KiB
2,4GHz interface is disabled, only 5GHz is active. The channel is clear, my only neighbor is transmitting on 36, me on 100 (5500/ax/Ceee/D).
/interface/wifi/ex
# 2025-03-28 20:06:50 by RouterOS 7.18.2
# model = C52iG-5HaxD2HaxD
/interface wifi security
add authentication-types=wpa2-psk disabled=no group-encryption=ccmp group-key-update=20m name=sec1 wps=\
disable
/interface wifi
set [ find default-name=wifi1 ] channel.frequency=5500 .secondary-frequency=disabled .skip-dfs-channels=\
disabled configuration.country=Greece .manager=local .mode=ap .ssid=FFast datapath.bridge=bridge1 \
.client-isolation=no disabled=no security.authentication-types=wpa2-psk,wpa3-psk .ft=yes .ft-over-ds=\
yes
# no connection to CAPsMAN, managed locally
set [ find default-name=wifi2 ] configuration=cfg1 configuration.manager=capsman-or-local .mode=ap
/interface wifi cap
set caps-man-addresses=127.0.0.1 certificate=request discovery-interfaces=bridge1
/interface wifi capsman
set ca-certificate=auto enabled=yes package-path="" require-peer-certificate=no upgrade-policy=none
/interface wifi configuration
add channel.width=20mhz country=Greece datapath=datapath1 disabled=yes mode=ap name=cfg1 security=sec1 \
security.ft=yes .ft-over-ds=yes ssid=Capsman
/interface wifi datapath
add bridge=bridge1 client-isolation=no disabled=no name=datapath1
/interface wifi provisioning
add action=create-dynamic-enabled disabled=no master-configuration=cfg1
clients:
interface/wifi/registration-table/pr
Flags: A - AUTHORIZED
Columns: INTERFACE, SSID, MAC-ADDRESS, UPTIME, LAST-ACTIVITY, SIGNAL, AUTH-TYPE, BAND
# INTERFACE SSID MAC-ADDRESS UPTIME LAST-ACTIVITY SIGNAL AUTH-TYPE BAND
0 A wifi1 FFast 12:2D:49:xx:xx:xx 8h12m6s 54s10ms -55 wpa3-psk 5ghz-ac
1 A wifi1 FFast F6:7E:F3:xx:xx:xx 5h36m43s 9s -71 wpa3-psk 5ghz-ac
2 A wifi1 FFast AA:8F:89:xx:xx:xx 4h1m36s 0ms -61 wpa3-psk 5ghz-ac
3 A wifi1 FFast D0:9C:7A:xx:xx:xx 2h15m19s 3s -81 wpa3-psk 5ghz-ac
4 A wifi1 FFast 9C:30:5B:xx:xx:xx 29m31s 0ms -61 ft-wpa3-psk 5ghz-ac
5 A wifi1 FFast 14:5F:94:xx:xx:xx 29m19s 3s -60 wpa2-psk 5ghz-ac
Well, you can see that my clients are all AC.
Furthermore, like chechito, "previously i had hap ac2 without any problem".
Any advice is welcome! I could have messed up things myself, veeery easily!!!
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 28, 2025 8:53 pm
by itimo01
btw this config is wrong:
set [ find default-name=wifi2 ] configuration=cfg1 configuration.manager=capsman-or-local .mode=ap
/interface wifi cap
set caps-man-addresses=127.0.0.1 certificate=request discovery-interfaces=bridge1
If you want to use the local interfaces in capsman you set them to "local" and switch to the radio tab and hit "provision".
I'm using capsman (with local interfaces) + NO ft-over-ds and never had any issues.
There was the thought going around on some topics if this might only happen on "non-capsman" devices. Not sure if someone ever tried this.
So if you want to try you can provision your radio with capsman ig.
Re: v7.18.2 [stable] is released!
Posted: Fri Mar 28, 2025 11:23 pm
by JJT211
When doing a demo for my co-workers today, I noticed that you can use the "DHCP setup" wizard only once.
It creates the same name for the IP pool every time, so the second time you use it, it errors out with "pool already exists".
(I tried using it to create a new DHCP instance for a new VLAN that I had just created)
It would be better to include the interface name in the pool name, also for self-documenting the setup.
Yea, ive ran into this...but only if you're using the exact same IP pool (10.1.1.100 - 10.1.1.199). When I notice that, ill just add another IP (10.1.1.99 - 10.1.1.199) and it will create it just fine.
But it would be nice if it ROS recognized you're trying that the same pool isnt currently being used on any other DHCP interfaces and reuses it.
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 29, 2025 11:21 am
by pe1chl
In my case I added a new VLAN, assigned it a new /24 address (not overlapping), and used the setup wizard selecting the new VLAN.
It recognized the new address, proposed a new range in that new /24, which I accepted (Next) but in the final step it complained about the pool name already being in use.
At that point the router already had the default DHCP config on 192.168.88.1/24 and a newly added 192.168.89.1/24 which I configured using the wizard, and it failed when adding an extra 192.168.90.1/24 network.
What I expected is to get 3 pools with 3 different names. My suggestion is to include the interface name in the pool name, to make them unique.
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 29, 2025 2:09 pm
by Santi70
I have tried to add a new slave wifi interface (wiff66) of wifi1 on a hAPax3, wifi1 is in a bridge, when adding it (which it does correctly) it automatically adds wifi66 as a port to the bridge, but when I want to delete it from the bridge it doesn't let me because it says it can't delete a dynamic interface, if I make a copy of it to modify the PVID it doesn't let me because it says it already exists. However, I already have another virtual interface working with the PVID changed in the bridge, apparently something changed.
I did the same tests on a hAPac2 with the same version 7.18.2 and when adding the virtual interface it does NOT add it as a port to the bridge automatically.
Captura de pantalla 2025-03-29 124520.png
Re: v7.18.2 [stable] is released!
Posted: Sat Mar 29, 2025 2:15 pm
by itimo01
I did the same tests on a hAPac2 with the same version 7.18.2 and when adding the virtual interface it does NOT add it as a port to the bridge automatically.
You're comparing different devices which use different drivers.
1. Step is reading the manual:
https://help.mikrotik.com/docs/spaces/R ... ionexample:
There you will find that wifi-qcom-ac DOESNT support dynamic VLAN tags. While wifi-qcom DOES support them. "wireless" is a whole different story.
So the correct way to use VLANs on wifi-qcom is with the datapath setting while on the wifi-qcom-ac its via adding them manually.
Re: v7.18.2 [stable] is released!
Posted: Sun Mar 30, 2025 12:51 am
by Santi70
Thank you, I already know what the error was, the datapath is what was adding it to me dynamically.
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 31, 2025 12:27 pm
by jimmyz
btw this config is wrong:
set [ find default-name=wifi2 ] configuration=cfg1 configuration.manager=capsman-or-local .mode=ap
/interface wifi cap
set caps-man-addresses=127.0.0.1 certificate=request discovery-interfaces=bridge1
If you want to use the local interfaces in capsman you set them to "local" and switch to the radio tab and hit "provision".
I'm using capsman (with local interfaces) + NO ft-over-ds and never had any issues.
There was the thought going around on some topics if this might only happen on "non-capsman" devices. Not sure if someone ever tried this.
So if you want to try you can provision your radio with capsman ig.
I appreciate your thought and contribution. Tried this, if I interpret correctly
/interface wifi
set [ find default-name=wifi2 ] configuration.mode=ap
/interface wifi datapath
add bridge=bridge1 client-isolation=no disabled=no name=datapath1
/interface wifi security
add authentication-types=wpa2-psk,wpa3-psk disabled=no group-encryption=ccmp group-key-update=20m name=sec1 wps=disable
/interface wifi configuration
add channel.frequency=5500 country=Greece datapath=datapath1 disabled=no mode=ap name=cfg1 security=sec1 security.ft=yes ssid=FFast
/interface wifi cap
set caps-man-addresses=127.0.0.1 certificate=request discovery-interfaces=bridge1
/interface wifi capsman
set ca-certificate=auto enabled=yes package-path="" require-peer-certificate=no upgrade-policy=none
/interface wifi provisioning
add action=create-dynamic-enabled disabled=no master-configuration=cfg1
it still intermitts the connection under no certain case. 2-3 times a day.
The only log is
2025-03-31 12:12:58 wireless,info 9C:30:5B:xx:xx:xx@wifi1 disconnected, connection lost, signal strength -60
2025-03-31 12:13:09 wireless,info 9C:30:5B:xx:xx:xx@wifi1 connected, signal strength -71
There is no known interference and I'm sitting 4 meters away from the device.
Next thing to do is to swap the hAP with another one, well, when time permitts
Re: v7.18.2 [stable] is released!
Posted: Mon Mar 31, 2025 6:48 pm
by pe1chl
I noticed that it is possible to add multiple routing tables with the same name:
/routing table
add disabled=no fib name=test
add disabled=no fib name=test
This is accepted without error message and then there are two tables with name test, and it is unclear which one is used.
SUP-184107 created.
Re: v7.18 [stable] is released!
Posted: Tue Apr 01, 2025 12:14 am
by JJT211
I just realized I forgot to give a heads-up in this thread too, like I did in "v7.18rc [testing]":
Heads-up - breaking changes for management and monitoring:
*) console - put !empty sentence when API query returns nothing;
Thanks for the heads up!
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 01, 2025 1:03 pm
by nmt1900
I noticed that it is possible to add multiple routing tables with the same name:
/routing table
add disabled=no fib name=test
add disabled=no fib name=test
This is accepted without error message and then there are two tables with name test, and it is unclear which one is used.
SUP-184107 created.
Same applies to other objects as well - partitions can have same name as well to create more confusion. Partitions can be renamed from command line though...
Re: v7.18 [stable] is released!
Posted: Tue Apr 01, 2025 1:20 pm
by netwpl
Is VRRP having any issues with this release. Thatās the only thing stopping me from moving up my main core network.
Read something about connection syncing
definitely. ive upgraded a CCR 1072 vrrp-stack to 7.18.2, afterwards the vrrp instances have been disabled with weird errors. due to no time for debugging, after downgrade to 7.16.2 everything was fine.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 01, 2025 2:02 pm
by Larsa
Mikrotikās known VRRPās been broken for a few releases now, but why itās still not fixed is anyoneās guess. Still there in v7.19, apparently.
Pretty remarkable that a mission-critical HA (high availability) feature isnāt fixed right away, if you ask me.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 01, 2025 4:15 pm
by Mimiko
First router on 7.16.2 firmware and second router on 7.18.2 firmware. VRRP works as expected, connection tracking and preemption mode. the 7.16.2 has 254 priority and preemption mode enabled, while 7.18.2 has 100 priority and disabled preemption mode. Restarting any of them works correctly to became master-slave. The only drawback the 7.18.2 router shows 'Connection tracking innactive' for VRRP instance, but the connection tracking is working.
Then I upgrade the first router to 7.18.2. No config is changed on both routers. VRRP brokes. Both routers have VRRP as master. Its like they do not see each other. But nothing changed in config in firewall. Only a firmware update was made.
I see this as a major bug in 7.18 versions of routeros. 7.16 works as expected, 7.18 breaks VRRP.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 01, 2025 5:18 pm
by noradtux
I have multiple VRRP (legacy IP and v6) running on CCR2216 with ROS 7.18.2 without issues. Maybe config related?
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 01, 2025 5:20 pm
by pe1chl
Same applies to other objects as well - partitions can have same name as well to create more confusion. Partitions can be renamed from command line though...
Well, at least partitions also have a number that is visible to the user.
The routing table number (which of course exists in Linux) is completely hidden from the user.
So after creating two tables with the same name, it is completely unclear which one is actually used.
Fortunately it turns out it is possible to rename one of them and then see in the references (e.g. routing rule, mark route) what is changing...
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 01, 2025 8:34 pm
by nmt1900
Be it routing table names or partition names - all points towards the need of better configuration integrity checks. We might not be able to get full reference level checks but object name level checks should be one of most basic things there is...
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 9:34 am
by Mimiko
I have multiple VRRP (legacy IP and v6) running on CCR2216 with ROS 7.18.2 without issues. Maybe config related?
If this were be the config related, then it should be mentioned the difference of configuration with pre 7.17 firmware.
Can you post your config which does work?
Beware, that vrrp configuration is working on firmware 7.16.2 and as soon the router is updated, the vrrp does not work (the election of master-backup does not work)
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 9:37 am
by Network5
The only drawback the 7.18.2 router shows 'Connection tracking innactive' for VRRP instance, but the connection tracking is working.
I think that is just a non-updated state. If you change the interface's name, it disappears.
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 11:40 am
by pe1chl
Be it routing table names or partition names - all points towards the need of better configuration integrity checks. We might not be able to get full reference level checks but object name level checks should be one of most basic things there is...
Actually in most places it just works fine. You get the "already have such item" error and the add is refused.
It seems that in some places this check is forgotten.
After all these years I never tried to dissect how the configuration layer in RouterOS actually works, but I would expect (if only for size reduction) that it is completely table-driven and uses as little specific code for each action as possible.
I.e. tables exist that hold all commands and possible parameters, and the functions to call to handle operations on them. That would also include checking functions to call before an add or set (does the item exist), so the command interpreter already knows that something is wrong.
(similar to how objects are handled in an object-oriented programming language)
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 4:05 pm
by AlexandruL
I'm using wifi-qcom-ac on cAP with Wifi Capsman Controller on a hEX, and the most used cAPs go into an unrecoverable state without power cycle, even though they are rebooted daily at 03:00. On the switches I only see port flaps that go away as soon as the AP is power cycled. On RouterOS 7.18.1 did not seem to have this issue as long as the APs were rebooted once every 24h.
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 4:33 pm
by infabo
@AlexandruL Maybe you also experience this?
viewtopic.php?p=1134698
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 5:09 pm
by AlexandruL
@Infabo I know that topic, could be a misconfiguration or a bug, I experienced something somewhat "similar". Whenever I have cAPs conected to a MSTP regional root and there is some port flapping on ports different than the cAPs, the cAPs lose connection a few times a day, I'm using CRS354-48G-4S+2Q+ switches. I fixed that by moving the regional root bridge to another switch.
It could be that the bridge on the cAPs is not hardware offloaded and on the CRS is hardware offloaded and that may be an issue.
This issue is different, I believe the driver hangs the cAP in such a way that it never recovers by itself. Only a few cAPs are having this issue and they have a lot of clients connected to them 15-20, less used cAPs only hang if they have long uptimes (a few days). As I mentioned, the cAPs have a reboot task every day at 03:00 in order to avoid it.
I've also checked the wires and connections that connect the cAPs and everything seems to be in order, the other port flaps were caused by bad wires/wall ethernet sockets and were fixed.
I've checked multiple times the MSTP configuration and it's correct, with correct priorities, region and revision.
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 02, 2025 10:19 pm
by AlexandruL
@Infabo About an hour after my last post, 2 cAPs went into a non-operational state, after about 2, maybe 3 hours they rebooted by themselves and are now accessible again. I'm curious if I enable ping watchdog, if that reboots the cAPs faster.
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 03, 2025 8:59 am
by mkx
I'm curious if I enable ping watchdog, if that reboots the cAPs faster.
My experience is that ping watchdog reboots device real fast ... when pings start to fail. Beware that it'll trip also when "reference" device becomes unavailable for some reason. The question remains whether pings will fail when cAPs become "non-operational" though.
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 03, 2025 10:45 am
by AlexandruL
I'm curious if I enable ping watchdog, if that reboots the cAPs faster.
My experience is that ping watchdog reboots device real fast ... when pings start to fail. Beware that it'll trip also when "reference" device becomes unavailable for some reason. The question remains whether pings will fail when cAPs become "non-operational" though.
I've got another cAP that went into a non-operational state but it recovered by itself in about 30 minutes. On the CRS switch I see the ethernet port alocated for the cAP flapping continuously until the device recovered.
Regarding ping watchdog, I've set the timeout for 5 minutes for now and maybe I'll tighten it to 3 minutes. At the time of the issue, the device had an uptime of about 6 hours but little activity until 08:00 - 09:00.
In the logs I got the following messages:
system,error,critical router was rebooted without proper shutdown, probably kernel failure
system,error,critical kernel failure in previous boot
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 03, 2025 3:24 pm
by AlexandruL
@mkx, I can confirm that adding the ping watchdog with a timeout of 3 minutes does recover the cAP way faster, the device is back in business in about 4 minutes after becoming non responsive.
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 03, 2025 8:43 pm
by AlexandruL
@Infabo, check this out:
viewtopic.php?t=214819
The difference in my case is that all cAP were factory reset and some of them were even netinstalled, after that, the default config was modified to fit my needs but still following Mikrotik recommendations for wifi-qcom-ac devices.
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 03, 2025 9:06 pm
by infabo
My devices never rebooted or kernel paniced. A sole RSTP/bridge issue. I always resolved it by toggling ethernet interface to get port to forward again. Now my devices run 7.15.3 and the issue never appeared again. One could think it is something from 7.18 causing it........
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 03, 2025 11:09 pm
by irghost
I have noticed that after upgrading to RouterOS v7.18, the method of VRF route leaking using vrfname@vrfname no longer works.
Previous Working Method (Before v7.18)
In earlier versions, I could create a route leak between two VRFs by simply adding a route with the gateway in the format:
/ip/route/add dst-address=192.168.100.0/24 gateway=vrf-A@vrf-A
This allowed traffic from vrf-B to reach destinations in vrf-A seamlessly.
Issue in v7.18 and Later
After updating to v7.18, this method no longer functions. Routes are not installed, and the system does not recognize the vrfname@vrfname syntax as a valid gateway.
Questions:
Has this functionality been intentionally removed? If so, what is the recommended alternative?
Should we now rely entirely on import-target and export-target for VRF route leaking?
Is there an official changelog entry mentioning the deprecation of vrfname@vrfname?
I would appreciate clarification on this change and guidance on the best method for VRF route leaking in v7.18+.
Thank you for your time!
Re: v7.18.2 [stable] is released!
Posted: Fri Apr 04, 2025 10:10 am
by AlexandruL
My devices never rebooted or kernel paniced. A sole RSTP/bridge issue. I always resolved it by toggling ethernet interface to get port to forward again. Now my devices run 7.15.3 and the issue never appeared again. One could think it is something from 7.18 causing it........
Have you changed the bridge priority? I would set 0 for the root bridge and F000 for the AP.
Re: v7.18.2 [stable] is released!
Posted: Fri Apr 04, 2025 10:52 am
by infabo
My root bridge has "priority=0x7000". But regardless of this setting: it worked < 7.18. The weird thing on my problem is, that the bridge with constantly switching port-state between forwarding/learning is/was not even running 7.18 (in fact: 7.17.x). All was fine, as long all my devices had ROS < 7.18. As soon as a single 7.18.x device (with enabled RSTP protocol) joins the network the trouble begins - after some hours.
Re: v7.18.2 [stable] is released!
Posted: Fri Apr 04, 2025 6:42 pm
by nmt1900
What is "port cost mode" setting set to in bridge STP settings? Newer releases default to long while older releases defaulted to short - and upgraded devices with old config retained setting at short. This option appeared on 7.15 if my memory serves me right.
Issue with this is that all network devices in network must have same setting.
Re: v7.18.2 [stable] is released!
Posted: Fri Apr 04, 2025 9:25 pm
by pe1chl
Yes. All advanced STP-aware equipment has this. That is not too difficult to Google, isn't it?
Re: v7.18.2 [stable] is released!
Posted: Sun Apr 06, 2025 11:04 pm
by LordNikkon
Hello all,
I have two L009 routers in my network. Till some time back they was working very well with software 7.16.2
Recently i upgraded them to 7.17.2 (and later to 7.18.2) and then start problems. Routers rebooting in random moments. In logs i can see such information: "Router was rebooted without proper shutdown, probably kernel failure" and in next line "kernel failure in previous boot".
I didn't change anything in configuration (i have 2 IPSec tunnels and in OVPN). I was thinking that maybe ROS 7.17 is crappy so i upgraded to 7.18.2. Same story.
Same problem happen on both L009 (diffrent locations). Other routers (RB4011, RB5009, RB760, RB3011) don't have any problems with software (ok maybe beside HexS and not so lucky 7.18) - only L009. I could say that one router is broken but both of them? Don't think so. I also noticed that after changing from 7.16.2 to higher versions CPU utilization rised about 10%.
What should i do? For me something was introudeced in ROS7.17 and it'causing problems. Any hints? L009 is quiet new but something is wrong with this paticular HW.
Re: v7.18.2 [stable] is released!
Posted: Mon Apr 07, 2025 5:26 am
by junbr0
hmmmmmphh... on smips arch winbox access ( ex open new window terminal ) getting high cpu usage up to 80%
Re: v7.18.2 [stable] is released!
Posted: Mon Apr 07, 2025 11:40 am
by LordNikkon
Just in case i downgraded both L009 to 7.16.2 nad they working without issues (already for 12 hours) since then.
Now i'm sure for 99,9% that something was introduce in 7.17 ROS, cause problems and this bug is repated in all software which come after 7.17. I tested 7.17, 7.17.2, 7.18 and 7.18.2
Re: v7.18.2 [stable] is released!
Posted: Mon Apr 07, 2025 11:48 am
by pe1chl
Your issues are caused by the use of some advanced encryption method that has a bug in the kernel implementation.
It has been discussed in release topics before and will probably be fixed in the next release.
Re: v7.18.2 [stable] is released!
Posted: Mon Apr 07, 2025 2:52 pm
by LordNikkon
Your issues are caused by the use of some advanced encryption method that has a bug in the kernel implementation.
It has been discussed in release topics before and will probably be fixed in the next release.
I hope. Problem seems to be strongly realted with CPU build in L009 - IPQ-5018. All other ARM/ARM64 routers works great - RB4011, RB5009, RB3011. This week i will replace L009 for E50UG. It has diffrent CPU (EN7562CT) so it is high chance that bug will not affect new device.
Do you have link to related topic - i will read it to understand what happend.
Re: v7.18.2 [stable] is released!
Posted: Mon Apr 07, 2025 3:13 pm
by spippan
I have multiple VRRP (legacy IP and v6) running on CCR2216 with ROS 7.18.2 without issues. Maybe config related?
how did you configure conn-sync?
could you provide your config. of those 2216s please?
i have 2x2 CCR2004 on 7.14.3 where i depend on a working VRRP setup, so if this works for you, it might do so for my setups.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 08, 2025 3:24 pm
by ivicask
I just upgraded first time fresh unpacked Cube 60Pro ac(set of 2), no settings touched, after updating i see warning under Routerboard that "Cpu not running at default frequency" and its set to 716mhz.
But when i try to change it to Auto or any other freq(for test) it tells me Couldn't change Settings - not allowed by device-mode(6).
Is this normal behavior or bug?
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 08, 2025 3:50 pm
by mkx
Is this normal behavior or bug?
Good morning.
Yes, since 7.17 one has to allow routerboard uder /system/device-mode to be able to change anything under /system/routerboard ... which includes CPU frequency.
Before you join the choir: there were lenghty and loud complaints about extensive use of device-mode ... MT listened a tiny bit, but we'll all have to adapt to new reality.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 08, 2025 4:22 pm
by ivicask
Is this normal behavior or bug?
Good morning.
Yes, since 7.17 one has to allow routerboard uder /system/device-mode to be able to change anything under /system/routerboard ... which includes CPU frequency.
Before you join the choir: there were lenghty and loud complaints about extensive use of device-mode ... MT listened a tiny bit, but we'll all have to adapt to new reality.
You missed the point, there was no warnings before upgrade or i ever touched CPU freq on this fresh unpacked device , its the upgrade which changed freq or whatever it did and now complains about "it self"
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 08, 2025 5:19 pm
by Paternot
You missed the point, there was no warnings before upgrade or i ever touched CPU freq on this fresh unpacked device , its the upgrade which changed freq or whatever it did and now complains about "it self"
The upgrade didnĀ“t change frequency. It changed You ability to change frequency between "auto" or "$VALUE" without manual intervention. If it was "auto" before the upgrade, it will still be on "auto" after, and the up/down auto scaling will still happens. If it was set on a given fixed frequency, it will still be on that one.
The difference is that NOW You need physical access in order to change the setting. And there is one place "/system/device-mode/" where You can change this behavior - again, physical access is needed to make the change.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 08, 2025 6:49 pm
by mkx
You missed the point, there was no warnings before upgrade or i ever touched CPU freq on this fresh unpacked device , its the upgrade which changed freq or whatever it did and now complains about "it self"
The upgrade didnĀ“t change frequency.
I can't say about this particular device, but default CPU frequency can change between ROS versions. I think it was around 6.45 when "auto" was introduced (first on a few device models) and made default on several device models a few releases later ... and it displayed same (nasty) warning after that.
Yes, you're right, upgrade did not change frequency, but since default might have changed, it now displays the warning.
Re: v7.18.2 [stable] is released!
Posted: Tue Apr 08, 2025 11:51 pm
by Maggiore81
Out of memory condition. CCR1036 just updated at 7.18.2 from 7.18.1
I have opened support ticket with mikrotik.
Plain 1036 with dhcp + nat and fasttrack and 5 pppoe users.
Re: v7.18.2 [stable] is released!
Posted: Wed Apr 09, 2025 4:15 am
by loloski
Out of memory condition. CCR1036 just updated at 7.18.2 from 7.18.1
I can concur this sucks for just 2 days uptime after the upgrade the memory it consume is insane, normally the consumption is under 1g, we don't have any use case anymore with
mikrotik except for BRAS mikrotik please fix this don't push your product to get out of the door completely, I will going to continue monitor this otherwise will revert back to 7.12
1.jpg
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 10, 2025 3:43 pm
by Maggiore81
I have replaced the 1036 with a CCR2004 (on 7.18.2) to see if it is a combo architecture + conf.
I will let you know.
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 10, 2025 4:19 pm
by pe1chl
It must be related to configuration and/or usage pattern.
Re: v7.18.2 [stable] is released!
Posted: Thu Apr 10, 2025 10:39 pm
by Maggiore81
Well, I was upgraded perfectly fine till 7.18.1 - after 7.18.2 started the memory leak.
Downgraded to 7.18.1 and to 7.17.2 but the memory leak persisted.
So I made export-import into a CCR2004 arm64, and it now works flawlessy