summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* libnm-util: if one of slave-type and master is set, both must be setdcbw/098-slave-fixupDan Williams2014-03-261-0/+9
| | | | | | | | | | slave-type is required because master may refer to an interface that is not yet created, and thus the details of the slave connection are ambiguous. While we can auto-detect slave-type in some cases (like if a bridge-port setting exists, then slave-type=bridge), that functionality isn't implemented yet and doesn't work for all cases. So for the moment, require that both slave-type and master are set if one is set.
* core: respect connection permissions for internal activation requestsDan Williams2014-03-251-0/+14
| | | | | | | | | Similar to "core: respect connection user permissions for activation/deactivation", if a master connection is being activated because a slave connection requested it, ensure that the user requesting the master connection is allowed to activate it. Backport-of: efd0e2a589866de0b9fc71253325fcde33a847ac
* core: respect connection user permissions for activation/deactivationDan Williams2014-03-252-8/+60
| | | | | | | | | | | | | | | | | | | | | | | | | This appears to be a bug since the original 0.9.0 release when connection permissions were implemented. If all the following are true: - the user is local (as determined by systemd or ConsoleKit) - the user has been given the NETWORK_CONTROL PolicyKit permission - the user is not listed in the connection's permissions - the user knows the D-Bus object path of a connection which they have no permissions for then that user may activate/deactivate connections that are not visible to that user as determined by the connection permissions. Fix that by ensuring that these operations check whether the user has permission. These operations are *not* affected, and have always checked user permissions before allowing the operation: - modifying any connection details - requesting any secrets or passwords for the connection - deleting the connection Backport-of: eb8bc5396e0f41b9ebcba5e45916de8b523168c3
* core: emit Manager ActiveConnections before Device ActiveConnectionDan Williams2014-03-201-32/+26
| | | | | | | | | When activating a connection, the Device object's ActiveConnection property was emitted before the object was added to the Manager's active connection list, and thus before the Manager emitted a change signal for the ActiveConnections property. That's the opposite order from what it should be; the manager should know about the AC before the device starts using it.
* core: emit PropertyChanged signal for ActiveConnection when disconnectingDan Williams2014-03-181-2/+2
| | | | (cherry picked from commit 9c5c0cca7fc3ba9fc819df4c1c6d0144cdd6975d)
* update .gitignore fileThomas Haller2014-03-181-0/+6
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: default route should stay on the current active deviceThomas Haller2014-03-181-18/+18
| | | | | | | | | | | | | | | get_best_ip4_device() and get_best_ip6_device() iterate over the list of devices to find the device with the default route. The order of iteration is arbitrarly choosen. Before, if two devices had the same priority, it would choose the first one. Change it so that the device which currently has the default route keeps it -- until it gets deactivated or a higher priorty device gets connected. Signed-off-by: Thomas Haller <thaller@redhat.com> (cherry picked from commit 033285062757f912f39bec9fc0fab5e5127386f5)
* docs: use %TRUE, %FALSE macros instead of plain TRUE, FALSE values for gtkdocJiří Klimeš2014-03-187-37/+37
|
* modem-manager: if building systemd support, assume it manages the MM lifecycleAleksander Morgado2014-03-182-27/+47
| | | | | | | We will not explicitly poke MM to start it if NetworkManager is built with systemd support. https://bugzilla.gnome.org/show_bug.cgi?id=703040
* libnm-glib: suppress warnings unless LIBNM_GLIB_DEBUG is setDan Williams2014-03-181-39/+36
| | | | | | | | Most of these warnings are things libnm-glib can't do anything about, and they are pretty annoying when running nmcli or nmtui, and libraries usually shouldn't print random warnings anyway. So downgrade them to debug messages that can be enabled if we need to see them.
* libnm-glib: make properties-changed debugging available at runtimeDan Williams2014-03-181-14/+22
| | | | | | Use an environment variable LIBNM_GLIB_DEBUG=properties-changed to indicate that properties-changed debugging messages should be printed. Also cleans up the debug output formatting.
* core/dhcp: fix dispose() of NMDHCPClient to handle multiple invocationsThomas Haller2014-03-181-5/+15
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-util: fix trivial GOI copy & paste issueDan Williams2014-03-181-1/+0
|
* libnm-glib; fix introspection annotations so that <ipv6>.get_address() workedJiří Klimeš2014-03-181-4/+9
| | | | | Without the correct annotation, the functions didn't work correctly in Python (causing segmentation fault).
* build: add --with-dnsmasq, to specify dnsmasq pathJan Alexander Steffens2014-03-183-3/+14
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=700219
* docs: update documentation linksWilliam Jon McCann2014-03-184-5/+5
| | | | Various GNOME services moved around so links need updating.
* dbus: allow communication with NetworkManager-iodine VPN pluginDan Fruehauf2014-03-181-0/+1
|
* libnm-util: don't touch dhcp-send-hostname when setting dhcp-hostname (rh ↵Jiří Klimeš2014-03-181-3/+0
| | | | | | | | | | | #1001529) It is better to leave it to user whether he wants to enable sending hostname, because he probably disabled it manually (dhcp-send-hostname is TRUE by default). Also, this would not work for plugins that read and set dhcp-hostname after dhcp-send-hostname. https://bugzilla.redhat.com/show_bug.cgi?id=1001529
* dhcp: dhcpcd uses a fixed path for PID filesDan Williams2014-03-182-2/+6
| | | | | It always uses RUNDIR and the change to NMRUNDIR was in error. This could cause NetworkManager not to be able to kill old dhcpcd processes.
* dhcp: force IPv4-only for dhcpcdDan Williams2014-03-182-0/+11
| | | | | | | | | | | | | | | | | | dhcpcd v5.99 and later automatically enabled IPv6 behavior unless specifically disabled. This is undesirable for two reason: 1) dhcpcd sends IPv4 Router Solicitations, which NetworkManager handles itself, so there's no need to do it twice. NetworkManager knows better than dhcpcd whether IPv6 is supposed to be used for that interface or not. 2) Some devices don't react well to IPv6 when they aren't expecting it. For example, older Qualcomm Gobi-based devices will listen for Router Solicitations and attempt to set up IPv6, but if other settings are not done correctly, or the firmware doesn't actually support it, the firmware will then crash. So simply upgrading your dhcpcd from 5.x to 6.x magically stops WWAN working for these devices.
* libnm-glib: fix crash by taking additional ref in nm-remote-connection/result_cbThomas Haller2014-03-181-0/+2
| | | | | | | | | | | | result_cb invokes a function pointer provided by the user. Nothing prevents the user from destroying the NMRemoteConnection in the callback, which leads to a crash. Take an additional ref of NMRemoteConnection to keep it alive. This probably caused a crash for nm-applet: https://bugzilla.redhat.com/show_bug.cgi?id=1030403 Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-glib: fix a crash in NMObjectDan Winship2014-03-181-0/+3
| | | | | | | deferred_notify_cb() needs to take a ref on the object around emitting its deferred signals, since otherwise if a notify:: handler drops the last reference on an object, a following g_object_notify() call would crash.
* core: workaround crash when connecting to wifi (rh #1025371)Thomas Haller2014-03-181-6/+10
| | | | | | | | | | | | | | rh #1025371 reports a crash in handle_ip_config_timeout() because nm_device_wifi_get_activation_ap() did not return any access point. The handling of the AP in nm-device-wifi.c should be reworked and soon will be fixed. For now, play it safe, and try to cope with any cases where nm_device_wifi_get_activation_ap() might return NULL. Later, this patch should be reverted and handling of the AP properly cleaned up. https://bugzilla.redhat.com/show_bug.cgi?id=1025371
* trivial: quiet log message about failing to determine virtual interface nameDan Williams2014-03-181-2/+2
| | | | | | | | | | | In the case of autoconnect VLANs or IB partitions, if the parent interface hasn't been detected yet at startup, then the get_virtual_interface_name() won't be able to find the parent yet. That's normal, and when the parent is found, system_create_virtual_device() will be run again and the parent will be found, and the autoconnect VLAN/IB partition will be created. But we shouldn't warn that the parent can't be found when that might be a normal occurance.
* settings: validate hostnames from D-Bus (bgo #711179)Dan Williams2014-03-182-0/+38
| | | | | | Do some minimal verification of hostnames that come in via D-Bus, for length and content. Otherwise we'd get as far as asking glibc to set the system hostname, which would reject us.
* libnm-util: do not assert valid connection type in nm_connection_is_type()Jiří Klimeš2014-03-181-2/+1
| | | | That is not useful, simply return FALSE.
* core: fix memory leak in nm-agent-managerThomas Haller2014-03-181-1/+1
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix memory leak in nm-dhcp-dhclientThomas Haller2014-03-181-1/+1
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* dispatcher: fix memory leak in nm-dispatcher-actionThomas Haller2014-03-181-3/+5
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* libnm-glib: fix use proper unref function in libnm-glib/nm-ip4-config.cThomas Haller2014-03-181-3/+3
| | | | | | | NMIP4Address and NMIP4Route instances must be released with a special nm_ip4_*_unref function. Signed-off-by: Thomas Haller <thaller@redhat.com>
* keyfile: always chain-up parent constructor in keyfile dispose methodThomas Haller2014-03-181-1/+2
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix NMManager:primary-connection when a VPN has the default routeDan Winship2014-03-181-4/+14
| | | | | | | | If a VPN had the default route, :primary-connection would become NULL, which is exactly what it's not supposed to do. Fix it to have the value it's supposed to. https://bugzilla.gnome.org/show_bug.cgi?id=710207
* libnm-glib: remove bogus warningDan Williams2014-03-181-1/+0
| | | | | | | When connecting to a hidden SSID, the Access Point object that NetworkManager creates will have no frequency, because the frequency is unknown until the connection succeeds. The warning has no use; if the AP doesn't have a frequency then it even match a connection with a specified frequency.
* libnm-util: remove reference to non-existent "Posix" namespaceDan Winship2014-03-181-4/+1
| | | | | There's no way in gobject-introspection to annotate something as returning an arbitrary C struct type, so don't try.
* libnm-util: fix Bridge priority default (rh #1073664)Dan Williams2014-03-141-1/+1
| | | | | Due to a misread of the kernel code, the bridge priority default when STP was enabled was 0x80 instead of 0x8000.
* libnl-util: refactor nm_utils_ip4_prefix_to_netmask/netmask_to_prefixThomas Haller2014-03-143-80/+82
| | | | | | | | | | | | | | | | | | | | | - use a more efficient implementation for prefix_to_netmask - fix netmask_to_prefix to behave consistently in case of invalid netmask - remove unused duplicated functions from NetworkManagerUtils.c - add test functions Based-on-patch-by: Pavel Šimerda <psimerda@redhat.com> Signed-off-by: Thomas Haller <thaller@redhat.com> Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771 (cherry picked from commit 4dd6ab8f4b47e906be84442be8d68e82e41a1a24) Backport this commit, because the previous implementation of nm_utils_ip4_netmask_to_prefix caused a compiler warning: nm-utils.c: In function 'nm_utils_ip4_netmask_to_prefix': nm-utils.c:1676:22: error: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Werror=strict-overflow] while ((*p == 0xFF) && p < end) {
* build: fix (invalid) compiler warningThomas Haller2014-03-141-1/+1
| | | | | | | | connection_parser.c: In function 'make_ip4_setting': connection_parser.c:673:33: error: 'method' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (!is_static_block && strstr (method, "dhcp")) { Signed-off-by: Thomas Haller <thaller@redhat.com>
* dispatcher: fix wrong IP6 addresses in dispatcher script environmentThomas Haller2014-03-141-7/+4
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=701819 Signed-off-by: Thomas Haller <thaller@redhat.com>
* build: convert from INCLUDES to AM_CPPFLAGSDan Williams2014-03-0438-314/+241
| | | | | | | | | | | | | Prevents automake warnings like: callouts/tests/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS') Unfortunately, AM_CPPFLAGS is only used if the target has not defined its own CPPFLAGS, which a lot of NM targets had. But we can easily fix that by including AM_CPPFLAGS in the target specific CPPFLAGS where needed, or collapse common CPPFLAGS into AM_CPPFLAGS and remove per-target CPPFLAGS where appropriate.
* build: clean git master generated filesDan Williams2014-02-261-1/+4
| | | | Makes it easier to switch between git master and 0.9.8.
* firewall: ignore UNKNOWN_INTERFACE errorsDan Williams2014-02-261-2/+5
| | | | | | | If the firewall didn't know about the interface, don't log errors about it because there's nothing NM can do. Also, sometimes NM sends the not-IP interface, like when disconnecting WWAN when the PPP interface is already gone.
* core: suppress error message ZONE_ALREADY_SET when adding firewalld zoneThomas Haller2014-02-261-3/+9
| | | | | | | | | | | | | | See also https://bugzilla.redhat.com/show_bug.cgi?id=886432, where firewalld was changed, not to return ZONE_ALREADY_SET for 'changeZone'. However, 'addInterface' can still fail with this error. Suppress the following error lines: <debug> [1392290031.179280] [firewall-manager/nm-firewall-manager.c:117] nm_firewall_manager_add_or_change_zone(): (em1) firewall zone add -> (null) ... <warn> (em1) firewall zone add/change failed: (32) ZONE_ALREADY_SET Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: report which option is unknownGuido Günther2014-02-261-2/+4
| | | | | | | | | | | | | | | So far NetworkManager didn't tell which option it didn't know about: Invalid option. Please use --help to see a list of valid options. Now it is a bit more informative: Unknown option --asdf. Please use --help to see a list of valid options. The "Unknown option" string is marked as translatable in glib so i18n doesn't suffer. Signed-off-by: Thomas Haller <thaller@redhat.com>
* manager: fix notification of the connectivity propertyGiovanni Campagna2014-02-261-0/+2
| | | | | | | Notify DBus clients at the end of a connectivity check, and when NMConnectivity reports a change. https://bugzilla.gnome.org/show_bug.cgi?id=724550
* libnm-util: fix verify_identity() in '802-1x' settingJiří Klimeš2014-02-261-0/+2
| | | | | We need to return FALSE on error, otherwise we pile GErrors and assert in nm_setting_verify().
* libnm-util: fix adding values to 'phase2-altsubject-matches'Jiří Klimeš2014-02-251-5/+6
| | | | It was mixed up with 'altsubject-matches'.
* core: bugfix potential crash in dhcp4_state_changedThomas Haller2014-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | Causes glib warning GLib-GObject-WARNING **: invalid cast from 'NMIP4Config' to 'NMDHCP4Config' #0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0 #1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0 #2 0x0000003371c32c43 in g_type_check_instance_cast () from /lib64/libgobject-2.0.so.0 #3 0x000000000042aece in dhcp4_add_option_cb (key=0x1df8350, value=0x1dbca10, user_data=0x1e0d9f0) at nm-device.c:1884 #4 0x00000000004953e5 in nm_dhcp_client_foreach_option (self=0x1dcb2a0, func=0x42aea3 <dhcp4_add_option_cb>, user_data=0x1e0d9f0) at nm-dhcp-client.c:807 #5 0x000000000042b1dc in dhcp4_state_changed (client=0x1dcb2a0, state=DHC_BOUND4, user_data=0x1de4330) at nm-device.c:1959 #6 0x0000003371c126ac in g_cclosure_marshal_VOID(unsigned int0_t, void) () from /lib64/libgobject-2.0.so.0 #7 0x0000003371c104c7 in _g_closure_invoke_va () from /lib64/libgobject-2.0.so.0 #8 0x0000003371c29749 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0 #9 0x0000003371c2a3af in g_signal_emit () from /lib64/libgobject-2.0.so.0 #10 0x0000000000493d01 in dhcp_client_set_state (self=0x1dcb2a0, state=DHC_BOUND4, emit_state=1, remove_now=0) at nm-dhcp-client.c:241 ... regression, introduced by 46be6b344deb428f8ec7968527b782b6c3feedcc. Signed-off-by: Thomas Haller <thaller@redhat.com>
* wifi: do not print dump inconsistency error for get scan commandStanislaw Gruszka2014-02-101-0/+9
| | | | | | | | | | Avoid printing "nl_recvmsgs() error: (-33) Dump inconsistency detected, interrupted". DUMP_INTR error is harmless for scan (see in code comments). (cherry picked from commit 28dfb2e4a2cc13affc787878a3eab4cde03a8bba) Signed-off-by: Thomas Haller <thaller@redhat.com>
* build: include the git commit id of HEAD in ./configureThomas Haller2014-02-051-0/+2
| | | | | | | | | `make dist` packs the 'configure' file in the tarball, so this is useful, to include the commit id into the release tarball. (cherry picked from commit 8da98026daca5dad95f402a5c9b648d68fe8c73d) Signed-off-by: Thomas Haller <thaller@redhat.com>
* dhcp: ensure any dhclient script from dhclient.conf is ignoredDan Williams2014-02-051-0/+4
| | | | | | | | | | | The config file can specify a dhclient script, which gets used instead of what NM passes on the command-line. Make sure that script gets ignored in the final dhclient config, because the script NM passes is the script that needs to be used to pass data back to NM. People may have old dhclient.conf files lying around that get picked up and we don't want any script specified there to interfere. (cherry picked from commit 97990135f150237eb7d529894fb0149d9faa5f0f)
View Lorry Controller Status