| Age | Commit message (Collapse) | Author |
|---|
|
This is a continuation of the previous include sort patch, which
only sorted for .c files.
|
|
This ensures that several DHCPv6 clients can run on separate interfaces
simultaneously.
|
|
This is managed by the kernel, but we should track whether or not we have
a configured IPv6LL address. This fixes two issues:
- we now wait for IPv6LL before considering the link ready
- we now wait for IPv6LL before attempting to do NDisc or DHCPv6
these protocols relies on an LL address being available.
|
|
Router Discovery is a core part of IPv6, which by default is handled by the kernel.
However, the kernel implementation is meant as a fall-back, and to fully support
the protocol a userspace implementation is desired.
The protocol essentially listens for Router Advertisement packets from routers
on the local link and use these to configure the client automatically. The four
main pieces of information are: what kind (if any) of DHCPv6 configuration should
be performed; a default gateway; the prefixes that should be considered to be on
the local link; and the prefixes with which we can preform SLAAC in order to pick
a global IPv6 address.
A lot of additional information is also available, which we do not yet fully
support, but which will eventually allow us to avoid the need for DHCPv6 in the
common case.
Short-term, the reason for wanting this is in userspace was the desire to fully
track all the addresses on links we manage, and that is not possible for addresses
managed by the kernel (as the kernel does not expose to us the fact that it
manages these addresses). Moreover, we would like to support stable privacy
addresses, which will soon be mandated and the legacy MAC-based global addresses
deprecated, to do this well we need to handle the generation in userspace. Lastly,
more long-term we wish to support more RA options than what the kernel exposes.
|
|
The previous behavior:
When DHCPv6 was enabled, router discover was performed first, and then DHCPv6 was
enabled only if the relevant flags were passed in the Router Advertisement message.
Moreover, router discovery was performed even if AcceptRouterAdvertisements=false,
moreover, even if router advertisements were accepted (by the kernel) the flags
indicating that DHCPv6 should be performed were ignored.
New behavior:
If RouterAdvertisements are accepted, and either no routers are found, or an
advertisement is received indicating DHCPv6 should be performed, the DHCPv6
client is started. Moreover, the DHCP option now truly enables the DHCPv6
client regardless of router discovery (though it will probably not be
very useful to get a lease withotu any routes, this seems the more consistent
approach).
The recommended default setting should be to set DHCP=ipv4 and to leave
IPv6AcceptRouterAdvertisements unset.
|
|
Enabling address acquisition, configuring the client and starting the client are now
split out. This to better handle the client being repeatedly enabled due to router
advertisements.
|
|
|
|
string-util.[ch]
There are more than enough calls doing string manipulations to deserve
its own files, hence do something about it.
This patch also sorts the #include blocks of all files that needed to be
updated, according to the sorting suggestions from CODING_STYLE. Since
pretty much every file needs our string manipulation functions this
effectively means that most files have sorted #include blocks now.
Also touches a few unrelated include files.
|
|
This ressurects 47d45d3cde45d6545367570264e4e3636bc9e345. We now always use /128 prefixes,
so there is no need for the DHCPv6 code to know about prefixes expiring.
|
|
|
|
|
|
|
|
The actual code rename will follow. The reason for the change of name is to make it
simpler and more uniform with how we name other libraries (we don't include the
underlying protocol). The new name also matches the naming in the kernel (which
is particularly relevent here as we expect to let the kernel do some parts of
the protocol and we do others).
|
|
Every time the state is written out we may trigger third-party apps, so
let's be a bit more careful about writing this out unnecessarily.
|
|
We only keep the addresses that we added ourselves in link->addresses, and
introduce a new set link->addresses_foreign to keep addresses of unknown
origin.
Only functional change is that "foreign" addresses no longer prevent a link
from entering "configured" state.
|
|
We were considering a link configured whilst its IPv6 addresses were still
tentative.
Fixes issue #650.
|
|
No need to expose these functions, but rather call them from address_{add,drop}.
|
|
We need to be able to look these things up quickly as we will be updating them
continuously and there can in principle be many of them.
|
|
|
|
Wait until DHCPv6 has acquired an address before announcing the link
to be configured. Log the DHCPv6 lease lost event.
|
|
No functional changes, just moving definitions into separate header
files.
|
|
|
|
|
|
This changes log_unit_info() (and friends) to take a real Unit* object
insted of just a unit name as parameter. The call will now prefix all
logged messages with the unit name, thus allowing the unit name to be
dropped from the various passed romat strings, simplifying invocations
drastically, and unifying log output across messages. Also, UNIT= vs.
USER_UNIT= is now derived from the Manager object attached to the Unit
object, instead of getpid(). This has the benefit of correcting the
field for --test runs.
Also contains a couple of other logging improvements:
- Drops a couple of strerror() invocations in favour of using %m.
- Not only .mount units now warn if a symlinks exist for the mount
point already, .automount units do that too, now.
- A few invocations of log_struct() that didn't actually pass any
additional structured data have been replaced by simpler invocations
of log_unit_info() and friends.
- For structured data a new LOG_UNIT_MESSAGE() macro has been added,
that works like LOG_MESSAGE() but prefixes the message with the unit
name. Similar, there's now LOG_LINK_MESSAGE() and
LOG_NETDEV_MESSAGE().
- For structured data new LOG_UNIT_ID(), LOG_LINK_INTERFACE(),
LOG_NETDEV_INTERFACE() macros have been added that generate the
necessary per object fields. The old log_unit_struct() call has been
removed in favour of these new macros used in raw log_struct()
invocations. In addition to removing one more function call this
allows generated structured log messages that contain two object
fields, as necessary for example for network interfaces that are
joined into another network interface, and whose messages shall be
indexed by both.
- The LOG_ERRNO() macro has been removed, in favour of
log_struct_errno(). The latter has the benefit of ensuring that %m in
format strings is properly resolved to the specified error number.
- A number of logging messages have been converted to use
log_unit_info() instead of log_info()
- The client code in sysv-generator no longer #includes core code from
src/core/.
- log_unit_full_errno() has been removed, log_unit_full() instead takes
an errno now, too.
- log_unit_info(), log_link_info(), log_netdev_info() and friends, now
avoid double evaluation of their parameters
|
|
When setting IPv6 addresses acquired by DHCPv6, systemd-networkd sets
the IFA_F_NOPREFIXROUTE flag in the IFA_FLAGS netlink attribute. As
the flag and the attribute are present starting with Linux 3.14, older
kernels will need systemd-network to manage prefix route expiry.
By default, DHCPv6 addresses are first assigned setting the
IFA_F_NOPREFIXROUTE flag in the IFA_FLAGS netlink attribute. Should
the address assignment fail, the same assignment is tried without
the IFA_FLAGS attribute. Should also the second attempt fail, an error
is printed and address assignment ends with failure. As successful use
of the IFA_FLAGS netlink attribute is recorded in the Link structure,
the DHCPv6 code will know if the kernel or systemd-network fallback
code handles expiring prefixes.
The prefix expiration and IPv6 address updating fallback code is
resurrected from the parts deleted with commit
47d45d3cde45d6545367570264e4e3636bc9e345.
This patch can be removed once the minimum kernel requirements are
greater than or equal to 3.14.
|
|
Introduce BindCarrier= to indicate the set of links that determine if
the current link should be brought UP or DOWN.
[tomegun: add a bit to commit message]
|
|
On Tue, Feb 10, 2015 at 08:10:43PM +0100, Lennart Poettering wrote:
> Hmm, I think it would be nicer to use be32toh() here instead, since it
> ensures the macro is (to a limited degree) typesafe.
>
> Any chance you could rework that?
From: Paul Martin <paul.martin@codethink.co.uk>
Date: Wed, 11 Feb 2015 11:47:16 +0000
Subject: [PATCH] networkd dhcpv4 logging endian fix
On a big-endian host, systemd-networkd prints out IPv4 network
addresses byte reversed:
Feb 10 16:43:32 hostname systemd-networkd[151]: eth0 : DHCPv4 address 158.1.24.10/16 via 1.1.24.10
The address obtained is 10.24.1.158/16 and the route is
10.24.0.0/16 dev eth0 src 10.24.1.187
The macro ADDRESS_FMT_VAL() unpacks a "struct in_addr" in a
little-endian specific manner.
This patch forces the passed address into host order, then unpacks it.
On an x86 later than i486, compiled with -O2, the only extra overhead
is a single bswap instruction.
|
|
This allows both IPv4 and IPv6 link-local addresses to be enabled or disabled. By default
we still enable IPv6LL and disable IPv4LL. The old config option is kept for backwards
compatibility, but removed from the documentation.
|
|
We will be woken up on rtnl or dbus activity, so let's just quit if some time has passed and that is the only thing that can happen.
Note that we will always stay around if we expect network activity (e.g. DHCP is enabled), as we are not restarted on that.
|
|
Only the very basics, more to come.
For now:
$ busctl tree org.freedesktop.network1
└─/org/freedesktop/network1
└─/org/freedesktop/network1/link
├─/org/freedesktop/network1/link/1
├─/org/freedesktop/network1/link/2
├─/org/freedesktop/network1/link/3
├─/org/freedesktop/network1/link/4
├─/org/freedesktop/network1/link/5
├─/org/freedesktop/network1/link/6
├─/org/freedesktop/network1/link/7
├─/org/freedesktop/network1/link/8
└─/org/freedesktop/network1/link/9
$ busctl introspect org.freedesktop.network1 /org/freedesktop/network1
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.network1.Manager interface - - -
.OperationalState property s "carrier" emits-change
$ busctl introspect org.freedesktop.network1 /org/freedesktop/network1/link/1
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.network1.Link interface - - -
.AdministrativeState property s "unmanaged" emits-change
.OperationalState property s "carrier" emits-change
|
|
|
|
|
|
This patch integrates LLDP with networkd.
Example conf:
file : lldp.network
[Match]
Name=em1
[Network]
LLDP=yes
|
|
Handle all aspects of ICMPv6 and DHCPv6 in a file of its own as is done
with DHCPv4 and IPv4LL.
|
|
The kernel always returns all addresses, rather than only for the given link, so let's only enumerate once.
|
|
rest of the code
|
|
- Rename log_meta() → log_internal(), to follow naming scheme of most
other log functions that are usually invoked through macros, but never
directly.
- Rename log_info_object() to log_object_info(), simply because the
object should be before any other parameters, to follow OO-style
programming style.
|
|
log_error_errno() as log calls that take error numbers
This change has two benefits:
- The format string %m will now resolve to the specified error (or to
errno if the specified error is 0. This allows getting rid of a ton of
strerror() invocations, a function that is not thread-safe.
- The specified error can be passed to the journal in the ERRNO= field.
Now of course, we just need somebody to convert all cases of this:
log_error("Something happened: %s", strerror(-r));
into thus:
log_error_errno(-r, "Something happened: %m");
|
|
link_update()
This allows us also to simplify link_has_carrier() a bit.
|
|
Suggested by Lennart and Kay.
|
|
This is the state when we are waiting for udev to initialize the device, and waiting for
libudev and rtnl to be in sync. In the future we probably will also be waiting for nl80211.
At this point we do not yet have enough information to know whether or not networkd should
be handling the device.
|
|
|
|
|
|
|
|
|
