d198119e

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Catch the address that took the network down, and stop the tool lying about imports

Deploying this configuration left the router working and everything behind
it without IPv6. The line was

    /ipv6 address
    add from-pool=v6pool interface=lan

which takes no address in particular and so takes ::, the subnet-router
anycast address. Every IPv6 router on a link has to answer for that one,
so claiming it fails duplicate address detection and the interface is left
with no valid address at all. It had worked for months because a router
that already holds an address never runs detection again; the first reset
is where it surfaces. So: a new problem, subnet-router-anycast, which
fires on that exact line of the configuration that broke.

Two things in the tool that made the failure worse than it was.

The readiness check was a tcp connection to port 22. RouterOS listens well
before it will authenticate, so the deployment declared the router back and
then failed at the next step with an authentication error. There is now a
 command that retries the whole connect-authenticate-run-a-command
path, over the same code an import uses, and the deployment waits on that.

The import decided whether it had worked by grepping the output for a
phrase, and RouterOS prints nothing at all about an import run over ssh
even though the same command on a console prints every line. So a
successful import was reported as a failure, with the words "Nothing in it
has been applied", which the code had no way to know and which was false.
It reads the exit status now, and when it does fail it says that how much
was applied is not something it can tell.

A failed second stage now prints the command that finishes it.