Instead of overwriting constructed(), update the s390 subchannels via
realize_start_notify(). This makes more sense and is also more similar
to what other device implementations do.
All implementations of link_changed() chain up to NMDevice's
base implementation. Thus, everybody wants to set the carrier.
Refactor the code to set the carrier outside of link_changed().
Instead of creating a GSList use an array. That way, we save
the allocation and free of an GSList instance. Also, avoid
cloning the export path. It is stable.
This usually indicates that the driver missed beacons from the AP, due to driver bugs
or faulty power-save management. It doesn't mean that the PSK is wrong.
Previously, we would require a @self argument and the @call_id in
nm_act_request_cancel_secrets(), although the @call_id already has
a pointer to @self.
In principle that is not necessary, but it makes the API a bit
more robust as you need to care about the lifetime of the @req
as well.
However it is a bit inconvenient, because it requires that caller to
track both the activation request and the call-id.
Now, allow nm_act_request_get_secrets() to instruct the call-id to
take an additional reference to @self. Later on, we would allow to omit
the argument during cancelling. We only allow this, if the call-id
takes a reference to @self.
The ioctl APIs ethtool/mii require an interface ifname. That is inherrently
racy as interfaces can be renamed. This cannot be fixed, we can only
minimize the time between verifying the ifname and calling ioctl.
We already had problems with that when ethtool would access an interface
by name that didn't exists. See commit ab41c13b06 .
Checking for an existing interface only helps avoiding races when an interface
gets deleted. It does not help against renaming.
Go one step further, and instead of checking whether such an ifname
exists, try to get the ifname based on the ifindex immediately before
we need it.
This brings an additional overhead for each ethtool access.
Moving the PPP manager to a separate plugin that is loaded when needed
has the advantage of slightly reducing memory footprint and makes it
possible to install the PPP support only where needed.
https://bugzilla.gnome.org/show_bug.cgi?id=773482
This makes it easier to install the files with proper names.
Also, it makes the makefile rules slightly simpler.
Lastly, the documentation is now generated into docs/api, which makes it
possible to get rid of the awkward relative file names in docbook.
Added platform functions to retrieve device link mode status and to
switch from auto to manual link negotiation:
nm_platform_ethtool_get_link_settings
nm_platform_ethtool_set_link_settings
Keep the include paths clean and separate. We use directories to group source
files together. That makes sense (I guess), but then we should use this
grouping also when including files. Thus require to #include files with their
path relative to "src/".
Also, we build various artifacts from the "src/" tree. Instead of having
individual CFLAGS for each artifact in Makefile.am, the CFLAGS should be
unified. Previously, the CFLAGS for each artifact differ and are inconsistent
in which paths they add to the search path. Fix the inconsistency by just
don't add the paths at all.
With systemd < 219, restarting the journald service closes the stdout
and stderr streams associated with services.
The NM process has SIGPIPE ignored, but g_spawn_sync()/g_spawn_async()
re-enable it and so any child executed with those functions will
terminate by default if it tries to log anything to stdout/stderr.
The teamd instance launched by NM is affected by this problem since it
writes debug messages before actually ignoring SIGPIPE.
To fix this, use the @child_setup callback of g_spawn() to ignore
again SIGPIPE in the child process.
https://bugzilla.redhat.com/show_bug.cgi?id=1393853
Otherwise its path remains visible on D-Bus despite the object is gone,
making libnm sad and grumpy:
libnm-WARNING **: no object known for /org/freedesktop/NetworkManager/AccessPoint/666
On some architectures, it seems we don't properly expose
the symbol of these static variables from NetworkManager
binary.
Just avoid that and don't instead use a static array
inside the device plugin itself.
While at it, make the arrays all const, which possibly allows
the linker to put those symbols in the read-only section.
When the device has an IP interface different from the main one, we
previously took the MTU saved in priv->mtu (which is the MTU initially
set on the underlying interface) and applied it to the IP interface.
This is wrong as it forces the two MTUs to be equal and breaks
connectivity for devices with encapsulation (as PPP). Instead, track
the two MTUs in different variables.
https://bugzilla.redhat.com/show_bug.cgi?id=1385198
It is a bit fragile not to clone the string because we depend on
nm_ip6_config_get_search(priv->ip6_config) to be stable.
In practice, it's no problem. Saves an additional strdup and the
effort to cleanup the memory afterwards.
- only record @now timestamp if we actually need it.
- use gint32 for @now. It seems wrong that NMNDiscDNSServer
uses guint32 for the timestamp. We keep
nm_utils_get_monotonic_timestamp_s() as gint32 for a reason.
- ensure the arrays are initialized to zero. E.g.
ndisc_addr->dad_counter was uninitalized.
- set the size for arrays outside the loop
- use g_array_unref(). I think that is usually better. It makes
only a difference when somebody else holds a reference to the
array. And in that case, it usually seems better not to clear
the array, just release your refrence.
You cannot assume that we are always able to lookup a corresponding
lnk object. In fact, there is no guarantee that link->ifindex still
exists in the platform cache at all.
The compiler warns us when we don't specify all enum values
in a switch(), provided that default: is missing.
Make use of that to get a warning when we add a new tunnel mode.
When an IP-tunnel connection with mode different from the implemented
ones was activated, an assertion failed in tunnel_mode_to_link_type().
Instead we should return NM_LINK_TYPE_UNKNOWN there and fail the
activation.
There's two parts of the configuration involved: the subnet addresses
and the DNS information.
For the addressing, the shared (downlink) device signals the policy needs for a
/64 subnet. When it gets one, it merges it into the autoconf configuration and
forwards to the NDisc. When more prefixes are needed, the (uplink) device asks
the DHCP manager and eventually signals delegation (reception) of a prefix.
The NMDevice only provides the mechanism, the actual subnetting needs to
be done by the NMPolicy.
For the DNS configuration, the shared device just copies it from
whichever device the policy deems suitable.
