Calling g_file_test with a NULL path causes valgrind to complain.
NetworkManager[24512]: <debug> [1377884547.687536] [dhcp-manager/nm-dhcp-dhclient.c:482] create_dhclient_config(): (em1): no existing dhclient configuration to merge
==24512== Syscall param access(pathname) points to unaddressable byte(s)
==24512== at 0x3F976E7627: access (in /usr/lib64/libc-2.17.so)
==24512== by 0x4EDA556: g_file_test (in /usr/lib64/libglib-2.0.so.0.3600.3)
==24512== by 0x49BB69: create_dhclient_config (nm-dhcp-dhclient.c:364)
==24512== by 0x49CC39: ip4_start (nm-dhcp-dhclient.c:671)
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a glib assertion.
Backtrace:
#0 0x00007f139ab08e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f139ab08ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003f9aa3151a in g_type_check_instance () from /lib64/libgobject-2.0.so.0
#3 0x0000003f9aa272d4 in g_signal_handlers_disconnect_matched () from /lib64/libgobject-2.0.so.0
#4 0x0000000000495b7d in supplicant_interface_release (self=0xc58040) at devices/nm-device-wifi.c:423
#5 0x0000000000498a28 in dispose (object=0xc58040) at devices/nm-device-wifi.c:3525
#6 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#7 0x000000000047699a in remove_device (manager=manager@entry=0xc09050, device=0xc58040, quitting=quitting@entry=1) at nm-manager.c:748
#8 0x0000000000478a84 in dispose (object=0xc09050) at nm-manager.c:4558
#9 0x0000003f9aa14338 in g_object_unref () from /lib64/libgobject-2.0.so.0
#10 0x0000000000428cc0 in main (argc=1, argv=0x7fffc0948c98) at main.c:626
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a glib assertion:
"dbus_g_proxy_cancel_call: assertion `pending != NULL' failed"
Backtrace:
#0 0x00007f962dad9e0d in g_logv () from /lib64/libglib-2.0.so.0
#1 0x00007f962dad9ff2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x00000000004a84bd in nm_secret_agent_cancel_secrets (self=0x213b300, call=0x1) at settings/nm-secret-agent.c:331
#3 0x00000000004a4068 in request_free (req=0x216a490) at settings/nm-agent-manager.c:479
#4 0x00007f962dac25fa in g_hash_table_remove_internal () from /lib64/libglib-2.0.so.0
Signed-off-by: Thomas Haller <thaller@redhat.com>
libgsystem contains more than just the local allocation macros; in the
future we will likely want to make use of some of this such as the
structured logging support.
Add *_to_string functions for address (ip4 and ip6) and
route (ip4 and ip6). Also refactor the previously existing
nm_platform_ip4_route_to_string function.
The to_string function returns a pointer to an internal
buffer. Also update log_* functions to make use of the new
to_string functions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before the change if an alias for a setting name existed, it was used instead of
the real name and TAB-completion for the real name didn't work.
before:
nmcli> goto 802<TAB>
no output
now:
nmcli> goto 802<TAB>
nmcli> goto 802-11-wireless
802-11-wireless 802-11-wireless-security
nmcli> goto <TAB>
802-11-wireless-security (wifi-sec) connection ipv6
802-11-wireless (wifi) ipv4
The properties are not implemented in NM core, nor in ifcfg-rh plugin. Thus
they are not preserved over re-reading from ifcfg-* file. Moreover they are
highly dependent on drivers.
When we allowed editing them, the connection changed after re-reading and
was marked as dirty (and users were puzzled).
Add properties to track the "primary" connection (ie, the active
connection with either the default route, or the route to the VPN with
the default route), and the active connection that is currently
activating, and likely to become the :primary-connection when it
completes.
https://bugzilla.gnome.org/show_bug.cgi?id=704841
NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive
portal" and "limited network connectivity" (ie, connected to a router
that has lost its upstream connection). Add a new NMManager
:connectivity property to provide this information.
Also add a CheckConnectivity method, which can be used to force NM to
re-check the connectivity state, which could be called by a client
after it completed a portal login, or fixed a network problem.
The connectivity-checking code would generally result in
NMManager:state going CONNECTING -> CONNECTED_GLOBAL -> CONNECTED_SITE
in the case where the connectivity check failed. The brief incorrect
CONNECTED_GLOBAL is bad, because clients might see it and do the wrong
thing.
Instead, when we are ready to switch from CONNECTING to CONNECTED_*,
do a connectivity check first, and switch to either CONNECTED_SITE or
CONNECTED_GLOBAL based on the result of that.
Build and use NMConnectivity regardless of build options; if you build
without libsoup, NMConnectivity will just always report that you have
full connectivity (like it does when you build with libsoup but don't
enable connectivity checking).
Before, whereever a connection id is accepted, the completion only
offered 'id', 'uuid', 'path', etc. With this change, it will additionally
suggest the id of existing connections.
https://bugzilla.redhat.com/show_bug.cgi?id=997997
Signed-off-by: Thomas Haller <thaller@redhat.com>
To support optimal completion, more context must be considered.
Especially the OPTIONS, which must appear before the OBJECT.
Modify bash completion to try parsing first the options.
Before, whenever you had options, completion did not work
anymore (because the object was expected as first argument).
Moreover, options were also suggested after specifying the
object. This is now mitigated by parsing the command line
in two steps.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This also slighly changes the behaviour for writing IPV6_DEFAULTGW.
- IPV6_DEFAULTGW will be written after IPV6ADDR and
IPV6ADDR_SECONDARY.
- Before, if there were no IPv6 addresse present, the IPV6_DEFAULTGW
might not have been cleared. Now IPV6_DEFAULTGW is always written
(or unset as in the case of gateway ::).
https://bugzilla.redhat.com/show_bug.cgi?id=997759
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before, when a route failed to be added, NM stopped adding further
routes. However, the activation still continued and the user was not
notified about the error.
Adding a route might fail for example if the gateway is not on one of
the subnets of the interface.
Now, a failure to add a route makes the activaion fail. If the
connection has autoconnect=yes, this might result in some unsuccessful
reconnection attempts.
In the future, we might want to distinguish between manually added routes
and routes from RA/DHCP. So that connecting to a wrongly configured DHCP
server still works for most parts.
https://bugzilla.redhat.com/show_bug.cgi?id=999544
Signed-off-by: Thomas Haller <thaller@redhat.com>
These devices don't have a platform device at creation time, thus
is_software wasn't getting set properly. Move the is_software
decision to constructed() because by this point, the iface and
ifindex (if present) will be known for all cases and thus we can
figure out if it's a software device or not in one place.
The fix in commit b5b43a6d65 missed the
release of the route instance (because nm_setting_ip4_config_add_route
does not take over the passed route but duplicates it).
So the orginal error was to free the route with the wrong deallocation
method gs_unref_object instead of nm_ip4_route_unref.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This backwards compatible patch adds the possibility to use new
nm_device_generate_connection() API via update_connection() virtual
method implementations in NMDevice subclasses.
Compatibility is achieved by first trying to use the older API and
match_l2_config() virtual method and only then moving on to
update_connection().
The nm_device_generate_connection() calls update_connection() to create
type-specific NMSetting instances and verifies the connection before
returning it. To avoid tinkering with NMSettingConnection in
update_connection() we use a class attribute called connection_type
which is used by nm_device_generate_connection() itself.
Known issues:
* nm_device_generate_connection() method doesn't implement DHCP lease
configuration matching. We shouldn't actually need it but if a use case
for that will come out, we can fix it later.
* nm_device_generate_connection() doesn't fill in the slave-specific
options.
* update_connection() is not implemented and connection_type is not set
in the subclasses. This will be fixed in individual patches.
* NMSetting's compare_property() implementations in combination with
NM_SETTING_COMPARE_FLAG_CANDIDATE are not yet fully ready thus rendering
false negatives in some cases. Same as above.
Acked-by: Dan Winship <danw@gnome.org>
Acked-by: Thomas Haller <thaller@redhat.com>
