dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

chrisdb · 2019-11-21 20:26:27

hello,

Since my last system update I get the following error from my journal (linux-lts):

Nov 21 20:55:41 myarch dhcpcd[346]: if_sendnetlink: NETLINK_GET_STRICT_CHK: Protocol not available

THis is the status from systemctl:

● dhcpcd.service - dhcpcd on all interfaces
   Loaded: loaded (/usr/lib/systemd/system/dhcpcd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2019-11-21 21:19:13 CET; 1min 10s ago
  Process: 347 ExecStart=/usr/bin/dhcpcd -q -b (code=exited, status=0/SUCCESS)
 Main PID: 353 (dhcpcd)
    Tasks: 1 (limit: 4915)
   Memory: 3.8M
   CGroup: /system.slice/dhcpcd.service
           └─353 dhcpcd: [master] [ip4] [ip6]

Nov 21 21:19:20 myarch dhcpcd[353]: wlp1s0: requesting DHCPv6 information
Nov 21 21:19:20 myarch dhcpcd[353]: wlp1s0: fe80::5e35:3bff:feb8:bc6d is reachable again
Nov 21 21:19:20 myarch dhcpcd[353]: wlp1s0: adding default route via fe80::5e35:3bff:feb8:bc6d
Nov 21 21:19:24 myarch dhcpcd[353]: wlp1s0: leased 192.168.0.130 for 3600 seconds
Nov 21 21:19:24 myarch dhcpcd[353]: wlp1s0: adding route to 192.168.0.0/24
Nov 21 21:19:24 myarch dhcpcd[353]: wlp1s0: adding default route via 192.168.0.1
Nov 21 21:19:24 myarch dhcpcd[353]: if_sendnetlink: NETLINK_GET_STRICT_CHK: Protocol not available
Nov 21 21:19:30 myarch dhcpcd[353]: wlp1s0: failed to request information
Nov 21 21:19:30 myarch dhcpcd[353]: wlp1s0: fe80::5e35:3bff:feb8:bc6d is reachable again
Nov 21 21:19:30 myarch dhcpcd[353]: wlp1s0: fe80::5e35:3bff:feb8:bc6d is reachable again

output of ip addr:

3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 64:6e:69:e5:77:e7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.130/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp1s0
       valid_lft 3445sec preferred_lft 2995sec
    inet6 2a02:1811:e502:f000:9bf6:92f1:804e:2fdd/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 596655sec preferred_lft 78255sec
    inet6 fe80::9596:fe5e:cd0d:8689/64 scope link 
       valid_lft forever preferred_lft forever

I only have this with the linux-lts version, not the main version.
The strange thing is my connection works fine.
What could be wrong?

I just want to get a clean journal

rsmarples · 2019-11-22 13:34:17

https://roy.marples.name/cgit/dhcpcd.gi … nux.c#n928

Basically dhcpcd was compiled using kernel headers for a newer kernel than you're actually running.
Try upgrading your kernel.

seth · 2019-11-22 14:49:35

OP wrote:

I only have this with the linux-lts version, not the main version.

The symbol was renamed in late 2018, right after the 4.19 series was released: https://www.mail-archive.com/netdev@vge … 73225.html so one would have to compile dhcpcd against the lts kernel and keep two different versions…

rsmarples · 2019-11-22 17:24:03

seth wrote:

OP wrote:
I only have this with the linux-lts version, not the main version.
The symbol was renamed in late 2018, right after the 4.19 series was released: https://www.mail-archive.com/netdev@vge … 73225.html so one would have to compile dhcpcd against the lts kernel and keep two different versions…

That's not right. Even if renamed, the code path will still work because the numeric value of the symbol hasn't changed.
Here's the commit which added it: https://github.com/torvalds/linux/commi … 911baebc66
So it was added for 4.20 and the newest arch LTS kernel is 4.14

In other words, the system headers dhcpcd was compiled for do not match the running kernel.
Either recompile dhcpcd using older kernel header, upgrade the kernel or patch dhcpcd not to use the option.

It's only a minor optimisation really - unless you have many interfaces or many addresses you don't need it.

chrisdb · 2019-11-23 12:54:48

rsmarples wrote:

seth wrote:
OP wrote:
I only have this with the linux-lts version, not the main version.
The symbol was renamed in late 2018, right after the 4.19 series was released: https://www.mail-archive.com/netdev@vge … 73225.html so one would have to compile dhcpcd against the lts kernel and keep two different versions…
That's not right. Even if renamed, the code path will still work because the numeric value of the symbol hasn't changed.
Here's the commit which added it: https://github.com/torvalds/linux/commi … 911baebc66
So it was added for 4.20 and the newest arch LTS kernel is 4.14
In other words, the system headers dhcpcd was compiled for do not match the running kernel.
Either recompile dhcpcd using older kernel header, upgrade the kernel or patch dhcpcd not to use the option.
It's only a minor optimisation really - unless you have many interfaces or many addresses you don't need it.

Ok thank you

So what's the use of this option exactly?

**Edit: just read your link and it explains it
I would not know how to create a patch though..

Last edited by chrisdb (2019-11-23 13:02:32)

rsmarples · 2019-11-25 03:54:15

diff --git a/src/if-linux.c b/src/if-linux.c
index b57f36fa..adf7f766 100644
--- a/src/if-linux.c
+++ b/src/if-linux.c
@@ -925,6 +925,7 @@ if_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, struct nlmsghdr *hdr,
 	if ((s = if_linksocket(&snl, protocol)) == -1)
 		return -1;
 
+#if 0 /* Disable for old kernels and new headers */
 #ifdef NETLINK_GET_STRICT_CHK
 	if (hdr->nlmsg_type == RTM_GETADDR) {
 		int on = 1;
@@ -933,6 +934,7 @@ if_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, struct nlmsghdr *hdr,
 		    &on, sizeof(on)) == -1)
 			logerr("%s: NETLINK_GET_STRICT_CHK", __func__);
 	}
