4 Commits

Author SHA1 Message Date
Chen Qi
a0d774ffae networkmanager: fix /etc/resolv.conf handling
The current handling of /etc/resolv.conf by NM has some problems.
When networkd is not configuring network, and there's 'ip=dhcp'
in kernel command line, the /run/NetworkManager/resolv.conf file
is not created, resulting in /etc/resolv.conf being a dead symlink.
This is because NM is treating the network interface as externally
configured and will not try to reconfigure it again.

This means if we want NM to work properly with /etc/resolv.conf,
we've got to either ensure there's no 'ip=dhcp' in kernel command
line, or we've got to ensure networkd is configuring network. This
is weird because normally we should not enable two network managers
at the same time. Note that NM syncs part of its codes with networkd,
which is the reason I think it happens to work when these two network
configuration tools are configuring the same interface at the same
time.

In fact, NM now works well with resolved. It sends the DNS info it
gets to resolved unconditionally by default (the behavior could be
disabled in configuration file).

Looking at the original commit that sets up the update-alternatives
mechanism, it says:
"""
  This brings the networkmanager in sync with how systemd-resolved and connman
  work. Additionally this allows it to function with a read-only rootFS.
"""
I guess the author was using systemd but disabling resolved, and the author
wanted to use read-only rootFS. In order to keep such combination still works,
change to use PACKAGECONFIG to handle things, and when 'man-resolv-conf' is
enabled, the above combination could still work.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
(cherry picked from commit a8ebf23dde9c82dd9d1dcd0fa6de0b4467a0112b)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
2023-01-21 10:10:14 -05:00
Chen Qi
43e318de2f networkmanager: install config files into correct place
The current location has no effect, because NetworkManager
is not looking for config files there.

In meson.build, we have:
  nm_pkglibdir = join_paths(nm_prefix, 'lib', nm_name)
  config_extra_h.set_quoted('NMLIBDIR',          nm_pkglibdir)

It's clear that the configuration directory should be
nonarch_libdir instead of libdir.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
(cherry picked from commit 15893f46f8af8c91d922fa41f9a1f537d92aeb9a)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
2022-12-20 10:47:41 -05:00
Chen Qi
971a33338f networkmanager: fix dhcpcd PACKAGECONFIG
Without this patch, even if dhcpcd is enabled, the NetworkManager
cannot find it. Below are the messages from NetworkMananger:

  dhcp: init: DHCP client 'dhcpcd' not available
  dhcp: init: Using DHCP client 'internal'

The problem is that dhcpcd needs to be specified as a path, otherwise
NetworkManager tries to find it in /usr/sbin/dhcpcd.

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
(cherry picked from commit 178123a0066c40db1e75d018dc65f056fb03b826)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
2022-12-20 10:47:16 -05:00
Adrian Freihofer
9e4d107f6a networkmanager: update 1.38.0 -> 1.40.0
NetworkManager:
* Drop unused, internal systemd DHCPv4 client. This is long
  replaced by nettools' n-dhcp4 implementation.
* The nmcli command now supports --offline argument with "add" and
  "modify" commands, allowing operation on keyfile-formatted connection
  profiles without the service running (e.g. during system provisioning).
* The device state file /run/NetworkManager/devices/$ifindex now has
  new sections [dhcp4] and [dhcp6] containing the DHCP options for the
  current lease.
* Add multipath TCP (MPTCP) support. NetworkManager can now configure IP addresses
  as MPTCP endpoints. This is configurable via the "connection.mptcp-flags"
  property. The default setting is such that MPTCP handling is automatically
  enabled if the kernel sysctl "/proc/sys/net/mptcp/enabled" indicates so.
  NetworkManager does not enable the MPTCP sysctl or adjust the limits (ip mptcp limits).
  The administrator or the distribution is supposed to configure the desired system
  settings.
  Note that strict reverse path filtering (rp_filter) breaks many MPTCP use cases.
  With MPTCP handling enabled, NetworkManager will relax a strict (1) rp_filter
  to loose (2). Otherwise rp_filter is untouched by NetworkManager.
* NetworkManager expanded log messages for invalid DHCP options.
* Fix the requirement of hardware address for DHCPv6, by dropping it.
* Increase the PMK lifetime for Wi-Fi connections using WPA-EAP.
* "nmcli networking off" now waits for deactivations to complete.
* Improve the appearance of nm-settings-nmcli man page by preserving
  paragraphs.
* Support enabling ipv4ll alongside DHCPv4 and static addressing.
* Support configuring "ipv6.mtu".
* Honor "nm.debug" kernel command line to enable debug logging of
  NetworkManager.
* NetworkManager reads the kernel command line "/proc/cmdline" for several
  purposes, including "nm.debug" for enabling debugging and the
  "match.kernel-command-line" setting in the profile. NetworkManager now
  first looks now for "/run/NetworkManager/proc-cmdline", which allows to
  overwrite the command line.
* Improve the reapply of non-bridge properties.
* Honor adding a Bluetooth NAP connection with all available methods.
* Improve carrier detection.
* During the build, stop relying on intltool for i18n and use gettext only.
* Undeprecate nm_remote_connection_get_secrets() in libnm.
* NetworkManager now will restart DHCP if the MAC changes on a device.
* Several internal improvements.

Recipe:
* Drop the last patch :-). -Difcfg_rh=false is now honored and the
  distro detection patch is no longer needed.
* Fix: move /etc/resolv-conf.NetworkManager to daemon package
* Fix: remove ppp rdepends from daemon. The ppp plugin rdepends on ppp.
* ifupdown plugin requires now bash not sh. But the ifupdown is an
  optional plugin anyway.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
2022-08-29 13:07:18 -07:00