| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit 2d1b85f (th/assume-vs-unmanaged-bgo746440), we clearly
distinguish between two modes when encountering devices with external
IP configuration:
a) external devices. For those devices we generate a volatile in-memory
connection and pretend it's active. However, the device must not be
touched by NetworkManager in any way.
b) assume, seamless take over. Mostly for restart of NetworkManager,
we activate a connection gracefully without going through an down-up
cycle. After the device reaches activated state, the device is
considered fully managed. For this only an existing, non volatile
connection can be used.
Before 'th/assume-vs-unmanaged-bgo746440', the behaviors were not
clearly separated.
Since then, we only choose to assume a connection (b) when the state
file indicates a matching connection. Now, extend this to also assume
connections when:
- during first-start (not after a restart) when there is no
state file yet.
- and, if we have an existing, non volatile, connection which
matches the device's configuration.
This patch lets NetworkManager assume connection also on first start.
That is for example useful when handing over network configuration from
initrd.
This only applies to existing, permanent, matching(!) connections, so it is a
good guess that the user wants NM to take over this interface. This brings us
closer to the previous behavior before 'th/assume-vs-unmanaged-bgo746440'.
https://bugzilla.redhat.com/show_bug.cgi?id=1439220
|
| | |
|
| |
|
|
|
|
|
|
|
| |
nm_config_device_state_*() always access the file system directly,
they don't cache data in NMConfig. Hence, they don't use the
@self argument.
Maybe those functions don't belong to nm-config.h, anyway. For lack
of a better place they are there.
|
| |
|
|
|
| |
For _() and N_() we don't have a space before the parenthesis.
Be consistent about that.
|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780277
[thaller@redhat.com: with `make -C po NetworkManager.pot update-po`]
|
| | |
|
| |
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780277
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes: a72ffe230bce1486fcd6bbaea8e111a9e77f33ed
|
| | |
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1398934
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before, setting a device to unmanaged causes it to go down and clear
the interface state.
It may be useful to instruct NetworkManager not to touch the device
anymore but leave the current state up. Changing behavior for
nmcli device set "$DEV" managed no
To get the previous behavior, one has to first disconnect the interface
via
nmcli device disconnect "$DEV"
nmcli device set "$DEV" managed no
Note that non-permanent addresses like from DHCP will eventually time
out because NetworkManager stops the DHCP client. When instructing
NetworkManager to let go of the device, you have to take it over in
any way you see fit.
https://bugzilla.redhat.com/show_bug.cgi?id=1371433
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1440089
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Arguably, we currently only have one instance of NMPlatform,
NMRouteManager, NMDefaultRouteManager -- the one owned by the
NMNetns singleton.
Hence, all these instances we create with "log-with-ptr" set explicitly
to false.
In the future we want to support namespaces, and it will be be common to
have multiple instances. For that we have "log-with-ptr" so we are able
to disambiguiate the logging.
Change the default to TRUE because it makes more sense. It has currently
no effect as the default is never used.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get
the platform singleton instance.
For one, this is a step towards supporting namespaces, where we need
to use different NMNetns/NMPlatform instances depending on in which
namespace the device lives.
Also, we should reduce our use of singletons. They are difficult to
coordinate on shutdown. Instead there should be a clear order of
dependencies, expressed by owning a reference to those singelton
instances. We already own a reference to the platform singelton,
so use it and avoid NM_PLATFORM_GET.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This also ensures that we own a reference to the
NMPlatform, NMRouteManager and NMDefaultRouteManager
instances. See bug rh#1440089 where we might access
the singleton getter after destroing the singleton
instance of NMRouteManager. This is prevented by
keeping a reference to those instances -- indirectly
via the netns instance.
Later, we may add support for multiple namespaces. Then it might
make sense to swap the NMNetns instance of a device when moving
the device between namespaces.
Also, drop the use of singelton instances.
https://bugzilla.redhat.com/show_bug.cgi?id=1440089
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NMPlatform, NMRouteManager and NMDefaultRouteManager are singletons
instances. Users of those are for example NMDevice, which registers
to GObject signals of both NMPlatform and NMRouteManager.
Hence, as NMDevice:dispose() disconnects the signal handlers, it must
ensure that those singleton instances live longer then the NMDevice
instance. That is usually accomplished by having users of singleton
instances own a reference to those instances.
For NMDevice that effectively means that it shall own a reference to
several singletons.
NMPlatform, NMRouteManager, and NMDefaultRouteManager are all
per-namespace. In general it doesn't make sense to have more then
one instances of these per name space. Nnote that currently we don't
support multiple namespaces yet. If we will ever support multiple
namespaces, then a NMDevice would have a reference to all of these
manager instances. Hence, introduce a new class NMNetns which bundles
them together.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set the device state as removed when the link disappears, so that in
the call to unrealize() when the device is unmanaged we also perform a
cleanup of it and especially, we terminate any DHCP client instances
running on the device.
If we keep DHCP clients running, we can hit assertions later when we
start another instance on the same interface, because we kill the old
dhclient from the pidfile, and the g_child_watch_add() done by the
first client instance is not able to waitpid() it, complaining with:
GChildWatchSource: Exit status of a child process was requested but
ECHILD was received by waitpid(). Most likely the process is
ignoring SIGCHLD, or some other thread is invoking waitpid() with a
nonpositive first argument; either behavior can break applications
that use g_child_watch_add()/g_spawn_sync() either directly or
indirectly.
https://bugzilla.redhat.com/show_bug.cgi?id=1436602
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure we call G_IS_ENUM_CLASS() or G_IS_FLAGS_CLASS() only on classed
types.
$ nmcli connection modify foobar wifi.powersave 1
Thread 1 "nmcli" received signal SIGSEGV, Segmentation fault.
0x0000000000440a4d in _set_fcn_gobject_enum at
clients/common/nm-meta-setting-desc.c:985
985 || G_IS_ENUM_CLASS (gtype_prop)) {
Fixes: f53218ed7cd7b5ed9dbe9cc2df122efc1efbf621
|
| |
|
|
| |
https://bugzilla.redhat.com/show_bug.cgi?id=1439360
|
| | |
|
| |
|
|
|
| |
An unexpected message causes the test to abort after the first line of
output.
|
| |
|
|
| |
Fixes: ddfff04a457444ee9a7c7e85d08e1d7213b3ab6e
|
| |
|
|
|
|
|
|
|
|
| |
src/NetworkManagerUtils.c:347:18: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
NMIPAddr a1 = { 0 }, a2 = { 0 };
^
{}
Should we initialize unions this way? I think it's all right -- the initializer
works well and { { { 0 } } } is probably not what we'd like to see.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
Support for 802.11w (Protected Management Frames).
https://bugzilla.gnome.org/show_bug.cgi?id=748367
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Instead of adding a new flag to configuration based on connection
type, use the driver-type field directly in the supplicant-interface.
|
| |/
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=748367
Signed-off-by: Michael Cronenworth <mike@cchtml.com>
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1439376
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The input list of routes is allowed to contain non-normalized routes,
that is, routes which host part is non-zero. Such routes are rejected
by kernel, but NM should transparently allow them (by normalizing
the host part).
The ID comparison function route_id_cmp() already properly ignored
the (possibly non-zero) host part. However, in the internal list we
also should make sure not to track such routes. We achive that by
normalizing the host part to zero.
Note that below we check whether the tracked route is idential to
the route configured at platform. If we don't normalize the host part,
the comparison will always indicate that the route is not yet
configured, and thus we will re-sync the route every time.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Kernel requires that routes have a host part of zero. For NetworkManager
configuration we allow non-zero host parts (but ignore them). Fix
route_compare() to ignore the host part.
This has only effect during assuming connections. That means, on
restart NM would fail to match a connection with static routes
if it has a non-zero host part. So, the impact is rather small.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Routes with a non-zero host part are not allowed by kernel and
don't really exist. We didn't reject such routes in users configuration,
so various part of NM allow such routes. NM should silently strip
the host part.
Extend the cache's route ID to clear the host part too.
Note that NM's handling of routes is fundamentally flawed, as
for kernels routes don't have an "id" (or rather: all properties
of a route are part of it's ID, not only the family,ifindex,
network/plen and metric tuple (see related bug rh#1337855).
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
Platform's add/remove operations accept a "network" argument.
Kernel requires that the host part (based on plen) is all zero.
For NetworkManager we are more resilient to user configuration.
Cleanup the input argument already before calling _nl_msg_new_route().
Note that we use the same "network" argument to construct a obj_id
instance and to find the route in the cache (do_add_addrroute()).
Without cleaning the host part, the added object cannot be found
and the add-route command seemingly fails.
|
| |\
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1442064
|
| | |
| |
| |
| |
| | |
There is only one caller. Don't bother moving the logic to a separate
function.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Got an assertion due to priv-proxy unset.
NMDevice:
- _platform_link_cb_idle()
- nm_device_unrealize() [NMDeviceTun]
- nm_device_state_changed()
- _set_state_full()
NMVpnConnection:
- _set_vpn_state()
- call_plugin_disconnect()
It seam to me, that can only happen if the NMVpnConnection never
completed on_proxy_acquired() and is still in preparing state when
being disconnected.
Avoid that be checking whether we have a proxy.
https://bugzilla.redhat.com/show_bug.cgi?id=1442064
|
| |
|
|
|
|
|
|
|
| |
If the D-Bus call to DeactivateConnection() fails, don't wait for the
connection to change state because this is not going to
happen. Instead, notify the user of the error and, if necessary, wait
for remaining connections to be deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1422786
|
| |
|
|
|
|
|
| |
It's perfectly valid to call the function with out_connection == NULL
when connection_hash == NULL too, as cancel_get_secrets() does.
Fixes: fbb1662269e3c47fa51abfe37d1f3c8f0a213bd0
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
That allows for the property list to contain derived
property types. Also, the list can be directly passed
off as a "const NMMetaAbstractInfo *const*" list.
|
