RouterOS Netinstall Server

RouterOS General
1

I wonder if we could get around some of the problems with NetInstall by baking it into RouterOS itself. For those that don’t have a second RouterOS device, an unlicensed CHR might suffice, even with its 1 Mbit/sec data rate limit. That’s still better than the old RS-232 NetInstall method, which continues to be supported, after all.

This idea gets around several fundamental problems with the current NetInstall implementations:


  • Client OS weirdness: MikroTik controls RouterOS top-to-bottom
  • Antimalware interference: Ain’t none such on RouterOS
  • Packet routing weirdness: If any OS can sort out routing issues in that delicate time where the target device doesn’t have a proper IP configuration yet, it’s RouterOS
  • Timing issues: Some have blamed interfaces coming up and down due to Ethernet carrier reestablishment shortly after reboot and such, but if anyone can work such details out, it’s MikroTik
  • Temporary static IP: When NetInstall is self-hosted, RouterOS can add an IP in the 192.168.88.x space itself, rather than make the user do it manually
  • Package selection: Rather than make the user select NPKs, the default should be “set the other router to my running version”. Only if the user wants to upgrade the remote router to some other version do they need to upload separate NPKs

I’m thinking the process works like this: WinBox → Tools → NetInstall → wait for other box to come up → click Reinstall.

Bink, bonk, done.

2

Nice, I hope to do that with containers when supported again,
but is better if is direcly inside RouterOS (WHY NOT???!!!).
Obviously just some dummy person think to use a SMIPS device to host netinstall-6.48.6-smips.npk …

3

Sure… But something like netinstall should only be needed on very rare occasions. Upgrade process needs to be more reliable than it is (especially for v7). Adding netinstall servers all over the place is like an admission or promotional advertisement from Mikrotik that it should be an everyday used function. I’m not saying this feature is a bad idea (on the contrary) I’m just coming back to the argument that getting important stability bug fixes and other urgent new features to v7 should remain priority focus right now. Besides, like rextended has pointed out, this could probably be implemented as a container add-on, right? And Mikrotik always argues about limited nand resources and the need to be very selective when weighing/deciding which new requested features to add.. So let’s bring back container support for a start so these types of great ideas can start to become a reality. If a remote netinstall procedure could become a possibility, then this idea would have my full support for some sites where there are no windows/Linux machines for instance. Just yesterday I bricked an rb433 remotely by doing nothing but performing an innocent inplace upgrade from v7.3beta33 to v7.3beta34. built-in netinstall can’t help me even if it existed and I had 2 routers on site. I still need to arrange someone to press a reset button… Surely the board can me made to be more resilient in such a state. If normal bootup fails (kernel crash or something) then go straight to BOOTP or easier recovery (at least for some time before retrying), or something like this? Then another router on site acting as a netinstall server could prove very useful indeed

4

Hi,
I would love this idea, but only as an extra package optionally selectable. On 16Mb, we are already experiencing a lot of issues.
But to be honest just making the interface selectable in the “desktop” version, would be easier and sufficient.
BR
W

5

Certainly, but when you need it, you need it bad. Having it fail on you in your time of trouble is super-frustrating. The last time I had to resort to it, it required two hours of futzing about, including driving an hour round-trip to fetch a spare Windows box to dedicate to the matter. Bleah.


Adding netinstall servers all over the place is like an admission or promotional advertisement from Mikrotik that it should be an everyday used function.

I suggested putting it under Tools in Winbox. There’s not a single thing under there I use every day. It’s the OS’s junk drawer: where you go for the rare thing you almost never need, but which needs to be there when you need it.


this could probably be implemented as a container add-on, right?

A container would get you part of the way, but by their nature, they can’t reach out and change how the host OS does things. (If they could, they wouldn’t “contain” things very well, would they?) I’m thinking of temporary dynamic routing table updates to ensure that the 192.168.88.x temporary IP traffic gets back to NetInstall, for instance.


limited nand resources

The current Linux netinstall binary is 48 MiB, unpacked, and it’s a statically-linked executable. If it shared the rest of the OS’s dynamic libraries, it’d be smaller. Maybe even a lot smaller.

Still, I don’t oppose making it a package. There’s not much point in pressing every little mAP they sell into service as a potential NetInstall server. It’s more of a core function, implying a bigger box.

That said, dedicating a cheap RouterOS box to NetInstall makes more sense than dedicating a spare Windows box to it, as the current long list of configuration instructions encourages. Who wants to do all of that even once, much less undo it to get one’s main machine back in action, only to do it again later the next time you need NetInstall? If it’s that or spend $40 on a hEX Lite that does nothing else, I’m sure there are those that would happily do that.


remote netinstall…arrange someone to press a reset button

That sounds like a security nightmare. How would you prevent randos from uploading firmware of their choice? There’s a good reason for the current reset button dance.

Your idea of automatic BOOTP when it detects a boot loop or similar is a tentative “maybe” in my book. I worry that it’d be too easy to force it into that state remotely, such as through a weak configuration, as we see with all this botnet takeover stuff. Replacing the firmware should most definitely be under strict control.

6

Do you mean the network interface, to get around the problem of NetInstall not seeing the target box due to routing table trouble? If so, I’m not aware of a portable method.

In fact, the only one I’m aware of at all is Linux-specific.

For Windows, the best idea I have is to strap an integrated BSD sockets stack to WinPCap. I wouldn’t gamble on which is tougher, that or getting NetInstall working on RouterOS with the necessary WinBox GUI support code, but I do know which one would be more reliable. :slight_smile:

7

Well I have no idea about the specifics of a Windows solution for defining an interface. Still from my perspective (user), this is what I find always problematic with Netinstall.
Anyway, if the integrated Netinstall won´t use up the space needed for the new WPA3 implementation on my mAP Lite, I would be fully satisfied with that too. :slight_smile:
W