Now that NMActiveConnection has IP and DHCP config info, use that
directly in "nmcli con show active" rather than getting it from the
connection's device; this way, we get the right info for VPN
connections as well.
Add IP and DHCP config properties to the D-Bus ActiveConnection
objects.
For device connections, this is redundant with the properties already
on the Device object, but for VPN connections, this information was
not previously available.
When a new activation request is received, NetworkManager creates a new
NMActiveConnection to track that request. The device may already be activated,
in which case NetworkManager stops the old activation and starts the new one,
but both exist in parallel for a short period of time. If the old
NMActiveConnection is activating and already has a pending 'activation'
action, when the new NMActiveConnection adds its own 'activating' action,
they will clash. This is fixed by making each NMActiveConnection's activation
pending action uniquely named.
This fixes a g_warning with the following back trace:
#0 0x000000328224edfd in g_logv () from /lib64/libglib-2.0.so.0
#1 0x000000328224efe2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x000000328224f2e6 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000440aee in nm_device_add_pending_action (device=0x14002e0, action=0x50704a "activation") at devices/nm-device.c:7172
#4 0x000000000047525c in nm_active_connection_set_device (self=0x141b3c0, device=0x14002e0) at nm-active-connection.c:364
#5 0x0000000000475ec1 in set_property (object=0x141b3c0, prop_id=11, value=0x7fff7ff36c20, pspec=0x1405f70) at nm-active-connection.c:647
#6 0x0000003282615d3e in g_object_newv () from /lib64/libgobject-2.0.so.0
#7 0x00000032826162e6 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#8 0x0000003282616654 in g_object_new () from /lib64/libgobject-2.0.so.0
#9 0x0000000000474193 in nm_act_request_new (connection=0x13bb0e0, specific_object=0x0, subject=0x1447740, device=0x14002e0) at nm-activation-request.c:376
#10 0x000000000048e477 in _new_active_connection (self=0x13e8060, connection=0x13bb0e0, specific_object=0x0, device=0x14002e0, subject=0x1447740, error=0x7fff7ff36f90) at nm-manager.c:2947
#11 0x000000000048ed77 in impl_manager_activate_connection (self=0x13e8060, connection_path=0x134d590 "/org/freedesktop/NetworkManager/Settings/9", device_path=0x134d550 "/org/freedesktop/NetworkManager/Devices/1",
specific_object_path=0x0, context=0x143a9b0) at nm-manager.c:3206
#12 0x00000000004876c8 in dbus_glib_marshal_nm_manager_VOID__BOXED_BOXED_BOXED_POINTER (closure=0x7fff7ff37220, return_value=0x0, n_param_values=5, param_values=0x1448830, invocation_hint=0x0,
marshal_data=0x48e9dd <impl_manager_activate_connection>) at nm-manager-glue.h:189
#13 0x0000003284a0d6a9 in object_registration_message () from /lib64/libdbus-glib-1.so.2
#14 0x000000348ea1ce66 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3
#15 0x000000348ea0fa31 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#16 0x0000003284a0acc5 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#17 0x0000003282247df6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#18 0x0000003282248148 in g_main_context_iterate.isra.22 () from /lib64/libglib-2.0.so.0
#19 0x000000328224854a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#20 0x000000000042c6c0 in main (argc=1, argv=0x7fff7ff379b8) at main.c:629
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use a GSList of the string values, instead of an array of GQuarks.
Using GQuarks does not allow to add arbitrary strings, because they
would leak the internalized strings. The next patch will begin
using unique, non-const action strings.
Given the rather small number of expected pending states, a singly
linked list seems appropriate.
Signed-off-by: Thomas Haller <thaller@redhat.com>
(some fixes and simplifications by dcbw based on patch reviews)
Make clear, that only full names are guaranteed to work in future
versions. The use of some abbreviations might break as new options
get added.
It would be rather complicated, to ensure, that abbreviations always
continue to work, at the additional disadvantage, that they no longer
uniquely identify an option. Instead, clearly state that using
them is not guaranteed to work in the future. Users that care about
long term compatibility should instead spell out the full names.
Abbreviations are mainly here for interactive use.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Virtual device types can only have an ifname in the "Device" entry,
but the code was accidentally filling in the MAC address too if the
device currently existed (which then made the entry value invalid).
The nmtui development tree didn't use libtool, and the rules that
worked to install links in those Makefiles ended up causing the
libtool wrapper scripts to get installed here. Fix.
tui/vpn-helpers.c is not yet used, so it shouldn't be translated yet.
Having it in po/POTFILES fails distcheck because, since it is not
yet used, it's not distributed, and thus can't be found in the
distcheck build.
That means you can display single property.
Example:
$ nmcli -f connection.id,802-3-ethernet.mtu s c my-eth-profile
connection.id: my-eth-profile
802-3-ethernet.mtu: auto
and use it for 'nmcli device show'.
This allows filtering output not only for whole groups, but also for individual
fields in commands that print data in groups (sections).
Example:
$ nmcli -f general.device,general.driver,ipv4,ipv6.address device show eth0
GENERAL.DEVICE: eth0
GENERAL.DRIVER: e1000e
IP4.ADDRESS[1]: ip = 10.0.5.228/23, gw = 10.0.5.254
IP4.ADDRESS[2]: ip = 5.5.5.5/32, gw = 5.5.5.1
IP4.DNS[1]: 192.168.122.1
IP4.DNS[2]: 8.8.8.8
IP4.DOMAIN[1]: mycompany.com
deviceid_to_index returns -1 when the deviceid was not found.
Assiging it to an unsigned variable is wrong and would result
in printing an error message when trying to remove the non existing
index.
Signed-off-by: Thomas Haller <thaller@redhat.com>
A fake AP should be the current access point. The code in act_stage1_prepare
violated this invariant for a short time by emitting signals before
setting current_ap. Reorder statements, so that
- fake AP gets created and added to ap_list
- fake AP gets set as current_ap (suppressing notify signals)
- emit ACCESS_POINT_ADDED signal
- thaw notify::NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT signal
When performing a series of actions that emit several signals, it is
often difficult to emit them in an order, so that listeners get a
consistent view. With this change, listeners will get ACCESS_POINT_ADDED
signal, and the current ap already being set to the fake_ap. Next they
get notify::NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT. There is no perfect
solution, but this way it makes slightly more sense.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes automatic activation after changes in
commit ff7e47a418.
When a connection is deactivated impl_manager_deactivate_connection() is called
and the device goes to NM_DEVICE_STATE_DISCONNECTED. nm_device_state_changed()
then issues "state-changed" signal. The signal is connected to by various
listeners. The most interesting ones for this case are NMPolicy and
NMActiveConnection.
The problem is that NMPolicy's device_state_changed() is processed first and
thus in schedule_activate_check() we still have the old active connection
present (in ACTIVATED state).
This commit fixes the issue by connecting to "state-changed" signal using
g_signal_connect_after() in NMPolicy. This ensures NMPolicy's state-changed
handler is called after active connections are processed.
https://bugzilla.redhat.com/show_bug.cgi?id=1033187
