summaryrefslogtreecommitdiffstats
path: root/meta/recipes-connectivity/dhcpcd/files/0001-20-resolv.conf-improve-the-sitation-of-working-with-.patch
Commit message (Collapse)AuthorAgeFilesLines
* dhcpcd: upgrade to v10.0.1Sudip Mukherjee2023-05-221-2/+2
| | | | | | | | | | | | | Changes: Update license checksum: change in copyright year. Rebase patches for upstream changes. Remove upstream applied patches. (From OE-Core rev: d6e1f0d5eb22c94ad1ec5eef719db00deb1fb263) Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* dhcpcd: fix to work with systemdChen Qi2022-11-221-0/+82
Currently, dhcpcd does not work well with systemd. When using dhcpcd to configure network, the /etc/resolv.conf contents are not correct. This issue could easily be reproduced by using 'qemu + slirp' to start a systemd based image and using dhcpcd to configure network. The expected 'nameserver 10.0.2.3' is not in /etc/resolv.conf. The root cause of this problem is that dhcpcd assumes the resolvconf should recognize .protocol suffix[1]. But systemd's resolvconf (which is a symlink to resolvectl) has a limited support for traditional resolvconf interface[2], and "may not work with all clients"[3]. This of cource includes the clients that use the .protocol suffix. The current situation is: 1. systemd is not going to support the .protocol suffix in the foreseeable near future[4]. 2. dhcpcd does not want to merge systemd specific patch and insists systemd needs to consider the .protocol suffix[5][6]. It's a normal thing that people have different opinions. As a build system that supports such combination, however, we do need to come up with a solution to fix this typical integration problem, making dhcpcd and systemd work together. This patch solves this integration problem by relying on dhcpcd's ability to manage its own resolv.conf contents. But instead of letting it to write to /etc/resolv.conf directly, we supply the generated contents to resolvconf. In this way, the resolvconf still stands in the central place and dhcpcd remains a supplier to it. And the /etc/resolv.conf can get the correct contents. With this patch, dhcpcd could work with both sysvinit and systemd. [1] https://man.archlinux.org/man/resolvconf.8.en [2] https://man.archlinux.org/man/resolvectl.1#COMPATIBILITY_WITH_RESOLVCONF(8) [3] https://wiki.archlinux.org/title/systemd-resolved [4] https://github.com/systemd/systemd/issues/25032 [5] https://github.com/NetworkConfiguration/dhcpcd/pull/152 [6] https://github.com/NetworkConfiguration/dhcpcd/issues/146 (From OE-Core rev: 935ae419f51d911c73f5dc7b4a2e5e9a7b206985) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>