In some circumstances, the hello_protocol attribute could get modified
on the wrong peer, which would raise an AttributeError.
On reception of seqno 1 from a peer with protocol < 7, protocol could be
equal to zero which would cause handleHello to not return True, causing
the handshake to fail.

This commit concerns networks that use the --same-country option.
We recently discovered that the IP geolocation database contains
incorrect entries. To work around this, the protocol needs to be
changed by adding the country as 4th field in addresses (the first 3
are: ip, port, protocol) and the new --country option allows a node
to announce a country that differs from the one the GeoIP DB.

Thanks to the previous commits it's possible to implement backward
compatibility, by not sending the 4th field (country) to nodes that
can't parse it. Of course, these old nodes would continue to not
create appropriate tunnels and after a while, the administrator of
the network may decide to increase registry's --min-protocol (7).

In a network with only nodes that implement this last version of the
protocol, the nodes may only use the GeoIP DB to resolve their own IPs.

See merge request !27

There is a need to be able to extend the protocol without breaking
compatibility with old nodes. This is done by sending version.protocol
during inter-node handshake, in seqno 1 and seqno 2, so that a node
knows what version the peers speak and use appropriate format.

This is implemented with partial backward compatibility: handshake with
an old node succeeds when the new node does not have to send seqno 1.

Behaviour changed in commit 5a8e4186.

On machines using systemd, services were not enabled by default.

To reenable RTT-based metric, we usually want to force old nodes
to upgrade, so that they don't always look faster that others.

This reenables RTT-based metric, which
was disabled since we moved to v1.8+.

See commit 5a8e4186.

Commit 40d4e496 is not reverted
because Python 3 will also require to keep the distinction between
blob and text.

This feature was mainly for laptops but users:
- often don't care having the daemon running all the time;
- may not want to use the 'main-interface' option because the interface that
  provides internet access is not always the same, e.g. wifi & wired;
- may want other kinds of conditions,
  e.g. only specific wifi access points.

So in practice, main-interface is currently only use to set up a DHCP server or
provide IPv6 autoconfiguration. For such case, it is preferred to start/stop
re6stnet like a normal service.

This should fix strange bugs after running the demo for a long time,
with certificate renewal happening every few minutes.

The previous commit, which adds --ipv6, has the issue
that it does not check whether given IPs are valid.
Since IPv4 & IPv6 use completely different address
representation, --ip can be used for both.

When re6st attempts to use UPnP and IPv6 is enabled at the same time,
the external IPv4 was published for IPv6 protocols.
For example, machine6 in the demo had:
  10.0.1.3,1194,tcp;10.0.1.3,1194,udp;10.0.1.3,1195,udp6

This caused re6stnet to crash (socket.gaierror) if GEOIP2_MMDB is set.

With this commit, IPv4 & IPv6 are now processed independently.

/reviewed-on !21

/reviewed-on nexedi/re6stnet!19

The detection of the attribute `_private` was performed on a string
object representing the name of the method instead of the method itself,
leading to the registry allowing anyone to call private methods.

The purpose is to check that HMAC prevents routes from being exchanged
between the 2 networks. This happened when 2 nodes of 2 different re6st
networks are in the same LAN, and it caused many issues.

/reviewed-on !15

This reverts commit 24fea8cd.

The client up hook is required when IPv4 is not enabled.

HMAC is added in babel call to prevent babel communication between nodes of different re6st networks. 
This solves the problem of machines in different re6st networks but on the same LAN that exchange routes through babel. 
The key used to authenticate packets is randomly created on 16 bytes by the registry and sent to nodes when they fetch network parameters. 
This uses the WIP hmac branch of jech/babeld with Nexedi patches and the added possibility to not check HMAC in incoming packets for better HMAC integration on a HMAC-less network.

/reviewed-on !18

The received network parameter name can have a ':json' suffix that
is not present in the class attribute of this parameter.
This suffix was not removed and could cause attribute deletion to fail.

/reviewed-on !20

In commit d7a4d73f,
this was done only for the init.d script.

/reviewed-on !11

argparse is error-prone in that `action='append'` starts from (a copy of) the
given default when it adds values from command-line, rather than restarting
from an empty list. For example, simply passing `--disable-proto udp` resulted
in ['udp', 'udp6', 'udp'], which caused 'udp6' to remain disabled.

/reviewed-on !17

In commit 06974788,
we increased the --link-mtu value as a temporary way to compensate the
unexplained behaviour change of recent OpenVPN.

This was partly due to encryption, which was enabled despite
`--cipher none`. And it happens that the behaviour of --link-mtu only
changed for the server, with a mysterious difference of 93 bytes.

Hence the workaround to get identical tunnel MTU on both sides.

/reviewed-on !13

The fix to mark an interface as "up" and indicate its MTU was
useful for machines with a single client, because OpenVPN would fail
to configure them this way in OpenVPN 2.3. It has been fixed in 2.4
so the fix has been removed.

/reviewed-on !14

Passing `--cipher none` to OpenVPN is not enough anymore because
clients and servers can still negotiate the algorithm to use for
encryption (by default not empty). We pass the option `--ncp-disable`
to disable cipher negotiation.

/reviewed-on !12

The behaviour of --link-mtu has changed and we increase the values to
at least have interface MTU greater than IPv6 minimum.
We'll see later to have even greater values in ovpn_link_mtu_dict
(so that the resulting MTU is closer to what we had with 2.3)
or review the whole MTU part completely.

The main goal of this is to check if we should keep supporting
older distributions.

/reviewed-on !9

See "./demo --help" for more information.

/reviewed-on !8