froztbyte.getBlog()

Particularly, your shitty scripting interface.

Using a lot of Mikrotik routers in various places, I’ve grown accustomed to the platform, and it really is quite flexible. However, it has its idiosyncracies. Among them are bugs and regressions between versions (c’mon guys, can you at least get some functional testing in place?), inconsistencies/inabilities in how some things are done at protocol level (unable to forward a default route in BGP), those sort of things. Now before I continue, let me say that I understand how such things can happen, but I do feel annoyed that they can take that long to get resolved. The lack of automated functional testing is also a major bugbear.

So, you have a router, and you probably care about its config. Most people who do this are familiar with the tool rancid (for better or worse – maybe at some point ranrod will be usable), and there are a set of patches to support mikrotik devices over here. As a side effect of this toolchain, I have a set of method that I can use to log in on many devices with a relatively low-effort command method. Consider the following scenario: someone leaves a company, and you wish to update passwords (in the case where you don’t have don’t have tacacs or radius backing auth). On a unix-like system, you have a few options, but in router-/switch-land you’re limited to some other things. Not to worry, we have shell loops, clogin/mtlogin, and a bit of ingenuity! Leading us to make this:

for location in list some locations here; do
  grep 'mikrotik.*up$' "$location/router.db"; done | cut -d':' -f 1 | while read line; do
  mtlogin -c ':global users;
              :foreach i in=[/user find where name="userinquestion"] do={:set users ($users . "," $i);};
              /user set numbers=$users password=shinymoonbicycles; quit' $line;
done

Seems sane enough. Start a for loop, parse our router.db files for a list of routers we care about, loop through those and run the following automated command sequence. Low-effort, quick, gets it all done. Except it runs into this issue:

[automation@Brain] > can't read "users": no such variable

Argh. Apparently we can’t declare or use variables in this fashion. Even though I can do that perfectly okay when I’m logged into an interactive session (…how is this determined?). “But hold on,” I think, “rancid uses +ct in the username to skip colour and terminal detection; maybe I can disable that to get it done”. And no, you can’t. QQ

In my mind, this sort of thing, on top of the earlier listed problems, the utter silliness of the scripting language (really, go look at the way I have to construct a list of users, or, well, anything), and other things such as no clear equivalent of the cisco-alike “no” command that can be used to negate/remove any statement in the config, are among the things that stand in the way of Mikrotik being taken more seriously.

Mikrotik, you have a product with pretty good potential. It wouldn’t hurt to improve these things a bit. You can sell craploads of non-wifi CPE equipment if you could win over the Cisco-hearts. Please, fix this crap.

*publishes post and mails the link to Mikrotik support*