The problem is that the plugin name is prefixed with a registry name.
So, if the plugin is fetched from Docker Store, its name will be
"store/weaveworks/net-plugin".
The detection function does an exact match on "weaveworks/net-plugin",
so in the Docker Store case, the presence of the plugin cannot be
detected.
New behaviour in Docker 1.12 means it disregards a plugin-supplied
address pool that overlaps an existing route, which causes a hang as
noted in #2469. When we pass in the subnet, Docker believes we really
do want that address range and avoids the hang.
Now it's off by default, and there is an option to enable the
multicast route per-network.
We turn it on for the `weave` network created when we start the plugin.
Note that we remove the ability to set the weavemesh network name, or
disabling it altogether. This was always poorly support, since the
removal operation only ever operated on the default name. The option
was also not listed in the usage, though it was in the docs.
Bryan Boreham