As usual MikroTik does things without doing in-depth tests of what changing object names entails...I have issues with the backup script.
I made an export then upload via FTP.
7.12.1 works, from 7.13 no.
Non siete da soli..............we have spaces in ALL our system identities.
A small one ;):-D
chi sei, da che operatore?
Generically, using spaces in anything computing related is bad behavior MS enabled. Don’t use spaces in variables, names, or anything else along those lines and life gets a lot easier.It would always be best to adhere to common hostname format standards as system identity translates to hostname of the device.
!) console - replace reserved characters in file and script names with underscores;
[admin@Mikrotik] > /system/package/print
Columns: NAME, VERSION
# NAME VERSION
0 wireless 7.13
1 routeros 7.13
[admin@Mikrotik] > /system/package/update/install
channel: stable
installed-version: 7.13
latest-version: 7.13.1
status: ERROR: not enough disk space, 7.6MiB is required and only 7.6MiB is free
I may be wrong but noticed that now terminal is replacing spaces with _ , MT likes us to discover “fun” changes between the lines:I have issues with the backup script.
I made an export then upload via FTP.
7.12.1 works, from 7.13 no.
The script is described here:
viewtopic.php?p=1048251
Thanks. Yeah, fair point. I have the wifi-qcom package which appears to be correct for my deviceWrong package would result in zero performance.
Are you sure frequency settings are not set to auto and maybe not optimal ?
You did not change the package. So that does not apply to you. It only applies to those that have previously used the old "wireless" package and now are switching to "qcom-ac".I am slightly confused by posts that say to change the package will mean that all prior wifi config is removed; I guess it's not one size fits all, my device came back up without issue.
Thanks...*) wifi - fixed issue with setting country profile (introduced in v7.13.1);
script error: error - contact MikroTik support and send a supout file 
2024-01-14 06:18:50 system,error,critical router rebooted without proper shutdown, probably power outage 
I don't know if it is related, but I still need to disable/enable the underlying VLAN interface to make PPPoE work.*) vlan - fixed non-running VLAN interface after failed MTU change;
/interface bridge
add igmp-snooping=yes mtu=9796 name=bridge1 port-cost-mode=short vlan-filtering=yes
set [ find default-name=sfp-sfpplus1 ] l2mtu=9796 mtu=9796
/interface vlan
add interface=bridge1 mtu=1600 name=vlan6 vlan-id=6
add interface=bridge1 name=vlan100 vlan-id=100
/ppp profile
add name=profile-kpn-xs4all
/interface pppoe-client
add add-default-route=yes allow=pap disabled=no interface=vlan6 max-mtu=1500 name=pppoe-out1 profile=profile-kpn-xs4all use-peer-dns=yes user=blahblahblah
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1 internal-path-cost=10 path-cost=10 pvid=100
/interface bridge vlan
add bridge=bridge1 comment=Internet tagged=bridge1,sfp-sfpplus1 vlan-ids=6
add bridge=bridge1 comment=LAN tagged=bridge1 untagged=ether1,ether2,ether3,ether4,ether5,ether6,ether7,ether8,sfp-sfpplus1 vlan-ids=100
add bridge=bridge1 comment="Native untagged" untagged=bridge1 vlan-ids=1
/interface list member
add interface=pppoe-out1 list=WAN
add interface=vlan100 list=LANDon't tell me you made the mistake of installing an update in production before waiting at least 3 months in testing???@normis are you planning to revert the modification with spaces? We have THOUSAND of MT on the network with spaces in the "system identity", and they are without backup.
{
:local Identity [/system identity get name]
/system backup save dont-encrypt=yes name="Backup_$Identity"
}
Saving system configuration
Configuration backup saved
Thanks, I have netinstalled the router and got extra 200 KiB of free storage space.System Resources
I do hope 7.14 will be more stable. Is it really time for netinstall, which I have never run for this device?Code: Select alluptime: 18h5m28s version: 7.13.1 (stable) build-time: Jan/05/2024 13:51:11 factory-software: 6.43.10 # ... board-name: hAP ac^2 platform: MikroTik
If you you have never ever Netinstalled this device not even for the changing to v7 series (which is the risk averse way to go) than it is definitely time for ... Netinstall latest stable or testing...
/disk
add slot1 slot=slot1 type=hardware
add usb1 type=hardware
I got the same message after the upgrade from 7.13.1 (netinstalled) to 7.13.2 on my hAP ac2.Code: Select allscript error: error - contact MikroTik support and send a supout file
I don't see anything in the release notes about this item...I got the same message after the upgrade from 7.13.1 (netinstalled) to 7.13.2 on my hAP ac2.
Hi, is there always random reboot with 7.13.1 ? did you also test 7.13.2 ?And there is still nothing in 7.13.2 about the issue on RB5009UPr+S+ of the random reboot ?Code: Select all2024-01-14 06:18:50 system,error,critical router rebooted without proper shutdown, probably power outage
I had that problem as well, a month ago, when I upgraded to 7.13. So I did what it mentions and sent a supout file.(Device: hAP ac^2)
Log:
script error: error - contact MikroTik support and send a supout file (2)
error while running customized default configuration script: no such item
setting wifi to a country seems to get power to full value (ie canada 28 on 5GHZ 5745-5805) but on reboot goes to 8 on same frequency.. if you disable and re-enable interface it goes to 28 again properly. something on reboot isnt recognizing the right settings.What's new in 7.13.2 (2024-Jan-12 11:51):
*) leds - fixed default LTE LED configuration for wAPR-2nD;
*) lte - fixed cases where FG621-EA modem could be missing signal information in "lte monitor" (introduced in v7.13);
*) routerboard - added "reset-button" support for RBwAPR-2nD device;
*) sfp - improved combo-sfp handling for CRS328-4C-20S-4S+;
*) sfp - improved link establishment for RB4011 devices;
*) vlan - fixed non-running VLAN interface after failed MTU change;
*) wifi - fixed issue with setting country profile (introduced in v7.13.1);
I thought it would show only on the first reboot after the upgrade, but messages are present also on the second reboot (I didn't go on testing though).I had that problem as well, a month ago, when I upgraded to 7.13. So I did what it mentions and sent a supout file.
Reply: "Thank you for your report, we will check what is causing the "script error"."
Apparently they did not get around to doing that.
There is no Wireless->Wifi conversion at all. That is a bit problematic when you manage the device via wireless (e.g. the typical NAT router at home managed from a laptop, or a PtP link device managed from the remote end of the link).I'm pretty sure it's just a cosmetic one or might be something related to the Wireless->Wifi auto-conversion? (I'm not even sure there is one, I alway start from scratch ..so..).
The device works fine though, I quickly checked the export and everything seemed ok.
Hello, I was running 7.13.1 when I had this random reboot again. I've upgraded yesterday to 7.13.2 and had the reboot again during midnight today.Hi, is there always random reboot with 7.13.1 ? did you also test 7.13.2 ?And there is still nothing in 7.13.2 about the issue on RB5009UPr+S+ of the random reboot ?Code: Select all2024-01-14 06:18:50 system,error,critical router rebooted without proper shutdown, probably power outage
thanks.
Great news!*) ethernet - improved packet CPU core classifier for Alpine CPUs for non IPv4/IPv6 traffic;
@rextended Yes I did that mistakeDon't tell me you made the mistake of installing an update in production before waiting at least 3 months in testing???@normis are you planning to revert the modification with spaces? We have THOUSAND of MT on the network with spaces in the "system identity", and they are without backup.
*) wifi - use "Latvia" as default value for "country" property;
16dBm in 2.4 GHz is correct for European countries. (20dBm EIRP -4dBm antenna gain)I upgraded hAP ax³ to 7.13.2. Since I upgraded to this version I can't change the tx power.
2.4ghz always runs at tx16. Even if I change the country, it always works at tx 16 on the status screen and I cannot change it manually.
It should be possible to set this value lower ... but it's not clear if @mkbatur tried to lower the value.16dBm in 2.4 GHz is correct for European countries. (20dBm EIRP -4dBm antenna gain)I upgraded hAP ax³ to 7.13.2. Since I upgraded to this version I can't change the tx power.
2.4ghz always runs at tx16. Even if I change the country, it always works at tx 16 on the status screen and I cannot change it manually.
viewtopic.php?t=203076#p1049300
Antenna gain settings indeed kick in with frequency specific limit. But why would you want that? E.g. ETSI limit for part around 5800MHz is quite low. Why would you want to use even lower EIRP?I still use the "antena gain correction factor", which normally also is supposed to take care of the frequency specific limit and the needed reduction for higher MCS.
*) fetch - treat any 2xx HTTP return code as success (introduced in v7.13)
If it was a reply to my post,I guess MikroTik now must focus on the random reboots issue...
None of my devices is suffering from random reboots, so this is probably dependant on your specific configuration.I guess MikroTik now must focus on the random reboots issue...
Many of us are having this issue, so I guess you don't have openvpn tunnel configured and/or wireguard tunnel ?None of my devices is suffering from random reboots, so this is probably dependant on your specific configuration.I guess MikroTik now must focus on the random reboots issue...
So it's not entirely random, it's tied to some particular configuration. I'd say that's an useful input for mikrotik devs who will try to chase the problems down.Many of us are having this issue, so I guess you don't have openvpn tunnel configured and/or wireguard tunnel ?
None of my devices is suffering from random reboots, so this is probably dependant on your specific configuration.
I'm running 7.13.2 on a number of devices, and a couple of them do have wireguard tunnels, including the 2116 I use as my home/office router and use Wireguard daily from my phone and/or laptop to get back into the network. Neither those with nor those without wireguard have rebooted randomly.So it's not entirely random, it's tied to some particular configuration. I'd say that's an useful input for mikrotik devs who will try to chase the problems down.
And I agree with @whatever, none of my devices (running 7.13) suffer from reboots either. Indeed I'm not using neither openvpn nor wireguard nor DoH.
Please check ticket SUP-140482.
Requesting a fix for a DNS issue.
In version 7.13.1, there has been an occurrence of the DNS dynamic server going missing.
It appears to be a DNS crash.
It's confirmed that using the dns-to-address-list feature leads to the DNS crashing after a while.
Further tests in versions 7.13.2 and 7.13 also revealed this problem.
The system was upgraded from version 7.12, where everything was previously fine.
All devices that were upgraded from 7.12 and 7.12.x and use the dns-to-address-list feature are affected, especially the RB5009, which has a 100% occurrence rate. Please address this issue as soon as possible.
After some time of use, the DNS crashes.
I have support ticket open with them.So, people with reboots must send their supout files to Mikrotik, please. 🙂
No, hAP ac2 is finished. The flash space has run out and MikroTik is unwilling to do something about it (see discussion in 7.14beta topic).
See viewtopic.php?t=203076#p1049300Just upgraded my hAP AX3. Upgrade was ok and the router returned after a few minutes but I have noticed a major drop in WiFi performance with devices dropping from 450mbps plus to 75
...
Managing the device over a cable is tricky and I am keen to avoid breaking WiFi..is this performance drop due to the wrong package being used?
I just saw the discussion on the 7.14 beta topic, and I really hope that MikroTik decides to split some functions into different packages so we can have a smaller main one. I was able to get ZeroTier for now by using "wireless" instead of "wifi-qcom-ac," but the free space left is barely enough to make a single backup of my config. I also downloaded the 7.14beta7 npk, and it's already bigger than the 7.13.2... sad day for my old hAP ac².No, hAP ac2 is finished. The flash space has run out and MikroTik is unwilling to do something about it (see discussion in 7.14beta topic).
Probably the problem lies in OpenVPN (as it happened before, and Mikrotik took *months* to have it fixed). No autosup generated. Let's hope that they work on this, it's getting really frustating having these kind of problems on and off since I upgraded to version 7 (I have a RB5009, btw).So it's not entirely random, it's tied to some particular configuration. I'd say that's an useful input for mikrotik devs who will try to chase the problems down.
And I agree with @whatever, none of my devices (running 7.13) suffer from reboots either. Indeed I'm not using neither openvpn nor wireguard nor DoH.
I'm running 7.13.1. So 7.13.2 is stable now?I have also a RB5009 with openvpn client on running on it. Since version 7.13.1 the reboots magically stopped, but with 7.13 there were once or even twice a day. Even netinstalled as support suggested, but 7.13 wasn't playing nice. Don't know what was changed between version 7.13 and 7.13.2 as the support team failed to reproduce the error. Anyway I hope that when 7.14 goes stable doesn't break it again.
Nope my ax2's are still rebooting.So 7.13.2 is stable now?
Hello,Nope my ax2's are still rebooting.So 7.13.2 is stable now?
I had similar problem after upgraded from 7.13.1 to 7.13.2. I have a script to reboot the ac2 every morning. After upgraded to 7.13.2, it does not able to boot up. All I have to do is restore from a 7.13.1 backup image (all wifi interfaces, 2 physical and 3 virtual, are disable), then it can boot up. Also, reset to factory config can boot up too.It is probably just me, but upgrading from 7.12 to 7.13 on AWS broke the instance again and it does not boot any longer.
I had the same issue upgrading to 7.12 and was forced to recreate the instance.
Isn't there anything I can do to just get the upgrade on AWS working properly?
--Michael
1) Check the bridge’s protocol-mode, with AX2/AX3 it MUST be default value (rtsp).Just upgraded my hAP AX3. Upgrade was ok and the router returned after a few minutes but I have noticed a major drop in WiFi performance with devices dropping from 450mbps plus to 75
Why?1) Check the bridge’s protocol-mode, with AX2/AX3 it MUST be default value (rtsp).
No idea, found it out hard way by diffing configurations, why AX3 had much worse performance than AC2. With protocol-mode=rtsp all good and 1200@5GHz/AX as promised.Why?1) Check the bridge’s protocol-mode, with AX2/AX3 it MUST be default value (rtsp).
After posting that I had had none, I had two within the past 72 hours, one a 1036 and the other a CRS317.So, people with reboots must send their supout files to Mikrotik, please. 🙂
OK. Makes me feel better. Sort of. I thought I had seen/read it before.7.13 crashing when winbox is left open is a known bug
i updated 7.13.2 but i cant downrage back . its not work like before i downrageYes, you can downgrade. I use 7.12. It stable for me
What device is it and what is written in the logs?i updated 7.13.2 but i cant downrage back . its not work like before i downrage
And if logs report disk space as issue... you may be able to copy to PC and remove the backup files to free space before attempting downgrade.What device is it and what is written in the logs?i updated 7.13.2 but i cant downrage back . its not work like before i downrage
It's not "Try" but it is necessary otherwise the process tries to find a version of the wireless package to downgrade. But that package does not exist so downgrade will fail.Try removing the wireless package first. Then, perform a downgrade without the wireless package. I hope you are connected via cable, not WiFi.
I have been experiencing the same thing across multiple Mikrotik devices. Opened a ticket with Mikrotik Support (SUP-136194) and they determined it was DNS related, but none of the newer 7.14beta releases seems to be fixing it. DNS Cache size is clearly not respected and usage continues to grow. Once the cache limit is reached (less than 24 hours), I'm not able to "clear cache" or get the DNS Cache Used any less than what it's set to unless I reboot (or it crashed due to out of memory condition). The DNS cache table then does not show anything but static records (even though the cache is full???). It's a very strange bug and has been plaguing me.Just to let everybody knows, I have reported (SUP-128622) a memory leak on version v7.11.2, that continued on v7.12, v7.12.1 and v7.13. It seems to me and my undestandings of the supout files provided data, that it's still DNS resolver related.
I had initially reported a leak, that turned out to be really DNS resolver related, on v7.7 (SUP-105183, 20/January/2023), but it was fixed for the majority of my MK routers with v7.8rc2 and forward. But at least in one case, I'm still experiencing it, while having no real answers from Mikrotik Support Team on the SUP-128622 Support ticket. People just keep asking me to update to latest and provide new supout files, despite no changelog regarding leak or DNS changes.
With no other real options, I'm here asking for some help of the Mikrotik Staff Team that watches this community regarding the ticket SUP-128622
Here's an updated screenshot of memory usage on a RB2011 box with v7.13 over the last 8 (eight) days. IP/DNS is configured to use max of 16MB with cache data, but that amount was clearly not respected and usage is just growing, indefinitely, until the box crashes or I reboot it. The RB2011 is not a big memory box, with 128MB only, thus 25% of memory usage (that is all being used by the resolver process, confirmed by the supout provided data) is about 32MB, far beyond the 16MB configured limit.
PLEASE, HELP
.
mk leak.png
0 2023-12-23 07:52:45 memory system, info router rebootedWhat device is it and what is written in the logs?i updated 7.13.2 but i cant downrage back . its not work like before i downrage
Please open a separate topic for this issue. Since this issue is unrelated to the topic being discussed here.İ have mikrotik Mikrotik LDF 5 . This device is connected to the TpLink WR841N V11 indoor device with a cat6 cable. Wifi disconnects itself at random times. It gets fixed when you restart the TP Link device. If I do not put a wifi password on the TP Link device, there is no problem. i tried that another indoor acess point. i have same problem. so i know its about mikrotik
Is it related to device reboots, due to kernel failure?*) wifi-qcom - improved system stability when using FastPath (introduced in v7.13);
I did not notice any DNS service crashes despite using DoH in 7.13.1/7.13.2.......*) dns - fixed DNS service crash when DoH used (introduced in v7.13.1);
*) dns - fixed DNS service crash when DoH and hotspot used (introduced in v7.13.1);
And... Is it only about wifi-qcom, not wifi-qcom-ac?Is it related to device reboots, due to kernel failure?*) wifi-qcom - improved system stability when using FastPath (introduced in v7.13);
> system/resource/print
uptime: 1h1m3s
version: 7.13.3 (stable)
build-time: Jan/24/2024 13:16:46
factory-software: 6.40.5
free-memory: 180.3MiB
total-memory: 256.0MiB
cpu: ARM
cpu-count: 4
cpu-frequency: 448MHz
cpu-load: 0%
free-hdd-space: 164.0KiB
total-hdd-space: 15.2MiB
write-sect-since-reboot: 12876
write-sect-total: 4158636
architecture-name: arm
board-name: hAP ac^2
platform: MikroTik
> system/package/print
Columns: NAME, VERSION
# NAME VERSION
0 routeros 7.13.3
1 wireless 7.13.3
*) wifi - use "Latvia" as default value for "country" property;
TX power allowed changes with Country and ROS version. Change between versions can be dramatic. Eg Europe for 5745+ freq from 30dB to 16dB"Why the hell would the country-related changes affect the stations (i.e., Mikrotiks as wireless clients)?"
And I have seen some long lists in this forum of the power limits in earlier but recent ROS versions for the wifiwave2.Probably this change since 7.13.1:*) wifi - use "Latvia" as default value for "country" property;
You need to go to packages and "uninstall" the wireless package.Hi guys, I have upgraded my setup but for some reason I can not update my CAP AC2 to the qcom-ac package, I have done just like in the mikrotik yourube viode, draged it into files and rebooted, but everytime my cap boots up the file is gone but ther is still the old wireless package?
Funny, in the youtube he jsut drops the new wifi package and reboots, that is what I have been doing, but I'll try to remove the old one first :)You need to go to packages and "uninstall" the wireless package.Hi guys, I have upgraded my setup but for some reason I can not update my CAP AC2 to the qcom-ac package, I have done just like in the mikrotik yourube viode, draged it into files and rebooted, but everytime my cap boots up the file is gone but ther is still the old wireless package?
You can then drop the new AC package on and reboot - it will uninstall wireless and install wifi.
DISCLAIMER - I have only done this on hAP AC2 and on 7.13.1 and 7.13.2 - the process "should" be exactly the same with the same result (presuming H/W Support)
Yesterday, I upgraded again but now to 7.13.3 and everything with vpls is ok 👍I have a similar problem, on devices using MPLS/VPLS I see kernel panics every few hours and a lot of problems with packets not being forwarded or routed properly. I have seen it on an RB4011 (arm), RB5009 (arm64), and CCR1009 (tile). No supout generated, just a log message about the router being improperly rebooted and a suggestion that a kernel panic might be the reason.I tested this version on my CCR 1016 where MPLS and VPLS {LDP} is running. After 3 to 5 minutes router reboots and it keeps repating over and over. On version 7.12.1 everything is ok. Has anyone same experience? No error in log.
Seemingly the meaning of stable according to Mikrotik is exclusively:... issue is present on RoS 7.13+ versions, it is recommended to perform a temporary downgrade to RoS 7.12.
Are you sure this is limited only to OpenVPN?Seems we have managed to replicate the issue with the RB5009 oVPN clinet/server hardware encryption causing the router to reboot.
We are working on releasing the fix, as of today, issue is present on RoS 7.13+ versions, it is recommended to perform a temporary downgrade to RoS 7.12.
So is a 7.13.4 release coming with this fix and others? At this point I'd love to see 7.13 turned into an LTS release since we're already 3 releases in, and possibly another one is coming?Seems we have managed to replicate the issue with the RB5009 oVPN clinet/server hardware encryption causing the router to reboot.
We are working on releasing the fix, as of today, issue is present on RoS 7.13+ versions, it is recommended to perform a temporary downgrade to RoS 7.12.
Finally! Let's hope this is fixed quickly, if possible a 7.13.4 version...Seems we have managed to replicate the issue with the RB5009 oVPN clinet/server hardware encryption causing the router to reboot.
We are working on releasing the fix, as of today, issue is present on RoS 7.13+ versions, it is recommended to perform a temporary downgrade to RoS 7.12.
Hey, yes i got the same issues. Looks like is not fixed yet.... Problem ocurs with 7.13, before was no ProblemeAfter finally getting DOH working on my hAP AX lite, having downloading numerous certificates, I did a full clean config and I have got the router connecting to Cloudflare, but occasionally I get the following error messages in my log
DoH server connection error: Idle timeout - connecting
DoH server connection error: Idle timeout - connecting [ignoring repeated messages]
DNS seems to be connecting OK, I have only put 10GB through the router since I set the new config this morning. Is anyone else getting these error messages?
Hey, yes i got the same issues. Looks like is not fixed yet.... Problem ocurs with 7.13, before was no ProblemeAfter finally getting DOH working on my hAP AX lite, having downloading numerous certificates, I did a full clean config and I have got the router connecting to Cloudflare, but occasionally I get the following error messages in my log
DoH server connection error: Idle timeout - connecting
DoH server connection error: Idle timeout - connecting [ignoring repeated messages]
DNS seems to be connecting OK, I have only put 10GB through the router since I set the new config this morning. Is anyone else getting these error messages?
Then Mikrotik should check that, when setting the identity and not accept spaces (and other characters that doesn't belong there) :)It would always be best to adhere to common hostname format standards as system identity translates to hostname of the device.
It's not "wrong". Space should be encoded by RouterOS downstream if needed by some protocol. Since /system/identity mainly comes up in LLDP/CDP/MMDP – and winbox – I can see why some folks want to have spaces to make things more readable & not sure space violates those specs. And DNS on RouterOS does not use it.Then Mikrotik should check that, when setting the identity and not accept spaces (and other characters that doesn't belong there) :)It would always be best to adhere to common hostname format standards as system identity translates to hostname of the device.
It kinda limits the usefulness of newer /file/add since you may need to create a file with spaces for container/etc/etc. Like /system/identity, spaces have long been allowed in file names.*) console - replace reserved characters in file and script names with underscores
Glad to ear that ! :)Seems we have managed to replicate the issue with the RB5009 oVPN clinet/server hardware encryption causing the router to reboot.
We are working on releasing the fix, as of today, issue is present on RoS 7.13+ versions, it is recommended to perform a temporary downgrade to RoS 7.12.
# model = RB760iGS (hEX S)
/ipv6 address
add address=::a55:31ff:fe12:581a eui-64=yes from-pool=Altibox interface=vlan-home
add disabled=yes eui-64=yes from-pool=Altibox interface=vlan-management
add disabled=yes eui-64=yes from-pool=Altibox interface=vlan-guest
add disabled=yes eui-64=yes from-pool=Altibox interface=vlan-dmz
add address=::1 from-pool=Altibox interface=bridge no-dad=yes
/ipv6 dhcp-client
add add-default-route=yes interface=altibox-wan pool-name=Altibox pool-prefix-length=48 request=prefix use-peer-dns=no
/ipv6 firewall filter
# Omitted for brevity.
/ipv6 nd
add disabled=yes interface=bridge ra-interval=20s-1m
/ipv6 settings
set max-neighbor-entries=8192
Yes, in particular the hAP ac2 is in trouble, and MikroTik is in denial.One of my hAP ac2 running v7.13.2 had an interesting and totally unwanted behavior earlier today:
The router was reporting about 3% free space (so not totally full). If this is going to happen to everyone on normal install, we are getting into interesting times.
Not exactly true. Every 7.14 version requires more and more free space.Yes, in particular the hAP ac2 is in trouble, and MikroTik is in denial.
It will be interesting indeed... we will have to see what comes out of it.
It seems they were able to squeeze some space in the latest 7.14 beta. I would recommend remaining on 7.12.2 (so before the wireless changes) at least until 7.14.1 is released (and follow the release topic to see how things are).
11 435 632 Jan 8 11:43 routeros-7.13.1-arm.npk
11 431 544 Jan 15 11:16 routeros-7.13.2-arm.npk
11 423 348 Jan 25 11:19 routeros-7.13.3-arm.npk
11 591 276 Jan 11 10:16 routeros-7.14beta6-arm.npk
11 611 760 Jan 16 11:13 routeros-7.14beta7-arm.npk
11 619 964 Jan 23 15:40 routeros-7.14beta8-arm.npk
11 742 852 Feb 2 13:04 routeros-7.14beta9-arm.npk
Gains are meaningless if you immediately lose those gains if you want to use wifi-qcom-ac. Because that package is just as big. Combine that with 7.14beta9 RouterOS main pacakge and you can see that the situation is not great.The wireless package is ~500kb smaller in 7.14, so while there is ~320kb increase in main package... 7.14 uses ~180kb less space than 7.13.3 (using same wireless+routeros combo).
I did an upgrade via the package menu in winbox.Did you run into this issue when trying to configure the router from an export, or when just rebooting it after the upgrade?
There is this bug in the /export that it exports /ipv6 address before /ipv6 dhcp-client, but it has been like that for longer than 7.13.3 and it usually seems harmless.
Could it be that your IPv6 dhcp-client could not obtain a prefix? (e.g. ISP was temporarily unreachable)
I don't believe so. It has been already explained that separating packages creates a lot of overhead - wasted space. I also think that it isn't best approach to force users to uninstall feature, just so they can use a device they recently purchased. hAP ac2 isn't even legacy/EOL. New units are is still for sale so new users will face similar situation more and more often.Regarding hap ac2 lack of space, mikrotik could partition the router OS main package into smaller packages (again) and let the user choose the functions he wants to install.
Absolutely agree. IMHO best would be to start releasing RoS based on device model (not architecture) thus saving a LOT of space due to removal of extra drivers, which are at the moment bundled together. That could give second breath to devices with limited space.The design process of the package system seems erratic to me, ... don't you think?
Hopefully not for long. Thats why I am reporting it as a bug in this topic and not in RC/testing topic. This is IMHO no longer issue for a few individuals who are trying to add additional packages. This is becoming widespread and mikrotik surely understands the damage to reputation it could create if it gets more common and and starts getting media attention. I just hope they will approach it reasonably and not solve it by EOLing all devices with limited space. I have another device with ~50kB config which I assume will play up soon-ish but is in less critical spot so I might let it become unstable and then ask support@ for their opinion, if there is no staff answer here.MikroTik is in denial.
Good point. TBH, I don't think there will be some magic in 7.14+ which suddenly gives us lot of extra space. That is unavoidable consequence of adding more and more features.I would recommend remaining on 7.12.2 (so before the wireless changes) at least until 7.14.1 is released
Well, the "overhead" in packaging has to be less then 17kb... since that the size of the lora.npk (which has code for LoRaWAN too).It has been already explained that separating packages creates a lot of overhead
There appears to be some extra space in the latest 7.14beta versions, at least on the hAP ac2.Good point. TBH, I don't think there will be some magic in 7.14+ which suddenly gives us lot of extra space. That is unavoidable consequence of adding more and more features.I would recommend remaining on 7.12.2 (so before the wireless changes) at least until 7.14.1 is released
As long as updates are coming, they are free. This could mean for ROS v6, MT may limit these updates to security updates only. Statement fulfilled.The device includes free software updates for the life of the product or a minimum of 5 years starting from date of purchase..
And even worse: 15.3MB FlashProblem are all ARM wireless devices with 16MB flash.
In 7.13.3 arm npk route binary is actually the largest one, it is so huge at 541k compressed (1.4M unpacked) that I am pretty sure it contains linked in some kind of routing daemons to support OSPF, BGP, RIP etc... and although separating those daemons probably would not be an easy task it makes sense on smaller devices or switches that would never participate in a dynamic routing.I don't believe that routing protocols significantly increase the size of the main package or are easy to separate. The biggest impact comes from binary files. There are some with significant size and not everybody needs. dot1x (100k), lcdstat (212k), quickset (136k), smb (168k in 7.13.3), upnp (108k), wproxy (140k). And then there also a lot of drivers in the main package that are not needed for running a e.g. "Chateau LTE12". Extract that additional drivers into drivers extra package). Then also separate the wifi-qcom-ac package based on the chipset, or at least only install the chipset-relevant firmware/drivers from the package onto the flash. And suddenly we would see like at least 2MB free space on 16MB flash devices.
And fun facts:
The main package even contain files not relevant for them. e.g. under "/home/web/help/zerotier.txt" is lying around a license textfile for zerotier. com'on - zerotier is a separate package. put that license file to that package. Really.
I saw the binary size. This is a probably a big monolithic binary aka "god binary". Quite likely this is the reason why pe1chl suggestion to move some "exotic"/"advanced" routing protocols to some extra package is declined (like seen here: viewtopic.php?p=1049937#p1049937). Maybe the "smartest poster" did already know that there exists some hurdles....:DIn 7.13.3 arm npk route binary is actually the largest one, it is so huge at 541k compressed (1.4M unpacked) that I am pretty sure it contains linked in some kind of routing daemons to support OSPF, BGP, RIP etc...
In 7.13.3 arm npk route binary is actually the largest one, it is so huge at 541k compressed (1.4M unpacked) that I am pretty sure it contains linked in some kind of routing daemons to support OSPF, BGP, RIP etc... and although separating those daemons probably would not be an easy task it makes sense on smaller devices or switches that would never participate in a dynamic routing.
It still needs some user-land program to manage static routes, and I strongly suspect they put everything routing into a single binary.And for static routes linux doesn't need to run any daemons.
If they did it, then it was a poor design decission.It still needs some user-land program to manage static routes, and I strongly suspect they put everything routing into a single binary.And for static routes linux doesn't need to run any daemons.
It all boils down to space. Each package have its own overhead. The question is: "does the package overhead is bigger or smaller than the space we save breaking it up?"
If they did it, then it was a poor design decission.
No, that is not the question. The question is if we can have a useful subset of RouterOS functionality plus one or more extensions, which still fits in the flash memory, so the user can choose what functions they want. They cannot have everyhing because that would not fit (that is the place we are now), and making the combination of every function slightly larger is not what we worry about.The question is: "does the package overhead is bigger or smaller than the space we save breaking it up?"
It all boils down to space. Each package have its own overhead. The question is: "does the package overhead is bigger or smaller than the space we save breaking it up?"
If they did it, then it was a poor design decission.
Mikrotik says it's bigger.
I have no idea - but I think they know it better than I. At least, I hope so.
I have 2 rb5009 and they never reboot with 7.13.3.Does this fix the random reboots of the RB5009?
bridge - avoid per-VLAN host flushing on HW offloaded bridge (introduced in v7.13)
That's precisely my question! I rolled back all my managed devices to version 7.12.x until I see this firmware version fixed the random reboots. I use a lot of VPNs so for me is a non-go if this issue is not addressed with this new release.I have 2 rb5009 and they never reboot with 7.13.3.Does this fix the random reboots of the RB5009?
It would be interesting to identify what is the source of those reboots (vpn, routing).
Does this mean that the reboots mentioned by a few others after your post, are resolved? It would be interesting to see more about that.What's new in 7.13.4 (2024-Feb-07 11:59):
*) ovpn - improved system stability when using HW encryption on ARM64 devices (introduced in v7.13);
Hey there, I'm running same IPTV as you and can't see any problems (RB5009 on 7.13.4 and Adguard DNS container) but yes, Mikrotik site and forum are slow for me too... Forum keeps asking me to log in and had trouble posting something, I got 500 error in browserHello all. I don't know how it is with you, but I have a problem with version 7.13.4. DNS works much slower, there is buffering on Telemach-EON tv, netflix has delay by 2-3 sec to load content, web pages load slower, i downgrade to 7.13.3 and now is all works ok.
You have 0% of load on the CPU, put some load on it and check again.Dear Concern,
We are using multiple Dell servers in my ISP network. Recently we upgraded one dell R620 Server Mikrotik os version 6 to OS version 7.12.1 stable. Then we can see my CPU frequency showing only 1200Mhz. That was 2600Mhz when I was using the OS 6 version. Can you please help me how i can get 2600Mhz full frequency with OS V7 ? Please see attached file file for reference:
Thanks for reply, Its always show 1200Mhz if i use os 7, never change also in Full user load, Only if i downgrade to OS v6 then CPU again show 2600Mhz, Any idea how to solve this issue?You have 0% of load on the CPU, put some load on it and check again.Dear Concern,
We are using multiple Dell servers in my ISP network. Recently we upgraded one dell R620 Server Mikrotik os version 6 to OS version 7.12.1 stable. Then we can see my CPU frequency showing only 1200Mhz. That was 2600Mhz when I was using the OS 6 version. Can you please help me how i can get 2600Mhz full frequency with OS V7 ? Please see attached file file for reference:
Rose is much more than just SMB (it contains nfs, btrfs ...) and is external package, not in the main package.Not only they're not unbundling optional packages like PPP and Routing, but they also added Rose (SMB) functionality to the main package. IMO smb functionality is also optional and shouldn't be included in the main bundle.
Thanks for reply, I am using Dell R620 Server, So there is nothing in Routerboard option.May it be related to cpu scaling ?
what is on system routerboard settings ?
Do you observe actual decreased performance? Or are you just obsessed by what is shown in that dialog?Thanks for reply, Its always show 1200Mhz if i use os 7, never change also in Full user load, Only if i downgrade to OS v6 then CPU again show 2600Mhz, Any idea how to solve this issue?
IDK, strange. Although sometime they add commands, even if they are not supported or documented... e.g. /interface/lte/esim is just there, no docs.I encountered a new and for me unknown property on lte interface. It is "sms-read".
[...]
At that moment my mind exploded. How can a new config option from 7.14 testing branch be available in 7.13 stable branch? There is not even a single mention in the 7.13 changelog for this.
status: off
receive-enabled: yes
port: lte1
channel: 0
secret:
allowed-number:
sim-pin:
last-ussd:
/interface bonding
add lacp-rate=1sec mode=802.3ad name=bond-peer slaves=qsfpplus1-1,qsfpplus2-1 transmit-hash-policy=layer-3-and-4
/interface bridge
add admin-mac=DC:2C:DE:AD:BE:EF auto-mac=no name=bridge priority=0x5000 vlan-filtering=yes
/interface bridge mlag
set bridge=bridge peer-port=bond-peer
/interface bridge port
add bridge=bridge comment="MLAG Peer:" interface=bond-peer pvid=99 trusted=yes
add bridge=bridge edge=no-discover interface=bondsfp1 restricted-role=yes trusted=yes
/interface bridge vlan
add bridge=bridge comment=Core: tagged=bridge,bond-peer vlan-ids=1
/interface vlan
add interface=bridge name=vlan1 vlan-id=1
/ip dhcp-client
add interface=vlan1
Thanks! I did exactly what you suggested.Yet another control we loose with wifi drivers. You will have to manually exclude those frequencies.
I'm definitely seeing the wireless client degradation issue since upgrading to 7.13.4 from 7.13.2, on my WapAC (non wave2). Clients which are only 10 meters away are now only getting a signal strength of -89/-90.I upgraded my hAP ax3 CAPsMAN APs (there are 8 of them) together with an RB5009 running CAPsMAN on Friday. I appear to be noticing that some wireless clients are having problem keeping their connection. Has anyone else noticed a degradation since 7.13.3, nothing in the change logs...
I have not that problem on my hEX. Running 17.3.3 and still have not removed the not needed wireless package, I have 1388KiB free out of 16MiB.Found out that I can't reboot my HEX without first deleting backup in storage because of lack of space. Space on 16mb devices is becoming a bit of a limiting factor.
Just compare MIPSBE, MMIPS and SMIPS wireless package sizes with ARM on 7.14rc1. Also look at wifi-qcom-ac package size as well. Definitely progress on MIPSBE, MMIPS and SMIPS, but unfortunately still not enough for every single ARM based Mikrotik hardware with 16MB flash. Something still needs to be done with both with wireless package and wifi-qcom-ac package sizes on ARM because lots of people actually want wifi-qcom-ac and NOT wireless.Fwiw, Hex running 7.14rc1 including wireless package (using it as test for dual capsman setup):
How can one run ROS 7 on a hAP lite? I've tried this several times and even just as a CPE (no firewall filter rules, a blank config in fact) it was barely unusable. Slow to unresponsive CLI. And basically hung up every 2 days and needed a power cycle. A real 🫓.I've upgraded another HAP Lite just to make sure and it has also bricked (it's located on another site, near my home, so I will be able to inspect it personally soon).
It is better not to do it. Just remain on v6.How can one run ROS 7 on a hAP lite? I've tried this several times and even just as a CPE (no firewall filter rules, a blank config in fact) it was barely unusable.
hap lite running happily and rock stable on ROS 6.It is better not to do it. Just remain on v6.How can one run ROS 7 on a hAP lite? I've tried this several times and even just as a CPE (no firewall filter rules, a blank config in fact) it was barely unusable.
Thanks.I've had better luck with the 32bit binary for some reason
I can confirm that there is something strange with Wireguard on 7.13.4. My HAP AC2 has always worked perfectly with this version of ROS and all remote RBs via Wireguard. I updated two remote AX2s and never reached them again. The two AX2s work perfectly, but Wireguard somehow goes down. Yesterday I tried to restart my AC2 and surprisingly I resumed the connection with both of them. I had tried to turn off the Wireguard interface but it wasn't helpful, only the reboot was helpful. This morning I lost the connection with one of the two and not even restarting my AC2 again I'm solving. I should restart the remote AX2. Never had such problems, all RBs have the 7.13.4 with updated firmware. The configuration of these RBs is very simple being three houses with simple configurations. Has anyone found any quirks with Wireguard and this build of ROS?A little while ago I updated two AX2 remotes from 7.13.2 to 7.13.4 and I agreed that I can no longer reach them but I know for a fact that they are working perfectly except for Wireguard... Just me?
Thank you Mikrotik for the work and, above all, for not abandoning the AC devices. A question: I see that a lot of work is being done with the wifi-qcom driver, but do these changes indirectly also affect the wifi-qcom-ac or not?What's new in 7.13.5 (2024-Feb-16 19:35):
*) bridge - fixed MLAG connection after peer-link flap (introduced in v7.13);
*) bridge - fixed packet forwarding after changing HW offloaded bridge interface settings in certain cases (introduced in v7.13);
*) dns - do not close connection with DoH server after query execution (introduced in v7.13.3);
*) leds - fixed modem signal strength for RBSXTR&R11e-LTE (introduced in v7.13);
*) sms - increased SMS read timeout;
*) wifi-qcom - improved memory allocating process;
*) wifi-qcom - improved regulatory compliance for L11, L22 devices;
*) wifi-qcom - improved system stability for L11, L22 devices;
I think not. I still see so many "introduced in 7.13x" bugfixes that I think there have been major changes and 7.12.x should be the longterm release.7.13.5 one more step against Long Term release :)
It is not by spending a long time without releasing corrections that a Long-Term version is made.7.13.5 one more step against Long Term release :)
have the same one - will have a look how mine behaves this or next weekSame router, all working ok for me, no issue.RB1100dx4de reboots after few seconds, no supout.rif created, no time needed to do this.
Hi!I'm not 100% sure it's related to this release but I haven't seen this in any earlier ones and I had all of 7.13.0-7.13.3 before.
Hardware: hAP ac2 with 7.13.4 and wifi-qcom-ac configured as CAP with some vlan extras.
Since 7.13.4 the vlan bridge is changing its MAC address multiple times. After the last reboot this was going on for 5 minutes until it stabilized on one MAC. During that time CAPsMAN connection breaks after every change.
Log snippet:
Bildschirmfoto_2024-02-17_19-56-39.png
Anyone can give me a pointer what could be wrong? Or could it really be related to this version?
It was always the best practice to manually set Admin MAC Address of the bridge to MAC of the underlaying ethernet interface...Hi!I'm not 100% sure it's related to this release but I haven't seen this in any earlier ones and I had all of 7.13.0-7.13.3 before.
Hardware: hAP ac2 with 7.13.4 and wifi-qcom-ac configured as CAP with some vlan extras.
Since 7.13.4 the vlan bridge is changing its MAC address multiple times. After the last reboot this was going on for 5 minutes until it stabilized on one MAC. During that time CAPsMAN connection breaks after every change.
Log snippet:
Bildschirmfoto_2024-02-17_19-56-39.png
Anyone can give me a pointer what could be wrong? Or could it really be related to this version?
I have the same issue on wAP ac (RBwAPG-5HacT2HnD). RouterOS and Firmware are v7.13.4, and after a reboot the MAC addr. of bridge is changed every time... This will be a bug.
I can handle this with a fix ip instead of using dhcp, but I'm using it a simple AP without capsman.
So you are saying that we should just forcefully set an Admin MAC to workaround the issue? Still the question remains why this suddenly is a problem as it may be a bug? In any case I reported to support@ and waiting for feedback.It was always the best practice to manually set Admin MAC Address of the bridge to MAC of the underlaying ethernet interface...
Hi!
I have the same issue on wAP ac (RBwAPG-5HacT2HnD). RouterOS and Firmware are v7.13.4, and after a reboot the MAC addr. of bridge is changed every time... This will be a bug.
I can handle this with a fix ip instead of using dhcp, but I'm using it a simple AP without capsman.
Looking ar routing process stats hints to crashes of RIP process as PID for this process changes after autosupout is created and new redundant set of route instances appears in route list. It is not possible to predict how much time it takes for next crash to happen as sometimes it is possoble to get to 48+ hours uptime and sometimes it is less than 10 hours before everything related to routing becomes unresponsive and one core is maxed out (necessitating a reboot). Only thing left is to try to use "single-process" option in routing settings, but is not clear can it help with this or not.RB450Gx4 was upgraded from 6.49.13 and all RIP configuration had to be recreated.
All was fine for a while and then I see entries in log about creating RIP instances (same ones that do already exist). After that route list is populated with duplicate entries for all these instances. At same time autosupout file is created as well. It seems like route list would not be cleared if RIP instance interface(s) go down as route entries do not time out. Only way to ger route list cleared is reboot.
Same happens again after some time and then there are 3 instances of every RIP route and another autosupout file is created. After longer uptime dynamic routing stops working alltogether and route list or ip/route/print do not display anything while one CPU core is maxed out (log has entries "timeout while waiting for program 44"). Only way out is reboot.
Other endpoints see everything as normal and traffic flows normally unless routing stops working as described above.
SUP-144199
Why? What if there is bug in 7.13.4 and 7.13.5 did not fixed this problem??? Think a bit....They will mention the problem in one thread(7.14.4) and then will jum to another thread (7.13.5) without any history of the problem???Is this thread for 7.13.4 or 7.13.5. I see when you quote posts it uses the tilte for that post, not title for the thread, so posts above show 7.13.4 even if it should show 7.13.5.
So once again MikroTik. Use a new thread for every new Stable/Long Term a before.
AFAIK a Bridge has no own MAC address, and it takes the interface MAC address of the first active Port.So you are saying that we should just forcefully set an Admin MAC to workaround the issue? Still the question remains why this suddenly is a problem as it may be a bug? In any case I reported to support@ and waiting for feedback.
Because upgrader is obviously pretty stupid (as it can't only install e.g. wireless driver for device's chipset) and installer in 7.12 is only smart enough to select one additional package ... regardless the device model.After upgrade from 7.12.1 to 7.13.5 (but surely it will be the case with any 7.13.x version), wireless package was also present, eating away precious storage space. Why ? On a switch ?
I don't even run zerotier on it.But then: are you sure you don't want to run legacy CAPsMAN on your switch?
Because wireless was part of the main routeros package in 7.12. If wireless package wasn't installed by default during update to 7.13, you would lose features like legacy capsman.wireless package was also present, eating away precious storage space. Why ?
I know why it got installed (way too broad default upgrade behavior) but my point is that this happens on a device NOT using wifi and normally NOT being used as capsman controller (but it can, I do realize that).Because wireless was part of the main routeros package in 7.12. If wireless package wasn't installed by default during update to 7.13, you would lose features like legacy capsman.
Packages are upgraded before configuration is parsed so there is no way to know if you are using CAPsMAN or not, and as it was already explained to you wireless was the part of previous bundles so in order not to brake anything it is installed as the part of the upgrade process. Once you uninstall wireless package in version 7.13 it will not be installed on subsequent upgrades. And since you obviously didn't have any problems associated with it I don't see the point of your ranting...If capsman wasn't enabled, there is 0.0 reason for having that wireless package installed.
My take:
Don't install it by default on a switch.
If needed, device's admin can always add wireless him/herself. But at that point I suspect it's an admin knowing what he/she is doing.
How do I use grep command? Cannot find any reference in the docs or forums.
Would be nice to be able to do something like
:grep pattern [/ip/firewall/address-list export]
The <script> part is confusing. But since it's the ugly ducky of scripting with odd syntax... :grep is a UNIX thing, so the <script> is the command as a string, not RouterOS syntax. But real grep takes the pattern as default... make this even more confusing.:grep <F1>
<script> -- source of the script to execute
after -- lines to be printed leading context
as-array -- put output in an array
before -- lines to be printed trailing context
filename -- save output to file
pattern -- extended regular expression pattern
:grep "/ip/firewall/address-list export" pattern=".*":global multilineString "hello\nworld\nhello world"
:global hellos [:grep ":put \"$multilineString\"" pattern="hello.*" as-array]
:put $hellos
# hello;hello world
:put [:len $hellos]
# 2Still waiting on the NAT-PMP docs ...But Mikrotik should add some docs on :grep...
I did a reset and reconfigured the device. For a while it started to look like that report was false as it was able to get over 48 hours of uptime without problems but now route list statis made a record as previously routing locked up far earlier than this count of crashes. Every uptick in this graph counts for a crash in routing - list of about 400 routes grew up to 6000. Only way out was to disconnect the power (reboot command left device unresponsive) - and this of course is on 7.13.5, which did not brought any changes (in this behaviour compared to 7.13.4)RB450Gx4 was upgraded from 6.49.13 and all RIP configuration had to be recreated.
All was fine for a while and then I see entries in log about creating RIP instances (same ones that do already exist). After that route list is populated with duplicate entries for all these instances. At same time autosupout file is created as well. It seems like route list would not be cleared if RIP instance interface(s) go down as route entries do not time out. Only way to ger route list cleared is reboot.
Same happens again after some time and then there are 3 instances of every RIP route and another autosupout file is created. After longer uptime dynamic routing stops working alltogether and route list or ip/route/print do not display anything while one CPU core is maxed out (log has entries "timeout while waiting for program 44"). Only way out is reboot.
Other endpoints see everything as normal and traffic flows normally unless routing stops working as described above.
SUP-144199
Would really like to hope that internal development documentation is better than these incomplete "placeholders" in user documentations that sometimes lack even most basic things like default values for parameters etc. If development documentation would be as bad then there would not be much hope in getting out of current state of mess...There are lots of commands with incomplete documentation. They should get an intern (or group of 2 or 3) tasked with documenting all commands in the same format and checking if every option is documented.
https://help.mikrotik.com/docs/display/ROS/NAT-PMPStill waiting on the NAT-PMP docs ...