+#endif
 #endif
 
 	/* Request a reply */

Akusari · 2019-11-25 09:34:29

I have the same problem and i'm using the Arch LTS kernel (build on my own). I can understand that the focus is on the current available kernel. Well, it's a rolling-release thing. ;-)
As a software developer i would say that's definely a task for the userland tools, in this case dhcpcd daemon, to support any kind of kernel versions. It's basicly not an good idea to dedicate such things on compile time. The better solution is to do this on runtime. It should be no problem to request the kernel version and use the old or new "wording". It's just a define renaming so far as i know. I was trying to download the sources already. but unfortunately the domain no longer exist. :-(
(Link: https://roy.marples.name/downloads/dhcp … .2.tar.xz)

rsmarples · 2019-11-25 11:43:25

Akusari wrote:

I have the same problem and i'm using the Arch LTS kernel (build on my own). I can understand that the focus is on the current available kernel. Well, it's a rolling-release thing. ;-)
As a software developer i would say that's definely a task for the userland tools, in this case dhcpcd daemon, to support any kind of kernel versions. It's basicly not an good idea to dedicate such things on compile time. The better solution is to do this on runtime. It should be no problem to request the kernel version and use the old or new "wording".

As a software developer whose beard is quite grey, I disagree.

I *could* use the linux version kernel macro at compile time or I *could* detect the kernel version at runtime.
This tells me nothing - the end user could be running a custom patch just to get this feature into an older version.

I *could* detect an error at runtime and choose to ignore some errors, but what if I'm the above user trying to get this working on an older kernel? I *want* all errors logged to ensure it works smoothly.

It's just a define renaming so far as i know.

No, it's not. The whole feature is missing from the LTS kernel, but the headers claim otherwise.

