summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* fixup! libnm: add support for ovs-interface deviceslr/ovs-5Thomas Haller2017-10-111-1/+2
| | | | | | This ensures that nm-device-ovs-interface.h is self-contained -- aside from "nm-default.h", which can be relied on being first.
* fixup! libnm-core: add ovs-interface settingThomas Haller2017-10-111-0/+2
| | | | Since tags
* fixup! libnm-core: add ovs-interface settingThomas Haller2017-10-111-2/+2
| | | | Whitespace
* fixup! libnm-core: add ovs-interface settingThomas Haller2017-10-111-49/+58
| | | | Reorder code
* fixup! libnm-core: add ovs-port settingThomas Haller2017-10-111-94/+102
| | | | Reorder code
* fixup! libnm-core: add ovs-port settingThomas Haller2017-10-111-0/+12
| | | | Add Since tags
* fixup! libnm-core: add ovs-port settingThomas Haller2017-10-111-12/+12
| | | | Whitespace
* fixup! libnm-core: add ovs-bridge settingThomas Haller2017-10-111-2/+2
| | | | Whitespace
* fixup! libnm-core: add ovs-bridge settingThomas Haller2017-10-111-0/+8
| | | | Add Since tags
* fixup! libnm-core: add ovs-bridge settingThomas Haller2017-10-111-58/+66
| | | | Only reorder definitions
* devices: add support for openvswitch devicesLubomir Rintel2017-10-1113-0/+2557
|
* clients: add support for ovs-bridge settingLubomir Rintel2017-10-115-0/+50
|
* clients: add support for ovs-port settingLubomir Rintel2017-10-115-0/+61
|
* clients: add support for ovs-interface settingLubomir Rintel2017-10-115-0/+31
|
* libnm: add support for ovs-bridge devicesLubomir Rintel2017-10-118-0/+143
|
* libnm: add support for ovs-port devicesLubomir Rintel2017-10-118-0/+143
|
* libnm: add support for ovs-interface devicesLubomir Rintel2017-10-118-30/+173
|
* introspection: add o.fd.NM.Device.OvsBridge interfaceLubomir Rintel2017-10-115-0/+31
|
* introspection: add o.fd.NM.Device.OvsPort interfaceLubomir Rintel2017-10-115-0/+31
|
* introspection: add o.fd.NM.Device.OvsInterface interfaceLubomir Rintel2017-10-115-61/+93
|
* libnm-core: add ovs-bridge settingLubomir Rintel2017-10-1111-0/+395
|
* libnm-core: add ovs-port settingLubomir Rintel2017-10-1111-0/+515
|
* libnm-core: add ovs-interface settingLubomir Rintel2017-10-1111-0/+267
|
* device: ignore enslavement to ovs-masterLubomir Rintel2017-10-111-13/+18
| | | | | | That one is special. All interfaces that are attached to OpenVSwitch ports appear as slaves to that one even for our purposes we like to pretend they're slaves to the actual OpenVSwitch bridges.
* device: let the device subclass decide whether a slave is compatibleLubomir Rintel2017-10-112-11/+17
| | | | | Will be useful with OpenVSwitch where we want to be able to enslave "ovs-port" slaves, but also "ovs-bridge" slaves as a shorthand.
* manager: add a method to get a particular device of given typeLubomir Rintel2017-10-113-10/+28
| | | | And also make the remove_device() method use it behind the scenes.
* manager: always update the device when the plink comes and goesLubomir Rintel2017-10-113-45/+46
| | | | | | | | | | | For some software devices, the platform link appears only after they've been realized. Update their properties and let them know that the link has changed so they can eventually proceed with activation. Also, reset the properties (udi, iface, driver) that are set from the platform link when the link goes away. At that point they don't reflect reality anymore. Removes some code duplication too.
* manager: don't assign a new link to a device of a different link typeLubomir Rintel2017-10-111-0/+3
|
* connectivity: fix memory leakBeniamino Galvani2017-10-101-0/+1
| | | | | | The server response, allocated in easy_write_cb(), was not freed. Fixes: 7307dea9c4da6cdc53e4c23c4ce07cf51bd0c4b7
* core: fix memory leaks in NMIP{4,6}ConfigBeniamino Galvani2017-10-102-3/+2
| | | | | Fixes: 03e1cc96a5dc3d9a9b86f60810a330332c484a94 Fixes: 9a3117f1d3095e58859efce57ea4fb41d8fb7696
* all: merge branch 'th/policy-routing-pt2-rh1436531' (part 2)Thomas Haller2017-10-1059-1557/+1749
|\ | | | | | | | | | | | | | | | | | | | | Extend policy-routing and replace previously added route-table-sync setting with a route-table setting. The route table can now be configured per connection profile and affects all routes. This branch breaks API/ABI on development branch by dropping ipv4.route-table-sync from libnm. https://bugzilla.redhat.com/show_bug.cgi?id=1436531
| * core: rework tracking of gateway/default-route in ip-configThomas Haller2017-10-1034-895/+1098
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of having 3 properties @gateway, @never_default and @has_gateway on NMIP4Config/NMIP6Config that determine the default-route, track the default-route as a regular route. The gateway setting is the configuration knob for the default-route. Since an NMIP4Config/NMIP6Config instance only has one gateway property, it cannot track more then one default-routes (see related bug rh#1445417). Especially with policy routing, it might be interesting to configure a default-route in multiple tables. Also, later it might be interesting to allow adding default-routes as regular static routes in a connection, so that the user can configure additional route parameters for the default-route or add default-routes in multiple tables. With this patch, default-routes now have a rt_source property according to their origin. Also, the previous commits of this branch broke handling of the default-route :) . That should be working now again.
| * core: don't track route metric in ip-configThomas Haller2017-10-094-68/+0
| | | | | | | | | | | | | | | | | | | | | | | | It's not needed. Whenever we add a route, we pass in the route metric (for example, based on the device's configuration). No need to merge and track it into the NMIP4Config/NMIP6Config. The metric was only used in nm_ip4_config_create_setting() and nm_ip6_config_create_setting(). In fact it's wrong to do that, because it means we first capture some settings, and guess the configured route metric. But we cannot do that. Our best guess what a configured setting might be is -1.
| * core: don't track route MSS in ip-configThomas Haller2017-10-097-92/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The MSS is only set for VPN connections (by merging it in the respective NMIP4Config/NMIP6Config). It is also only used when setting the MSS of the default route. Don't track that property in NMIP4Config/NMIP6Config, instead, set the mss of the route directly in nm_vpn_connection_ip4_config_get() and nm_vpn_connection_ip6_config_get(). There is a potential change in behavior here: NMDevice also consisdered the MSS for the default route, but that would only be set if the MSS gets merged from an vpn-ip-config. Which at most is the case for iterface-less VPN types (libreswan). But even in that case, it doesn't seem right to me to use the VPN's MSS for the device's default-route.
| * core: use ipv6.route-table setting for other IPv6 routesThomas Haller2017-10-095-7/+24
| | | | | | | | Including device-routes, default-route, SLAAC.
| * core: use ipv4.route-table setting for other IPv4 routesThomas Haller2017-10-0917-20/+94
| | | | | | | | Including device-routes, default-route, DHCPv4, IPv4LL.
| * all: rework configuring route table support by adding "route-table" settingThomas Haller2017-10-0922-179/+274
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change behavior for users that configured policy routing outside of NetworkManager, for example, via a dispatcher script. Users had to explicitly opt-in for NetworkManager to fully manage all routing tables. These settings were awkward. Replace them with new settings "ipv4.route-table" and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable development branch by removing recently added API. As before, a connection will have no route-table set by default. This has the meaning that policy-routing is not enabled and only the main table will be fully synced. Once the user sets a table, we recognize that and NetworkManager manages all routing tables. The new route-table setting has other important uses: analog to "ipv4.route-metric", it is the default that applies to all routes. Currently it only works for static routes, not DHCP, SLAAC, default-route, etc. That will be implemented later. For static routes, each route still can explicitly set a table, and overwrite the per-connection setting in "ipv4.route-table" and "ipv6.route-table".
| * dns: merge IPv4 and IPv6 implementation for update_add_ip_config()Thomas Haller2017-10-091-57/+54
| | | | | | | | | | | | How nice would it be to have a NMIPConfig class that is agnostic for IPv4 and IPv6. Another small step, in unifying v4 and v6.
| * shared: add nm_utils_addr_family_to_size()Thomas Haller2017-10-091-0/+10
| |
| * core: refactor parsing resolve.confThomas Haller2017-10-097-257/+137
| | | | | | | | | | | | | | | | | | - merge the IPv4 and IPv6 implementations. They are for the most part identical. Also, they are independent of NMIP4Config/NMIP6Config. - parse the entire file at once. Don't parse it twice, once for the name servers and once for the options. This also avoids loading /etc/resolv.conf twice, as it would be done before.
| * shared: add nm_strstrip_avoid_copy()Thomas Haller2017-10-091-0/+27
| |
| * platform: mark static nla_policy variables as constThomas Haller2017-10-092-26/+68
| | | | | | | | | | | | | | | | | | | | | | | | These static variables really never be modified. Mark them as const, which allows the linker to mark them as read-only. The problem is libnl3's API, which has these parameters not as const. Add a workaround for that. Clearly libnl3 is not gonna modify the policy, that the API was fixed too [1] [1] https://github.com/thom311/libnl/commit/b4802a17a7655bfeee3e9c06e649d30b96dbad3b
| * wwan: fix uninitialized variable in ofono's context_property_changed()Thomas Haller2017-10-091-7/+6
|/
* dhcp: set @was_active on ipv6 when assuming a device with dhcp ipv6 confFrancesco Giudici2017-10-061-1/+1
| | | | | | Due to a typo the flag was set on ipv4 Fixes: ddfeed4530bb0ade4249025930da4f0456026d9f
* platform: treat dsa devices as regular wired ethernetLubomir Rintel2017-10-061-0/+4
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1371289
* device: reword logging line about device's state changeThomas Haller2017-10-061-2/+2
| | | | | | | | | | | | The line device (wlan0): state change: ip-config -> ip-check (reason none, internal state managed) prints the sys-iface-state, which is at other places logged with device[0x55914506ed70] (wlan0): sys-iface-state: external -> managed For consistency, name the same parameter the same.
* all: merge branch 'th/policy-routing-pt2-rh1436531' (part 1)Thomas Haller2017-10-0623-294/+455
|\ | | | | | | | | | | | | Merge an early part of the branch, with independent cleanups and refactoring. https://bugzilla.redhat.com/show_bug.cgi?id=1436531
| * dhcp/trivial: rename "priority" variables to "route_metric" in DHCP codeThomas Haller2017-10-069-49/+46
| | | | | | | | | | | | | | | | The name "priority" is well established for routes (e.g. kernel's RTA_PRIORITY netlink attribute). However, we call it at most places "metric" or "route_metric". Rename it, not to use two different names for the same thing.
| * device: factor out config argument to ip4_config_merge_and_apply()Thomas Haller2017-10-061-18/+17
| |
| * device: refactor function nm_device_get_priority() / _get_route_metric_default()Thomas Haller2017-10-062-15/+4
| | | | | | | | | | | | | | The name nm_device_get_priority() is misleading. Nowadays it's only used for the default route metric, and nothing else. Rename it, and make it static.
View Lorry Controller Status