When bringing up an interface, e.g. /etc/init.d/net.enp4s1 start, I get a lease (rebind, solicit, probe, then leased), but then get: ipv4_addaddr: ifaddaddress: Invalid argument then no IPv6 routers available (which is expected). then: timed out dhcpcd exited. This fails with net-misc/dhcpcd-7.0.1 and version 7.0.0. Reverting to version 6.11.5 worked.
What kernel are you using?
3.9.11-gentoo-r1. i'm stuck with an older one due to an nvidia driver + old card issue.
Created attachment 520094 [details, diff] Disable IFA_F_NOPREFIXROUTE for kernels older than 4.3.0 Can you test this dhcpcd patch please? It assumes that your kernel headers match your kernel version.
Created attachment 520096 [details, diff] Disable IFA_F_NOPREFIXROUTE for kernels older than 4.3.0
Hmm, that won't work as IFA_F_NOPREFIXROUTE was introduced in 3.14 kernel. So basicaly your kernel headers are newer than your running kernel. You should probably ensure that they match and rebuild userland accordingly then this error should go away.
Sounds good, thanks!
(In reply to Roy Marples from comment #5) > Hmm, that won't work as IFA_F_NOPREFIXROUTE was introduced in 3.14 kernel. > So basicaly your kernel headers are newer than your running kernel. > > You should probably ensure that they match and rebuild userland accordingly > then this error should go away. But this is supported (newer kernel headers than running kernel). Can't you detect this at runtime in dhcpcd like https://lists.freedesktop.org/archives/systemd-devel/2015-April/030473.html ?
(In reply to Thomas Deutschmann from comment #7) > But this is supported (newer kernel headers than running kernel). Who by? Certainily not me. If by Gentoo then certainly provide patches. > Can't you detect this at runtime in dhcpcd like > https://lists.freedesktop.org/archives/systemd-devel/2015-April/030473.html ? That's a fairly big hammer approach. If ioctl (or netlink in this case) fails, strip features until it works. Sadly, that just doesn't work for dhcpcd. IFA_F_NOPREFIXROUTE means we don't have to guess about prefix routes and thanks to various kernels we don't know for sure which route kernel added so we have to "guess". This really sucks for me down stream dealing with issues such as "dhcpcd messed my routing table" or "dhcpcd won't install the correct routes". So here's the deal, you want to support newer headers on old versions? Fine. I'll stop supporting dhcpcd in Gentoo. This might sound harsh, but I've been bitten too much with header mismatch on various Linux platforms mainly ArchLinux and mainly on ARM, rPI and other non mainstream systems for other issues.
(In reply to Roy Marples from comment #8) > Who by? Certainily not me. > If by Gentoo then certainly provide patches. Yes, it is supported by Gentoo, and the Linux community in general.
I don't know about the entire Linux community supporting that. I see the various places online where Gentoo [https://wiki.gentoo.org/wiki/Linux-headers] and Glibc [https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F] support it. The kernel itself [https://www.kernel.org/doc/Documentation/kbuild/headers_install.txt] doesn't state an expectation, but that "... a program built against newer kernel headers may not work on an older kernel." But in lieu of resolving that debate, would it be possible to detect the kernel at runtime and conditionally run the code protected by ifdef IFA_F_NOPREFIXROUTE? That seems cleaner than the "fail, strip features, and try again" approach. If Roy would accept such a patch, then the Gentoo folks or I could provide it. But if not, then no big deal. From my end-user perspective, it's not a big deal. I already have to mask a few packages from upgrading due to the lousy video card and drivers. I could just mask the new kernel headers too until I buy a new card or something.
(In reply to brho from comment #10) > But in lieu of resolving that debate, would it be possible to detect the > kernel at runtime and conditionally run the code protected by ifdef > IFA_F_NOPREFIXROUTE? That seems cleaner than the "fail, strip features, and > try again" approach. Yes, that does seem cleaner at first glance. However, the version number is not a reliable indicator of supported features. Other distros like to backport major features into their kernel patchsets.
(In reply to Mike Gilbert from comment #9) > (In reply to Roy Marples from comment #8) > > Who by? Certainily not me. > > If by Gentoo then certainly provide patches. > > Yes, it is supported by Gentoo, and the Linux community in general. Great. I'll be sure too pass any address or routing issues in dhcpcd from Gentoo users your way then :) (In reply to brho from comment #10) > I don't know about the entire Linux community supporting that. I see the > various places online where Gentoo > [https://wiki.gentoo.org/wiki/Linux-headers] and Glibc > [https://sourceware.org/glibc/wiki/ > FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F] support it. > > The kernel itself > [https://www.kernel.org/doc/Documentation/kbuild/headers_install.txt] > doesn't state an expectation, but that "... a program built against newer > kernel headers may not work on an older kernel." FWIW I agree with you whole heartedly. As dhcpcd in this instance is talking directly to the kernel and bypassing libc. I kinda favour the kernel team argument. Also, as a compatibility hacker on NetBSD kernel networking I am also quite biased as well. > But in lieu of resolving that debate, would it be possible to detect the > kernel at runtime and conditionally run the code protected by ifdef > IFA_F_NOPREFIXROUTE? That seems cleaner than the "fail, strip features, and > try again" approach. No, this would not fly. While I disagree with Mike for the most part, backporting features is a lot more commonplace than using newer headers, than the running kernel. Roy
Since we are talking directly to the kernel, bypassing libc, I tend to agree with Roy and the kernel team on this. Thanks, William
I am closing this as invalid due to no more comments or suggestions. There is really not anything I can do at this point, just make sure you have the correct linux-headers installed.