I was trying to download the sources already. but unfortunately the domain no longer exist. :-(
(Link: https://roy.marples.name/downloads/dhcp … .2.tar.xz)

Your URL is wrong - there should not be a round bracket at the end.

https://roy.marples.name/downloads/dhcp … 1.2.tar.xz
Works fine for me.

Akusari · 2019-11-25 23:20:08

rsmarples wrote:

I *could* use the linux version kernel macro at compile time or I *could* detect the kernel version at runtime.
This tells me nothing - the end user could be running a custom patch just to get this feature into an older version.

That's basicly the wrong way of concept. Yes, the user could have this or that - right! But is this a reason to ignore the highest possibility ?
99,9% of the users out there will use a standard kernel shipped with the linux distribution.

Your URL is wrong - there should not be a round bracket at the end.

The URL is correct. I tested it without brackets before. Look at the start at this text line. ;-)
But a funny thing is, that i test it again and my ISP DNS-Server found your domain, but my standard google DNS does not.
Faulty Google DNS. :-/

[daniel@Homer]~$ nslookup roy.marples.name
;; Got SERVFAIL reply from 8.8.8.8, trying next server
;; Got SERVFAIL reply from 8.8.4.4, trying next server
Server:		2001:4860:4860::8888
Address:	2001:4860:4860::8888#53

** server can't find roy.marples.name: SERVFAIL

[daniel@Homer]~$ nslookup 
> server 192.168.178.1
Default server: 192.168.178.1
Address: 192.168.178.1#53
> roy.marples.name
Server:		192.168.178.1
Address:	192.168.178.1#53

Non-authoritative answer:
roy.marples.name	canonical name = xenity.marples.name.
Name:	xenity.marples.name
Address: 81.108.15.115
Name:	xenity.marples.name
Address: 2001:470:690c:1::6

Akusari · 2019-11-26 11:23:02

chrisdb wrote:

I just want to get a clean journal :)

You have two possibilities:

a) Just downgrade your dhcpcd package to version 7.2.2-1 with pacman -U and wait until kernel 5.4 will be released as the new LTS kernel.
Probably this happen around feburar/march 2020.

b) Change your dhcp client to the ISC dhclient package. https://www.archlinux.org/packages/extr … 4/dhclient

This client is pretty good as well and it has the same support options.
It's shipped with the arch iso as well and in my opinion it's more a matter of taste which one do you prefer. :-)

rsmarples · 2019-11-26 12:46:48

Akusari wrote:

rsmarples wrote:
I *could* use the linux version kernel macro at compile time or I *could* detect the kernel version at runtime.
This tells me nothing - the end user could be running a custom patch just to get this feature into an older version.
That's basicly the wrong way of concept. Yes, the user could have this or that - right! But is this a reason to ignore the highest possibility ?
99,9% of the users out there will use a standard kernel shipped with the linux distribution.

OR Arch can do it right and have package repos per LTS so that they compile with the right headers.
What is even more crazy is this: https://www.archlinux.org/packages/core … s-headers/
So the Arch LTS headers are newer than any Arch LTS kernel. Crazy.
It could be argued that they should match the lowest supported LTS kernel.

I'll note that other LTS based distros do not have this issue.

Pretty sure most Arch users don't use LTS though, otherwise this issue would be more prevalent.
The highest default possibility is the user has matched headers and kernel.

Your URL is wrong - there should not be a round bracket at the end.
The URL is correct. I tested it without brackets before. Look at the start at this text line. ;-)

The actual link in your post definitely has the bracket at the end. It's wrong.

But a funny thing is, that i test it again and my ISP DNS-Server found your domain, but my standard google DNS does not.
Faulty Google DNS. :-/

[daniel@Homer]~$ nslookup roy.marples.name
;; Got SERVFAIL reply from 8.8.8.8, trying next server
;; Got SERVFAIL reply from 8.8.4.4, trying next server
Server:		2001:4860:4860::8888
Address:	2001:4860:4860::8888#53

** server can't find roy.marples.name: SERVFAIL

[daniel@Homer]~$ nslookup 
> server 192.168.178.1
Default server: 192.168.178.1
Address: 192.168.178.1#53
> roy.marples.name
Server:		192.168.178.1
Address:	192.168.178.1#53

Non-authoritative answer:
roy.marples.name	canonical name = xenity.marples.name.
Name:	xenity.marples.name
Address: 81.108.15.115
Name:	xenity.marples.name
Address: 2001:470:690c:1::6

This might have been an issue with my automated DNSSEC re-signing. I'm looking into this now.

Arch Linux

#1 2019-11-21 20:26:27

dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#2 2019-11-22 13:34:17

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#3 2019-11-22 14:49:35

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#4 2019-11-22 17:24:03

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#5 2019-11-23 12:54:48

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#6 2019-11-25 03:54:15

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#7 2019-11-25 09:34:29

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#8 2019-11-25 11:43:25

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#9 2019-11-25 23:20:08

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#10 2019-11-26 11:23:02

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

#11 2019-11-26 12:46:48

Re: dhcpcd NETLINK_GET_STRICT_CHK: Protocol not available

Board footer