I don't think automatic updates would be as disruptive as you think.

And having the ability to disable them and apply updates manually, combined with some forewarning like you are talking about (an email that says your router will restart tomorrow at 3am unless you do it sooner), would go a really long way.

A lot of Mikrotik's are installed at WISP's and other ISP's... making unplanned reboots very disruptive.

Those of us using them on our corporate networks might be inconvenienced by a temporary outage, but that's unlikely at 3am... however, scheduling and doing these manually is still the best way for enterprise gear.

I doubt that most ISPs who can't be bothered to apply security updates are going to notice a 5 minute reboot.

Split the difference - email the user that an update will apply on $date unless they do it first, or if they delay it (and don't let them delay it indefinitely).

You can already script something like this into RouterOS (Mikrotik's OS).

Good - they should make it the default!

Don't forget that a lot of the customer base for Mikrotik is in remote locations (ie: P2P connections in rural areas) or small ISPs. Having the router in your office die on you (even during office hours) is a little different than all your customers call you the same day their only internet connection is gone.

I used to be a customer of a remote WISP, P2P in a rural area.

I can't speak for all WISP's, but we only had service about 12 hours a day, less if it was raining. Five minutes to reboot a router would have been invisible.

I used to contract with a WISP. I would regularly get calls to "reboot the router" from the owner. The "router" was a fiber switch at their CO. I would just do it when they asked. I wasn't a customer nor did I get paid enough to fix their network. Sorry if that was your connection. :)

ISPs would just have to disable it before installing the router. Still seems like a good default.

> An "automatic" update that would potentially cause the router to reboot and bring down the network would go over very poorly with customers, even if it happens at 3 AM.

Maybe the the trigger for the automatic reboot could be more complicated than just a time-based trigger. Something like

    Reboot when
        localtime > 2AM & 
        localtime < 5AM & 
        traffic averaged over the last 5 min < 5kbs

Basically reboot unless the router detects the network is being used actively.

Of course, if you're on vacation and relying on that router to be available for security cameras, an automatic firmware update that results in a bricked router can be more than a little disruptive.

It's a tradeoff. You have to balance that negative against the negative of having botnets of millions of never-patched routers.

Automatic updates should be the default, but you should be able to shut them off if you want to make a different tradeoff.

Automatic security updates should be the default, all other updates should absolutely not. In case of patching routers there isn't much crapware to be upsold, but in general, if we're ever going to develop some code of ethics in this industry, I wish a part of it would be a rule of hard separation between security patches and feature updates, and another rule that the latter should never be done automatically without explicit opt-in.

Yes, it's extra work for developers, but the result of not doing that is the present situation - a lot of users, including a surprisingly large population of non-tech-savvy people, will go out of their way to shut down automatic updates, to avoid having to deal with broken workflows, upselling, ads sneaking in, and forced reboots in the middle of a business presentation or a game (or a surgery).

Automatic updates has some of the same issues as telemetry. Windows Update for example has to send information on things like drivers to scan for updates.

An update shouldn't brick a well built router; that's what watchdogs and secondary flash is for.

What about links that need to be available for failover or during emergencies? What about organizations that operate at those hours? I used to work at a 24 hour retail chain, and some stores in mining towns had their busiest hours around 4AM as busloads of miners came in to shop before the day started. We could _never_ upgrade those stores in the early morning hours.

So you're saying the defaults should be setup for the unusual use cases like you describe, even if that means we get botnets of millions of routers?

You're not going to define one set of secure-by-default rules that's going to work for everyone. Rather, you want to try to define a set of secure-by-default rules that work for most people. Then but the burden of reconfiguration and maintenance on those with unusual needs, rather than the majority.

Mikrotik's aren't really consumer-grade hardware (most Mikrotik's that is). Some operators deliberately stay a version or so back off the latest due to features breaking or instability, or requiring configuration changes, etc.

Automatic updating could be crippling to ISP operators (Mikrotik's are very popular with WISP's, and other smaller ISP operators).

> Basically reboot unless the router detects the network is being used actively.

For the average Mikrotik router, deployed at some WISP or small ISP, that's unlikely to happen.

You would only need to reboot if the kernel got updated. Otherwise just restart the affected services.

And kernel updates can be made faster with kexec so you don't have to reinitialize the hardware. The flashing procedure itself could also be made interruption-free with dual flash, which most sytems have anyway to avoid bricking the system.

It would take some effort to make it fast, but I think the update interruption could be brought down to the second-range. You'd still lose NAT state but that would only affect long-lasting sessions like SSH.