Don't assume that utilities such as systemctl or initctl is found in a certain
specific path. Instead look for them in $PATH. This applies to both the
Makefile and the NetworkManager dispatcher script.
Resolves#11.
The three I-Ds that describe SIIT-DC and SIIT-EAM have been published as
RFCs, so update the references accordingly. Also update once occurrence
of old terminology ("Host Agent") with the new and final one ("Edge
Relay").
Change "2014-2015" with "2014-2016". Also, I had forgotten to update the
licence comment in the clatd script itself in b5725c0, so fix that too.
Thanks to @ingvarha for noticing!
Just pass the entire supplied command line, be it a single scalar or an array,
to system(). It'll do the right thing with it. This gets rid of a spurious
trailing space in debugging output when cmd() was called with a single scalar
as the command argument (leaving @cmdline undefined).
This ensures that TCP connections terminated through the CLAT gets a sensible
TCP MSS value negotiated. By default, the value is set to the MTU of the
defaultroute minus 40. There should be no reason to change this in the vast
majority of cases, but it can be overridden with the "v4-defaultroute-advmss"
setting.
Adds "v4-defaultroute-replace" config/command-line setting (default disabled).
When enabled, it will unconditionally disable the pre-flight IPv4 connectivity
check, and ensure that any pre-existing IPv4 default routes are removed during
startup (and presumably replaced with the one pointing to the CLAT, unless
"v4-defaultroute-enable" has been disabled). Any IPv4 default routes that were
removed in this manner are restored when clatd is shutting down.
Newer NetworkManager versions will run the dispatcher scripts when new
unknown interfaces show up, including 'clat'. That will cause a clatd
restart right after startup, and we'll never get to fully initialise. So
ensure the dispatcher script does nothing if the device in question is
our own 'clat' to prevent this.
This allows clatd to work correctly on 3GPP mobile networks, where the
IID is assigned from the network, rather than being generated using
EUI-64. We still prefer the old method, though, the random one is only
used if no EUI-64 address exists on the PLAT device. Update docs
accordingly.
Also upgrade docs to better describe usage as a SIIT-DC Host Agent.
get_clat_v6_addr() didn't actually check if it saw any Modified EUI-64
based addresses on the PLAT device before proceeding. This caused it to
return a bogus CLAT address (::c1:a700:0) instead of failing with a
useful error message.
In the case of there being more than one EUI-64 based IPv6 address on
the PLAT device, clatd will now pick the one which share the longest
common prefix length with the PLAT prefix when deciding which one to
base the auto-generated CLAT IPv6 address on. This should avoid
accidentally ending up with a ULA-based CLAT IPv6 address when better
alternatives exist.
Resolves#1.
