Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Jan 2018 13:43:56 +0100
From:      Thomas Steen Rasmussen <thomas@gibfest.dk>
To:        freebsd-net@freebsd.org
Subject:   Help finding a pcb id
Message-ID:  <84c785a2-cf14-3921-797b-6e4157566f3b@gibfest.dk>

next in thread | raw e-mail | index | archive | help
Hello list,

I have a jailhost with a busy TCP service which sometimes cannot keep
up, triggering the usual "listen queue overflow" messages most of you
will have seen at some point:

kernel: sonewconn: pcb 0xfffff803f327a1d0: Listen queue overflow: 193
already in queue awaiting acceptance (1169 occurrences)
kernel: sonewconn: pcb 0xfffff8031b131740: Listen queue overflow: 193
already in queue awaiting acceptance (1068 occurrences)

These two pcb id's are repeating warnings:

$ cat /var/log/messages | cut -w -f 8 | sort | uniq -c
 142 0xfffff8031b131740:
 483 0xfffff803f327a1d0:

Through elimination I know which two listening TCP ports/services are
causing the warnings. But I can't get the pcb id to match.

Usually I would find the listening socket with netstat -Aan but the
listening sockets causing these warnings have different pcb ids in the
netstat output:

fffff80319ff5000 tcp4       0      0 185.96.180.29.9091
*.*                LISTEN
fffff80319e19410 tcp4       0      0 185.96.180.29.9090
*.*                LISTEN

What am I missing? What is the correct way to match the pcb id from
messages to a process/listening socket?

Could this be because of these pf rdr rules? Does a pf rdr create a new
pcb id which is "invisible" to netstat?

rdr on $if inet proto tcp from any to $tor6v4 port 443 -> $tor6v4 port 9090
rdr on $if inet proto tcp from any to $tor6v4 port 80 -> $tor6v4 port 9091

On a more general note I am wondering is if it would be possible to log
some more info from the socket around line 600 of sys/kern/uipc_socket.c?

Local (and remote where relevant) address/port/or whatever relevant for
the protocol, and perhaps also pid and jid? More info would make things
a lot easier on busy jailhosts :) The cause of "listen queue overflow"
messages can be almost impossible to find if the process/socket is
short-lived.

Thank you in advance for any input!


Best regards,

Thomas Steen Rasmussen





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84c785a2-cf14-3921-797b-6e4157566f3b>