interfaces: generalise the dhcp6c_script using the new IFNAME variable
The file was conceptually created in d36f0f4f62557 and before was a single
command line script... so add appropriate copyrights from that time onward.
Many thanks to Martin for pinoeering this back in the day!
interface: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
Add two debugging files which still need to be steered via the
debug setting.
interaces: use ifctl -u mode to check if force is needed #9521
We do force-reload in SOLICIT/REQUEST, but in REBIND and RENEW
cases we do want to check if the prefix information changed.
This may produce one spurious forced renew when the old prefix
disappears, but avoids reloading in average cases where the
existing prefix is (or existing prefixes are) kept.
interaces: use ifctl -u mode to check if force is needed #9521
We do force-reload in SOLICIT/REQUEST, but in REBIND and RENEW
cases we do want to check if the prefix information changed.
This may produce one spurious forced renew when the old prefix
disappears, but avoids reloading in average cases where the
existing prefix is (or existing prefixes are) kept.
interaces: use ifctl -u mode to check if force is needed #9521
We do force-reload in SOLICIT/REQUEST, but in REBIND and RENEW
cases we do want to check if the prefix information changed.
This may produce one spurious forced renew when the old prefix
disappears, but avoids reloading in average cases where the
existing prefix is (or existing prefixes are) kept.
interaces: use ifctl -u mode to check if force is needed #9521
We do force-reload in SOLICIT/REQUEST, but in REBIND and RENEW
cases we do want to check if the prefix information changed.
This may produce one spurious forced renew when the old prefix
disappears, but avoids reloading in average cases where the
existing prefix is (or existing prefixes are) kept.
interface: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
Add two debugging files which still need to be steered via the
debug setting.
interface: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
dhcrelay: relax the check for present addresses #9369
get_interface_ip(v6) is much too specific for what we're trying to
validate against here. Instead use the existing ifconfig data and
simply make sure if any address from the family is set. In the IPv6
link-local case that might be strange, but the effect on working
setups is zero in either case.
It could be considered removing this validation which originates from
the legacy code and just let the daemon fail to start, but the log
message is much nicer and effective for debugging purposes.
interface: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
interfaces: add a workaround for one-time sefgault in hostwatch
Seen this during testing but it's hard to debug in that post-update state
during bootup. In principle nothin g even changed between "50" and "90".
(cherry picked from commit b75dccbf599cefb1ec90516057afdf3815169c46)
interfaces: add a workaround for one-time sefgault in hostwatch
Seen this during testing but it's hard to debug in that post-update state
during bootup. In principle nothin g even changed between "50" and "90".
interfaces: get hostwatch status by process name
The PID takes a few ms to materialize, long enough for an apply to
show the service as red while still restarting.
The issue is reproducible via:
# service hostwatch restart && service hostwatch status
It shows the service as stopped.
(cherry picked from commit 55f34d8feb7a1b2b9af1e24ed46e6029fdaf3455)
interfaces: get hostwatch status by process name
The PID takes a few ms to materialize, long enough for an apply to
show the service as red while still restarting.
The issue is reproducible via:
# service hostwatch restart && service hostwatch status
It shows the service as stopped.
