summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* manager: check for master existence before realizing the devicebg/virt-dev-check-masterBeniamino Galvani2020-01-281-13/+13
| | | | | If we find out that no compatible master connection exists, we shouldn't realize the slave in the first place.
* manager: skip activation of a virtual device if master is missingBeniamino Galvani2020-01-281-0/+14
| | | | | | Don't realize a virtual device if the master is missing because in such case the autoactivation can't start and a stale link will be created.
* dhcp: don't add server-id option to the parameter request listBeniamino Galvani2020-01-251-1/+1
| | | | | | | | | | The option is mandatory in the replies from server and so we don't need to ask for it. dhclient doesn't do it either. But especially, it seems that requesting the option causes some broken server implementations to send duplicate instances of the option. So, remove the option from the parameter request list of the internal nettools and systemd DHCP implementation.
* device: minor cleanup NMDevice's _set_state_full() for unrefing activation ↵Thomas Haller2020-01-201-7/+4
| | | | request
* shared: remove nm_dbus_connection_signal_subscribe_object_manager() helperThomas Haller2020-01-161-7/+7
| | | | | | It seems to complicate things more than helping. Drop it. What we still have is a wrapper around plain g_dbus_connection_signal_subscribe(). That one is trivial and helpful. The previous wrapper seems to add more complexity.
* core/bluetooth: don't use nm_dbus_connection_signal_subscribe_object_manager()Thomas Haller2020-01-161-13/+46
| | | | | | | | | | | | nm_dbus_connection_signal_subscribe_object_manager() wraps the subscription. The problem is that this requires to pass a destroy notify function for cleaning up. Such a destroy notify function will result in an idle source when unsubscribing, which keeps the associated GMainContext alive (until it gets iterated some more). That seems error prone and outright unsuitable for NMClient. While the helper may be useful, it cannot be used by NMClient. So, there is only one user of this function and we don't expect a second one. It seems better to get rid of this wrapper and implement it directly.
* ifcfg-rh: avoid creaing route file twice in make_ip4_setting()Thomas Haller2020-01-161-16/+17
| | | | | | | | | Just read the content once. It's wasteful to read the file twice while parsing. But what is worse, the file content can change any time we read it. We make decisions based on what we read, and hence we should only read the file once in the parsing process to get one consistent result.
* ifcfg-rh: expose constructor for shvarFile that doesn't read content from fileThomas Haller2020-01-162-26/+46
|
* ifcfg-rh: split reading file and parsing from read_route_file() functionThomas Haller2020-01-161-21/+46
| | | | | | | | | | Split the parsing of the file content to a separate function. Next we will load IPv4 files only once, and thus only need to parse the content without reading it. Note that the function temporarily modifies the input buffer, but restores the original content before returning.
* ifcfg-rh: split reading file and parsing in ↵Thomas Haller2020-01-162-4/+19
| | | | | | | | | | | | utils_has_route_file_new_syntax() function We will need both variants, so that the caller can read the file only once. Note that also utils_has_route_file_new_syntax_content() will restore the original contents and not modify the input (from point of view of the caller). In practice it will momentarily modify the content.
* ifcfg-rh: don't use GRegex in utils_has_route_file_new_syntax()Thomas Haller2020-01-161-14/+34
| | | | | It's simple enough to iterate the file content line by line and search for a suitable prefix.
* ifcfg-rh/tests: add test for utils_has_route_file_new_syntax()Thomas Haller2020-01-161-0/+37
|
* core: remove code for unused NM_WIFI_P2P_PEER_GROUPS propertyThomas Haller2020-01-152-45/+0
|
* core: drop "Groups" property from WifiP2PPeer D-Bus APIThomas Haller2020-01-151-1/+1
| | | | | | | | | | | | This property is currently most likely not used. Also, because libnm doesn't expose it and the only known user of this API (gnome-network-displays) doesn't use it. In the future we may want to expand on the Groups API. E.g. exposing groups as separate D-Bus objects, in which case a better property type would be "ao" and not "as". For now, that is unclear nor requested. Remove the property for now.
* initrd/cmdline: minor style cleanupsThomas Haller2020-01-142-2/+3
|
* initrd/cmdline: obey rd.iscsi.ibftLubomir Rintel2020-01-142-43/+63
| | | | | | | | Do process the connections from the iBFT block if the rd.iscsi.ibft or rd.iscsi.ibft=1 argument is present. This is supposed to fix what was originally reported by Kairui Song <kasong@redhat.com> here: https://github.com/dracutdevs/dracut/pull/697
* initrd/ibft-reader: don't set con.interface-name in iBFT connectionsLubomir Rintel2020-01-143-0/+28
| | | | | | | | | | | | | If an argument in form ip=eth0:ibft is specified, we'd first create a wired connection with con.interface-name and then proceed completing it from the iBFT block. At that point we also add the MAC address, so the interface-name is no longer necessary.. Worse even, for VLAN connections, it results in an attempt to create a VLAN with the same name as the parent wired device. Ooops. Let's just drop it. MAC address is guarranteed to be there and does the right thing for both plain wired devices as well as VLANs.
* platform: generate IFA_BROADCAST address based on the peer IFA_ADDRESSThomas Haller2020-01-141-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is also what iproute2 does ([1]) when creating a default broadcast address with `ip addr add 192.168.1.5/24 brd + dev eth0`. Also, kernel does in fib_add_ifaddr() ([2]): ``` __be32 addr = ifa->ifa_local; __be32 prefix = ifa->ifa_address & mask; ... /* Add broadcast address, if it is explicitly assigned. */ if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0xFFFFFFFF)) fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32, prim, 0); if (!ipv4_is_zeronet(prefix) && !(ifa->ifa_flags & IFA_F_SECONDARY) && (prefix != addr || ifa->ifa_prefixlen < 32)) { if (!(ifa->ifa_flags & IFA_F_NOPREFIXROUTE)) fib_magic(RTM_NEWROUTE, dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST, prefix, ifa->ifa_prefixlen, prim, ifa->ifa_rt_priority); /* Add network specific broadcasts, when it takes a sense */ if (ifa->ifa_prefixlen < 31) { fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix, 32, prim, 0); fib_magic(RTM_NEWROUTE, RTN_BROADCAST, prefix | ~mask, 32, prim, 0); } } ``` Which means by default kernel already adds those special broadcast routes which are identical to what we configure with IFA_BROADCAST. However, kernel too bases them on the peer (IFA_ADDRESS). [1] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/ipaddress.c?id=d5391e186f04214315a5a80797c78e50ad9f5271#n2380 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ipv4/fib_frontend.c?id=bef1d88263ff769f15aa0e1515cdcede84e61d15#n1109
* platform: track IFA_BROADCAST address in NMPlatformIP4AddressThomas Haller2020-01-147-37/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - track the broadcast address in NMPlatformIP4Address. For addresses that we receive from kernel and that we cache in NMPlatform, this allows us to show the additional information. For example, we can see it in debug logging. - when setting the address, we still mostly generate our default broadcast address. This is done in the only relevant caller nm_platform_ip4_address_sync(). Basically, we merely moved setting the broadcast address to the caller. That is, because no callers explicitly set the "use_ip4_broadcast_address" flag (yet). However, in the future some caller might want to set an explicit broadcast address. In practice, we currently don't support configuring special broadcast addresses in NetworkManager. Instead, we always add the default one with "address|~netmask" (for plen < 31). Note that a main point of IFA_BROADCAST is to add a broadcast route to the local table. Also note that kernel anyway will add such a "address|~netmask" route, that is regardless whether IFA_BROADCAST is set or not. Hence, setting it or not makes very little difference for normal broadcast addresses -- because kernel tends to add this route either way. It would make a difference if NetworkManager configured an unusual IFA_BROADCAST address or an address for prefixes >= 31 (in which cases kernel wouldn't add them automatically). But we don't do that at the moment. So, while what NM does has little effect in practice, it still seems more correct to add the broadcast address, only so that you see it in `ip addr show`.
* core,libnm: add VRF supportBeniamino Galvani2020-01-146-2/+423
| | | | | | | | Add VRF support to the daemon. When the device we are activating is a VRF or a VRF's slave, put routes in the table specified by the VRF connection. Also, introduce a VRF device type in libnm.
* platform: add VRF supportBeniamino Galvani2020-01-149-0/+174
| | | | Add support for creating and parsing VRF links.
* ifcfg-rh: add support for VRF slavesBeniamino Galvani2020-01-144-1/+24
| | | | | | Even if the ifcfg-rh plugin doesn't support VRF connections, it must be able to read and write other connection types that have a VRF master.
* session-monitor: don't use GIOChannel to watch plain file descriptorThomas Haller2020-01-131-9/+13
|
* lndp: don't use GIOChannel to watch plain file descriptor for socketThomas Haller2020-01-131-14/+19
|
* platform: don't use GIOChannel to watch plain file descriptor for netlink socketThomas Haller2020-01-131-21/+17
|
* acd: don't use GIOChannel to watch plain file descriptor for event fdThomas Haller2020-01-131-13/+21
|
* dhcp/nettools: don't use GIOChannel to watch plain file descriptor for event fdThomas Haller2020-01-131-7/+11
|
* bluez: don't use GIOChannel to watch plain file descriptor for rfcommThomas Haller2020-01-131-11/+12
|
* bluez: don't use GIOChannel to watch plain file descriptorThomas Haller2020-01-131-41/+48
| | | | | Also, don't track the GSource via the guint ID but the full GSource pointer.
* all: use nm_g_unix_fd_source_new() instead of g_unix_fd_source_new()Thomas Haller2020-01-131-2/+6
| | | | | Its source-func argument has the right signature. Otherwise, this is an easy to make mistake.
* platform: use NM_MAKE_STRV() in NMLinuxPlatform:constucted()Thomas Haller2020-01-131-1/+1
|
* core: set MAC address for IP tunnels when creating deviceThomas Haller2020-01-092-7/+41
| | | | | | | | | | | | | | | There is however a serious issue currently: when NetworkManager creates virtual devices, it starts from an unrealized NMDevice, creates the netdev device, realizes the device, and transitions through states UNMANAGED and DISCONNECTED. Thereby, the state of NMDevice gets cleared again. That means, if the profile has "connection.stable-id=${RANDOM}" and "ethernet.cloned-mac-address=stable", then we will first set a random MAC address when creating the device. Then, the NMDevice transitions through UNMANAGED state, forgets the MAC address it generated and creates a new MAC address in stage 1. This should be fixed by better handling unrealized devices. It also affects all software devices that set the MAC address upon creation of the interfaces (as they all should).
* platform: support setting MAC address during nm_platform_link_gre_add()Thomas Haller2020-01-093-3/+10
| | | | We should set the MAC address of devices early on, and not later.
* platform: drop NMPlatformLnkMacvtap typedefThomas Haller2020-01-094-7/+5
| | | | | | | | | | | | | | | | | | | In several cases, the layer 2 and layer 3 type are very similar, also from kernel's point of view. For example, "gre"/"gretap" and "ip6tnl"/"ip6gre"/"ip6gretap" and "macvlan"/"macvtap". While it makes sense that these have different NMLinkType types (NM_LINK_TYPE_MACV{LAN,TAP}) and different NMPObject types (NMPObjectLnkMacv{lan,tap}), it makes less sense that they have different NMPlatformLnk* structs. Remove the NMPlatformLnkMacvtap typedef. A typedef does not make things simpler, but is rather confusing. Because several API that we would usually have, does not exist for the typedef (e.g. there is no nm_platform_lnk_macvtap_to_string()). Note that we also don't have such a typedef for NMPlatformLnkIp6Tnl and NMPlatformLnkGre, which has the same ambiguity between the link type and the struct with the data.
* platform: implement link_macvlan_add via nm_platform_link_add()Thomas Haller2020-01-093-89/+31
|
* platform: implement link_macsec_add via nm_platform_link_add()Thomas Haller2020-01-093-101/+43
|
* platform: implement link_ipip_add via nm_platform_link_add()Thomas Haller2020-01-093-83/+32
|
* platform: implement link_ip6gre_add via nm_platform_link_add()Thomas Haller2020-01-093-108/+48
|
* platform: implement link_ip6tnl_add via nm_platform_link_add()Thomas Haller2020-01-093-97/+45
|
* platform: implement link_6lowpan_add via nm_platform_link_add()Thomas Haller2020-01-093-74/+9
|
* platform: implement link_vxlan_add via nm_platform_link_add()Thomas Haller2020-01-094-140/+66
|
* platform: implement link_vlan_add via nm_platform_link_add()Thomas Haller2020-01-094-127/+76
|
* platform: implement link_sit_add via nm_platform_link_add()Thomas Haller2020-01-093-79/+31
|
* platform: implement link_gre_add via nm_platform_link_add()Thomas Haller2020-01-093-92/+45
|
* platform: add parent argument to nm_platform_link_add()Thomas Haller2020-01-094-14/+27
| | | | This is to set the IFLA_LINK parameter.
* platform: move special link-add functions to headerThomas Haller2020-01-092-91/+60
| | | | | These are thin abstractions over nm_platform_link_add(). Move them to the header.
* platform: extend nm_platform_link_add() to accept type specific extra parameterThomas Haller2020-01-094-35/+63
| | | | This will be used to unify all link-add implementation.
* platform: log name of link that gets added by nm_platform_link_add()Thomas Haller2020-01-091-4/+6
|
* device: avoid assertion failure when setting MAC address of unexpected ↵Thomas Haller2020-01-091-2/+4
| | | | | | | | | | address length IP tunnels honor ethernet.cloned-mac-address. That is a MAC address of 6 bytes (ETH_ALEN). Note that for example for gre tunnels, kernel exposes an address 00:00:00:00. Hence, trying to set ethernet.cloned-mac-address with an gre tunnel leads to an assertion failure. Instead, report and log a regular error.
* dhcp: nettools: handle 'retracted' event as 'expired'Beniamino Galvani2020-01-091-1/+1
| | | | | | | | | | | | The 'retracted' event is emitted when the client receives a NAK in the rebooting, requesting, renewing or rebinding state, while 'expired' means that the client wasn't able to renew the lease before expiry. In both cases the old lease is no longer valid and n-dhcp4 keep trying to get a lease, so the two events should be handlded in the same way. Note that the systemd client doesn't have a 'retracted' event and considers all NAKs as 'expired' events.
View Lorry Controller Status