Debian 12.5 dhcpcd 9.4.1 - non zero Recv-Q on raw sockets

[aaronriekenberg]

trafficstars

Have a machine running Debian 12.5, installed dhcpcd version 9.4.1 with apt install dhcpcd.

Have not modified the default /etc/dhcpcd.conf file. Using my home network with IPv4 and IPv6 from Google wifi.

Everything works as far as I can see. But noticing with netstat -anp that 2 Recv-Q entries for dhcpcd always seems to stay > 0 and with below 2 values (2560 and 2304). This happens even after systemctl restart dhcpcd or reboot.

Non-empty Recv-Q seems like there is some pending data in the raw sockets that dhcpcd is not reading? This seems not ideal but have not found any problems caused by this.

I can debug or provide more info as needed, just curious if this is expected or some way to avoid this. Thanks!

# netstat -anp | less
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
raw     2560      0 0.0.0.0:17              0.0.0.0:*               7           466/dhcpcd: [privil
raw6    2304      0 :::17                   :::*                    7           466/dhcpcd: [privil

More info for PID 466 in this example:

# ps -ef | grep 466
root         466     465  0 12:01 ?        00:00:00 dhcpcd: [privileged proxy]

Version info:

$ cat /etc/debian_version
12.5

$ /usr/sbin/dhcpcd --version
dhcpcd 9.4.1
Copyright (c) 2006-2021 Roy Marples
Compiled in features: INET ARP ARPing IPv4LL INET6 DHCPv6 AUTH PRIVSEP

[rsmarples]

in privsep dhcpcd uses the raw sockets for sending from an address without having to bind to it. It doesn't actually read from the raw socket itself.

We could drain it, but that would just cycle more CPU. Do you think this would be a better behavior?

[aaronriekenberg]

Thank you for the explanation!

[DanielG]

On Mon, Mar 11, 2024 at 03:16:31AM -0700, Roy Marples wrote:

in privsep dhcpcd uses the raw sockets for sending from an address without having to bind to it. It doesn't actually read from the raw socket itself.

We could drain it, but that would just cycle more CPU. Do you think this would be a better behavior?

Sounds to me like as-is it's consuming memory instead. Not sure that's better :)

Would it not be possible to install a BPF filter that just rejects all incoming packets on that socket if we're never going to read them?

--Daniel

[rsmarples]

On Mon, Mar 11, 2024 at 03:16:31AM -0700, Roy Marples wrote: in privsep dhcpcd uses the raw sockets for sending from an address without having to bind to it. It doesn't actually read from the raw socket itself. We could drain it, but that would just cycle more CPU. Do you think this would be a better behavior? Sounds to me like as-is it's consuming memory instead. Not sure that's better :) Would it not be possible to install a BPF filter that just rejects all incoming packets on that socket if we're never going to read them?

Isn't a BPF socket a separate entity? The data is still read on other sockets just fine. Just the raw data isn't delivered.

I did experiment with setting a small buffer size on the socket, but that didn't seem to have any effect so I left it as is. On BSD at least, a kernel buffer is allocated to the each socket for userland to read from. Draining the queued data does not release the buffer allocation, so there is no extra memory consumed by not draining. If the buffer gets too full it just overflows. I assume Linux is similar in this regard.

With dhcpcd-11 and #271 we might not need raw sockets at all so this might just go away.