Re: Raw and Raw6 sockets bound to port 17?
Roy Marples
Sun Aug 16 18:56:30 2020
Hi Murray
On 16/08/2020 03:43, Murray wrote:
Hello,
Please pardon me if this issue is covered elsewhere, but I've been unable to
find information regarding it. Recently I noticed that on my local Linux
desktop, dhcpcd is binding raw sockets to both IPv4 and IPv6 port 17, and
appears to never (or very rarely) check what it receives on that port (my basis
for this statement is that the RECV QUEUE, as shown by `netstat`, is enormous).
I checked the local configuration files and didn't see anything odd, nor did I
notice anything in the systemd unit files that would explain the behavior.
Google also wasn't of much help, and port 17 appears to be a throwback to the
quote of the day on UNIX systems. The DHCP server on my local network is a
standard ISP provided wireless router, but as the customer, I certainly don't
have access to any configuration options that would cause this.
My interest here is primarily understanding why I haven't always seen this
behavior, and what specifically is causing the program to use raw sockets and
bind to a mysterious port (whether specific to dhcpcd or the DHCP protocol
itself). I took a snapshot of the system memory, and the output of Volatility's
"netstat" command is shown below (`netstat` on a live system showed raw
sockets). Can anybody explain what I'm seeing, or perhaps point me in the
direction of documentation that can?
UDP 0.0.0.0 : 0 0.0.0.0 : 0
dhcpcd/599
UDP 0.0.0.0 : 17 0.0.0.0 : 0
dhcpcd/600
UNIX 21919 dhcpcd/600
UDP :: : 17 :: : 0
dhcpcd/600
UNIX 14249 dhcpcd/600
UNIX 20322 dhcpcd/600
UNIX 14251 dhcpcd/600
UDP 0.0.0.0 : 68 0.0.0.0 : 0
dhcpcd/601
UNIX 21919 dhcpcd/601
UDP :: : 546 :: : 0
dhcpcd/601
UDP 0.0.0.0 : 17 0.0.0.0 : 0
dhcpcd/683
UNIX 21919 dhcpcd/683
UDP :: : 17 :: : 0
dhcpcd/683
So you're not seeing port 17. Here's my system:
# netstat -pln | grep dhcpcd
udp 0 0 0.0.0.0:68 0.0.0.0:*
3419/dhcpcd: [netwo
udp6 0 0 :::546 :::*
3419/dhcpcd: [netwo
raw 214784 0 0.0.0.0:17 0.0.0.0:* 7
3418/dhcpcd: [privi
raw6 24960 0 :::17 :::* 7
3418/dhcpcd: [privi
raw6 0 0 :::58 :::* 7
3418/dhcpcd: [privi
raw6 0 0 :::58 :::* 7
3419/dhcpcd: [netwo
unix 2 [ ACC ] STREAM LISTENING 17825 3420/dhcpcd: [contr
/var/run/dhcpcd/sock
unix 2 [ ACC ] STREAM LISTENING 17827 3420/dhcpcd: [contr
/var/run/dhcpcd/unpriv.sock
Same command, but minus the -n flag
# netstat -pl | grep dhcpcd
udp 0 0 0.0.0.0:bootpc 0.0.0.0:*
3419/dhcpcd: [netwo
udp6 0 0 [::]:dhcpv6-client [::]:*
3419/dhcpcd: [netwo
raw 214784 0 0.0.0.0:udp 0.0.0.0:* 7
3418/dhcpcd: [privi
raw6 14208 0 [::]:udp [::]:* 7
3418/dhcpcd: [privi
raw6 0 0 [::]:ipv6-icmp [::]:* 7
3418/dhcpcd: [privi
raw6 0 0 [::]:ipv6-icmp [::]:* 7
3419/dhcpcd: [netwo
unix 2 [ ACC ] STREAM LISTENING 17825 3420/dhcpcd: [contr
/var/run/dhcpcd/sock
unix 2 [ ACC ] STREAM LISTENING 17827 3420/dhcpcd: [contr
/var/run/dhcpcd/unpriv.sock
So this shows that raw socks show the protocol (and protocol number) rather than
the port because raw sockets are typically not bound to any port.
In the new priviledge separation mode, dhcpcd creates bound ports for listening.
For sending we create a raw socket in the privileged process so it doens't
conflict with the listening port in the unprivileged process.
The main reason for this is because it's demanded by FreeBSD's capsicum sandbox
(you can't send on unconnected sockets in capsicum mode), but as it turned out
it allowed for a cleaner code path for both priviledged separation AND the non
separated variant.
Anyway, I've commited this patch:
https://roy.marples.name/cgit/dhcpcd.git/commit/?id=f4955ed46d5cd0434039ced42a18d9c202fd29f3
It reduces the size of the receive buffer to as much as the kernel allows and
show the receive-q numbers you see shouldn't get too high - my limited local
testing showed none got beyond 5000. Let me know if this improves it for you.
Roy
Archive administrator: postmaster@marples.name