I think that safe mode need to be more like time based than session based
since some times you need to change remotely a config and that maybe will obvious close the session but not necessary it a mistake
so it better to setup a timer
Ubiquiti equipment allows you to ‘test’ a change…
If you mess up, just Wait the 120 seconds!!
Phew!
Sent from my iPhone using Tapatalk
Yes,
Make it so that you can queue a bunch of changes and test deploy them for 120s or so.
+1
I hope mikrotik team need to think about this functionality
Enviado de meu XT1580 usando Tapatalk
Obvious requirement for a multitude of remote changes +1
been requested since 2017?
I don’t understand this request. Safe mode already allows multiple changes. It will not do anything, unless your config causes disconnect. So commit your 10 changes and wait for 120 seconds before exiting safe mode. It’s the same as you ask now, except that the time is shown on screen?
A slight difference between what’s achievable now and what people ask for is that certain changes will cause disconnect which is expected. Example: change of bridge MAC address while administrator is using MAC-telnet or MAC-winbox to connect. Current implementation will revert the changes made in safe mode while administrator would want to keep the change if he is able to connect using new MAC address within 120 seconds.
I understand that there are workarounds to keep safe mode working and still making changes, but there are different cases each requiring different workaround and it’s not simple to plan to use appropriate workaround in advance.
That is the point..
If you are remotely and make some changes, like move interface into a bridge or something similar, sometime you get disconnected and the safe mode is triggered..
Why just put a timer setting like
Set 5 min make some changes if you made a mistake and get locked in 5 safe mode is trigger and everything is back as before the changes.
Sent from my XT1580 using Tapatalk
Another good example
Why safe mode need to re think
Also
Safe mode sometimes troll you:
You are directly connected making simple changes.
When you go terminal to exit safe mode it tell y that was overwrite by another one and exit sometimes it revert sometime it keeps the changes..
Sent from my XT1580 using Tapatalk
If you lose connection, how do you expect safe mode to remain activated?
Normis,
A simple flap on a interface (wan) cause safe mode to trigger…
So not always a brief loss of connection means that safe mode need to be triggered
Sent from my XT1580 using Tapatalk
.
Maybe if after the user, which started safe mode, gets disconnected … and subsequently connects again before timer expires, the session would actually resume with safe mode activated and all? Possibly the timer would reset to initial value again not to trigger safe mode due to too little time remaining for administrator to manually exit safe mode?
good point
also since when safe mode have a timer ?
YES, YES, YES “raffav” have a 100% right !
UBNT have a good solution with their 120 seconds delay.. why MT can’t have it ?
MikroTik team - please introduce the same at RouterOS. Tahnks.
Although I agree with you and plan my changes with a ‘dual-stack’ mentality to bring things into line - I do get the point the others are trying to make. Sometimes the changes you need to make affect your connectivity to the device, you want to make those changes but if the changes dont work you are locked out - perfect for safe mode. Problem being that you make those changes with safe mode on, your session disconnects as expected, then the config reverts to old so you either cant apply new config - or have to apply new config and hope that it works without a safeguard.
Being able to set a safe mode / commit timer means you can turn on- make the change - lose your connection - re-connect and confirm all-ok to stop the revert.
It could certainly be handy in some situations for remote devices.
It doesn’t have it now. We’re trying to convince Normis that it’s a good idea to introduce one. 
Anything happened here?
I am relatively new to Mikrotik, and are used to a system with Save and Activate as two independent choices. Combined with ping watchdog I was able to move a client from one AP to another, and be absolutely sure that if I did something wrong, or the client didn’t connect with the new AP - it would come back to the old AP in a few minutes. Saved me many truckrolls. Surprised something similar is not implemented in RouterOS, with so many other great features for a WISP? Or am I missing something?
+1 MODE time based
Do not be instant undo!
Wait 180 second after the connection loss!!!
I can see the point. Sometimes when you perform a change, maybe a routing-change or vlan-change. The break of the TCP-connection is expected, however it’s reachable via another IP, then a timeout-based rollback would be prefered.
I have sometime solved it with a scheduled job - if it didn’t work, then reverse the changes after some minutes.