summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* core: reorgranize some NMManager functionsdcbw/miscDan Williams2014-01-241-334/+332
| | | | | No code changes at all, just moving GObject-related functions to the bottom of the file per NM conventions.
* trivial: more usage of g_signal_handlers_disconnect_by_func()Dan Williams2014-01-241-8/+11
|
* trivial: simplify some codeDan Williams2014-01-241-8/+4
|
* core: provide useful error messages to main() on Manager creation failureDan Williams2014-01-242-2/+5
|
* core: exit cleanly if D-Bus cannot be initialized (rh #1057738)Dan Williams2014-01-241-41/+49
| | | | Instead of crashing, let's exit cleanly.
* policy: fix policy after dcbw/kill-at-console merge (bgo #707983) (rh #979416)Dan Williams2014-01-241-2/+8
| | | | | | | | | | Polkit documentation suggests that <allow_any> applies to all clients, but that's actually not the case. allow_any, allow_inactive, and allow_active are evaluated individually based on whether the user is local and active (allow_active), local and inactive (allow_inactive), and not local (allow_any). Thus all three allow options must be specified for any authorization other than 'no'.
* merge: handle interface-less VPNs like open/libre-swan (bgo #721724) (rh ↵Dan Williams2014-01-2417-110/+593
|\ | | | | | | | | | | | | | | | | | | | | | | #1030068) IPSec-based VPNs that use the kernel IPSec functionality don't have tunnel interfaces. Instead, the IP addresses and routes they create are added to the parent interface and the kernel handles securing the traffic based on routing. Modify NM to handle this. Also modify NM to ensure it doesn't touch routes added externally, and to preserve various route properties correctly.
| * core/platform: sort routes before adding them in nm_platform_ipX_route_sync()Thomas Haller2014-01-241-32/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | A gateway route can only be added, if there exists a device route for that gateway. Therefore, nm_platform_ip4_route_sync() and nm_platform_ip6_route_sync() has to add the device routes first, before adding gateway routes. Note: usually for all configured addresses, there is also a device route for the subnet added by the kernel. This means, NM must first configure the addresses before route_sync, so that these implicit device routes already exist -- this is however already done correctly. Signed-off-by: Thomas Haller <thaller@redhat.com>
| * core/platform: revise failure to activate connection on error of setting routeThomas Haller2014-01-241-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This revises the commit fbde824584266d9f6ac7f14916fdcc9cd179a73a which causes the activation of a connection to fail generally when a route cannot be added. Instead, we only want to fail for user configured routes. Related: https://bugzilla.gnome.org/show_bug.cgi?id=722843 Related: https://bugzilla.redhat.com/show_bug.cgi?id=999544 Related: https://bugzilla.redhat.com/show_bug.cgi?id=1005416 Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771 Signed-off-by: Thomas Haller <thaller@redhat.com>
| * core/platform: compare IPv4 addresses in nm_platform_ip4_*_cmp() as ↵Thomas Haller2014-01-241-4/+4
| | | | | | | | | | | | integers, without memcmp() Signed-off-by: Thomas Haller <thaller@redhat.com>
| * platform: don't replace routes that already existDan Williams2014-01-241-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a route already exists that matches the network, prefix, gateway, and metric of a route NM would like to add, don't try to overwrite the route. Unlike IP addresses, the kernel doesn't update the details, it appears to completely replace that route, which might screw up external tools that added the route originally. One example of this is IPSec via openswan/libreswan. They add the routes to the kernel upon connection, and if NM replaces those routes, IPSec no longer works. While this may be due to kernel bugs or bad handling of route replacement, there's no reason for NM to touch routes that it wouldn't materially change anyway. (yes, we could perhaps use NLM_F_REPLACE in add_kernel_object() only when we really wanted to replace something, but why ask the kernel to do the work when it's not required anyway?)
| * core/platform: preserve external and static route metricsDan Williams2014-01-245-20/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two issues: 1) routes added by external programs or by users with /sbin/ip should not be modified, but NetworkManager was always changing those routes' metrics to match the device priority. This caused the nm_platform_ipX_route_sync() functions to remove the original, external route (due to mismatched metric) and re-add the route with the NetworkManager specified metric. Fix that by not touching routes which came from the kernel. 2) Static routes (from persistent connections) that specified a metric were getting their metric overwritten with the NetworkManager device priority. Stop doing that. Since the platform no longer defaults the metric to 1024, callers of nm_platform_ip4_route_add() (like NMPolicy's default route handling) must do that themselves, if they desire this behavior.
| * core/platform: add address/route sources (rh#1005416, bgo#722843)Dan Williams2014-01-2414-16/+425
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tag addresses and routes with their source. We'll use this later to do (or not do) operations based on where the item came from. One thing to note is that when synchronizing items with the kernel, all items are read as source=KERNEL even when they originally came from NetworkManager, since the kernel has no way of providing this source information. This requires the source 'priority', which nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect to ensure that NM-owned routes don't have their source overwritten when merging various IP configs in ip*_config_merge_and_apply(). Also of note is that memcmp() can no longer be used to compare addresses/routes in nm-platform.c, but this had problems before anyway with ifindex, so that workaround from nm_platform_ip4_route_sync() can be removed. https://bugzilla.gnome.org/show_bug.cgi?id=722843 https://bugzilla.redhat.com/show_bug.cgi?id=1005416
| * vpn: handle missing tunnel interface for IP-based VPNs (bgo #721724) (rh ↵Dan Williams2014-01-242-48/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #1030068) IPSec-based VPNs that use the kernel IPSec stack don't have tunnel interfaces, and the IP details (address, routes) get added directly to the parent network device. NetworkManager previously required a tunnel interface and failed the VPN if one was not provided. When no tunnel interface is passed, construct the VPN IP configuration using available details and pass that to the NMDevice as the VPN IP config. The device will merge that config with its own and apply any configuration that the kernel/VPN has not already applied. https://bugzilla.gnome.org/show_bug.cgi?id=721724 https://bugzilla.redhat.com/show_bug.cgi?id=1030068 https://bugzilla.redhat.com/show_bug.cgi?id=865883 https://bugzilla.redhat.com/show_bug.cgi?id=845599
| * dispatcher: handle VPN connections without interface namesDan Williams2014-01-241-1/+1
| |
| * dns-manager: allow NULL interface name for IP configsDan Williams2014-01-241-4/+1
|/ | | | | | | VPN services that use the kernel's IPSec stack (like OpenSwan/LibreSWAN) obviously don't have a tunnel interface, so don't require one. If those services provide Link-Local IPv6 DNS servers they simply won't work, but perhaps we can filter those out later or warn about them.
* examples: a Python GOI example for adding connections persistent vs. not savedJiří Klimeš2014-01-242-1/+103
|
* man: document the default value for autoconnect 'nmcli con add' argumentJiří Klimeš2014-01-241-1/+1
|
* po: update Tamil (ta) translation (bgo #722895)Shantha kumar2014-01-241-1131/+5163
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=722895 Signed-off-by: Thomas Haller <thaller@redhat.com>
* man: fix typo in commands in Team exampleJiří Klimeš2014-01-241-2/+2
|
* merge: add some missing D-Bus interface properties (bgo #715186)Dan Williams2014-01-2340-435/+2136
|\ | | | | | | | | | | | | | | | | Add properties for things that previously were missing to help out Qt bindings, among others. Also converts libnm-glib over to use the new properties, and adds some testcases to ensure libnm-glib works correctly with them. https://bugzilla.gnome.org/show_bug.cgi?id=715186
| * trivial: remove unused #definesDan Williams2014-01-2316-71/+0
| | | | | | | | | | These are no longer used by anything, but are determined automatically from the GObject property names.
| * libnm-glib: add testing framework and testcasesDan Williams2014-01-234-3/+1745
| | | | | | | | | | Add a fake NM service and test various aspects of the new NM D-Bus properties.
| * libnm-glib: remove unused pseudo-property codeDan Williams2014-01-232-240/+1
| | | | | | | | | | Now that all previous pseudo-properties have been converted to real D-Bus and GObject properties, we can remove this code.
| * libnm-glib: convert NMClient Devices to a real propertyDan Williams2014-01-232-23/+21
| |
| * libnm-glib: convert NMDeviceWimax NSPs to a real propertyDan Williams2014-01-232-36/+39
| |
| * libnm-glib: convert NMDeviceWifi AccessPoints to a real propertyDan Williams2014-01-232-33/+36
| | | | | | | | | | | | | | | | | | Note that this will cause the nm_device_wifi_get_access_points() to return hidden-SSID access point objects immediately, which it previously did not do until added/removed signals were sent by NetworkManager for a hidden SSID AP. Some clients may not handle this correctly, but given that they would have crashed when the first hidden SSID AP was found anyway, they should just be fixed.
| * libnm-glib: add support for non-pseudo-property added/removed signalsDan Williams2014-01-232-7/+100
| | | | | | | | | | | | | | | | | | With the addition of D-Bus properties for object-array properties in NetworkManager core, libnm-glib can use these properties instead of the pseudo-property stuff. However, we need to maintain API and provide individual added/removed signals for these properties, and that requires diff-ing the new and old object arrays. Add the infrastructure for doing that.
| * api/settings: expose the ConnectionRemoved signalDan Williams2014-01-233-3/+21
| | | | | | | | Helps out bindings.
| * api/wimax: add Nsps (Network Service Providers) propertyDan Williams2014-01-233-0/+28
| | | | | | | | Helps out bindings.
| * api/settings: add Connections propertyDan Williams2014-01-233-0/+29
| | | | | | | | Helps out bindings.
| * api/wifi: add GetAllAccessPoints() methodDan Williams2014-01-232-4/+37
| | | | | | | | | | | | | | The original GetAccessPoints() method call never returned hidden SSID access points. That's useful though, and the new AccessPoints property returns all of them too, so add this new method to return all access points, including hidden SSID ones.
| * api/wifi: add AccessPoints propertyDan Williams2014-01-233-0/+31
| | | | | | | | Helps other bindings.
| * api/core: add Devices property to the ManagerDan Williams2014-01-233-4/+31
| |
| * cli: handle hidden-SSID access points correctlyDan Williams2014-01-231-11/+17
|/
* wifi: fix double-free of error when handling D-Bus scan requestDan Williams2014-01-231-9/+13
| | | | | The error passed into the function by the manager's auth request logic should not be freed.
* wifi: fix crash after "merge: remove at_console..." for wifi scan requestsDan Williams2014-01-232-4/+5
| | | | | | Fix a crash caused by "merge: remove at_console..." when a scan request comes in via the D-Bus interface. This usage of the device "auth-request" signal was missed the first time around.
* merge: remove at_console from D-Bus permissions (bgo #707983) (rh #979416)Dan Williams2014-01-2311-96/+171
|\ | | | | | | | | | | | | Remove at_console, ensuring that all necessary calls are protected by PolicyKit authorization (which at_console is redundant with). Allows sessions that are not necessarily local (like SSH or remote desktop) to talk to NetworkManager, subject to administrator PolicyKit rules.
| * policy: allow inactive (remote/SSH) sessions to perform some actions (bgo ↵Dan Williams2014-01-231-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | #707983) (rh #979416) This commit allows inactive sessions (typically SSH or remote desktop logins) to modify their own connections, to modify the system hostname with authorization, and to modify system connections with authorization. https://bugzilla.redhat.com/show_bug.cgi?id=979416 https://bugzilla.gnome.org/show_bug.cgi?id=707983
| * dbus: kill at_console usage in permissions (bgo #707983) (rh #979416)Dan Williams2014-01-231-54/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | at_console permissions as implemented by D-Bus have some problems: 1) it is now fully redundant with PolicyKit and session tracking via systemd/ConsoleKit 2) it uses a different mechanism than PolicyKit or systemd to determine sessions and whether the user is on local or not (pam_console) 3) it was never widely implemented across so removing it harmonizes D-Bus permissions on all supported distros To that end, remove the at_console section of the D-Bus permissions, and rely on session-tracking and PolicyKit to ensure operations are locked down. No changes are being made to PolicyKit or session-tracking, so any operations denied by those mechanisms are still denied, and no permissions are being relaxed. Instead, this should allow remote users who log in via remote desktop or SSH to inspect network state, change connection parameters, and start/stop interfaces. Obviously if you are remote, you should not touch the interface which your connection is using, but that concern shouldn't prevent all the other nice stuff that you can do with NM. https://bugzilla.gnome.org/show_bug.cgi?id=707983 https://bugzilla.redhat.com/show_bug.cgi?id=979416
| * core: enforce permissions for SetLoggingDan Williams2014-01-232-9/+31
| | | | | | | | | | This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
| * sessions: fix return value handling for sd_uid_get_sessions() (bgo #707983)Dan Williams2014-01-231-10/+12
| | | | | | | | | | | | This function returns the number of sessions found, but the return value wasn't being correctly handled for errors. Also fix the require_active parameter value to be 100% clear about what NM wants.
| * settings: return error from GetConnectionByUuid() if caller not in ACLDan Williams2014-01-232-14/+43
| | | | | | | | | | | | | | While this function only returns the path of the requested connection (the actual settings are always protected), callers that aren't in the connection's ACL still probably shouldn't get that, if only to be pedantic.
| * core: add PropertiesChanged signals to IP4 and IP6 config objectsDan Williams2014-01-234-3/+22
|/ | | | | | | | Now that the objects get replaced when IP configuration changes instead of being destroyed and a new one created, they need PropertiesChanged signals. (noticed as a result of auditing all exported D-Bus objects)
* core: allow custom IP address ranges for Shared connections (bgo #675973)Dan Williams2014-01-2310-69/+314
| | | | | | | | | | | | | | | | Given an IPv4 address and prefix for a shared config, figure out the DHCP address range automatically. To keep things simple we allow a max of 252 addresses (not including network address, broadcast address, and the hotspot) no matter what prefix you use, so if the address is 10.0.10.1, you still only get a range of 10.0.10.2 -> 10.0.10.254. But we also leave some addresses available above the host address for static stuff, like we did before. This is done on a sliding scale from 0 to 8 addresses, where about 1/10th the number of available addresses are reserved. https://bugzilla.gnome.org/show_bug.cgi?id=675973
* core: only log about IPv6 Commit the first timeDan Williams2014-01-231-10/+10
| | | | | | | | | | | | Since IPv6 configuration gets updated every time a router advertisement comes in, it can lead NM to continuously logging: NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) scheduled... NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) started... NetworkManager: <info> Activation (eth0) Stage 5 of 5 (IPv6 Commit) complete. that's annoying. So after the initial configuration is done, make subsequent IPv6 Commit log messages debug instead of info.
* core: don't disable IPv6 when assuming connections (rh #1052157)Dan Williams2014-01-231-1/+2
| | | | | | Don't disable IPv6 when we're about to assume a connection that may well have IPv6 already configured on the interface, which removes all addresses and routes from the interface and generally Breaks Stuff.
* core: various fixes to autoconnect retry handling (rh #1029480)Dan Winship2014-01-2314-408/+372
|\
| * devices: when disconnecting master, propagate reason to the slavesDan Winship2014-01-231-28/+30
| | | | | | | | | | | | When disconnecting a master device, propagate its NMDeviceStateReason to the slaves. That way, if the reason is USER_REQUESTED, then the slaves will be blocked from re-autoconnecting as well.
| * core: fix master deactivationDan Winship2014-01-232-41/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | NMActiveConnection was categorizing all deactivation of master connections as "failure", and NMActRequest was deactivating all of the master's slaves with REASON_DEPENDENCY_FAILED no matter what the real reason was. In fact, NMActiveConnection only needs to handle the cases where the master fails before enslaving the device; any failure after that point will be caught by existing master/slave checks in NMDevice. So update the code accordingly (and remove the master_failed code from NMVpnConnection entirely, since no master supports having VPN slaves).
View Lorry Controller Status