That for sure is not a good idea. Some “debug” topics send a lot of data, more info than the router transports.
In some cases it can even cause an avalanche (depending on how your syslog server is connected), where it logs that it logs that it logs (etc).
Do you know that to export passwords, keys etc into config file you need to use the additional option “show-sensitive” ?
export file=myconfig show-sensitive
Additional info:
this behavior was changed from ROS6 (default show-sensitive) to ROS7 (default hide-sensitive).
Please
before you reply to post, read the WHOLE post
as you could see, and hopefully read, you will notice
that after crash, WG key was missing from export
AFTER modifying WG key, it was exported as expected
so, yes, i know how to export sensitive things, like passwords and WG keys
This behavior was reverted in 7.2.2 back to how it was before but this has only been done for IPv4. With IPv6, Routing rules still have priority over Routing marks.
In some cases of instability it can help to do this:
- /export show-sensitive file=export
- download the export.rsc file to your computer
- netinstall the device (do not keep the config and omit default configuration)
- connect using MAC address
- upload the export.rsc
- check with /export to the terminal that config is empty, remove what you see (e.g. DHCP client)
- /import verbose=yes export.rsc
hopefully it will finish the import without errors. when it doesn’t, start at the next item using:
/import verbose=yes skip-lines=123 export.rsc (when the error is in line 123)
This way you remove the config database and re-fill it with the readable config that you have.
(making sure there are no strange things left behind)
In v6, this never fixed a problem, at least not for me. For v7, this appears to be different.
Save RouterBOARD full backup of everything [configuration, certificates, host key, router users (no passwords), user-manager, dude, other files]
http://forum.mikrotik.com/t/router-crashes-are-wiping-the-config/149189/7
Yes it skips some items, fortunately they usually are either not commonly used, or stored somewhere else anyway (e.g. SSH key). But the original asker of the question can take this advice into account.
I think one of the things to do on v7 development is to include all such data in a /export show-sensitive output, in such a way that it can be re-imported too.
(e.g. a password can be output in hashed form, but using an option name like hashed-password= that the /user add command would then be able to process)
From unprotected backup you can extract idx and dat of user database.
Why not export on /user export show-sensitive file=users.rsc also the hash already readable on database? (And the possibility to set back?)
Is more simple manage users…
If you have more than one IP addresses you can set the one that is used by default for this particular route…
[quote=vmarkelov post_id=934138 time=1652961447 user_id=201182]
[quote=woro post_id=933744 time=1652790401 user_id=80222]
Upgraded from 7.1.x to 7.2.3 on my RB4011 and it seems that it started crashing once in a while which was not an issue with 7.1.x.
Smells a bit like my earlier issues here: <LINK_TEXT text=“viewtopic.php?t=179071”>https://forum.mikrotik.com/viewtopic.php?t=179071</LINK_TEXT>
[/quote]
For me helped disabling CapsMan
[/quote]
Disabling Capsman is not an option for me.
I’ve contacted support, collected a supout.rif and downgraded to 7.1.5.
All fine again.
Capsman and v7 are not yet friends… I would recommend to remain on v6 until that is fixed.
Works fine for me with 7.1.5 for quite a while. I guess I’ll stay on long-term then for now. But still would like Mikrotik to acknowledge the crash/reboot issue and address it.
I run a small capsman setup using 7 2.
Hasn’t crashed yet nor any other problems for the past 2 weeks.
Route with dst-address=“” can be exported, but not printed or deleted [ROS 7.2.3]
http://forum.mikrotik.com/t/route-with-dst-address-can-be-exported-but-not-printed-or-deleted-ros-7-2-3/158008/1
SUP-82277
Same problem in 750Gr3 for me too. Emailed support with supout. SUP-82725
Works for me too, 7.1.5, later versions and 7.3beta are too flaky but 7.1.5 is romping along ok, 56days of uptime on one of my hapac2’s and 45days on the other without issues, RB3011 which is the manager is presently at 27 days, would be 56days too but made the disastrous decision to try one of the newer 7.2 STABLE releases and reverted back.
So yeah, 7.1.5 is a winner out of the 7.x tree thus far.
the new inter NIC x7xx driver in 7.2.3 let my x86 box reboot each 2 days.
icmp (ping stop working from the router) issue still present
Does anybody else have issue that Chateau LTE 12 is randomly rebooting about two times per day?