Strange sockstat entries

[Doug Hardie]

I am seeing a number of unusual sockstat entries that look like:

?? ?? ?? ?? tcp4 10.0.1.230:587 178.16.54.22:63001

The occur at the end of the output. Often there are about 10 or so entries. Most of them vanish after a few seconds. However, two are quite persistent. What causes this type of entry?

-- Doug

[John Levine]

Port 587 is mail submission, so that's a spambot trying to break into your mail server.

I see lots of them on my submission server. Unless you have usernames and passwords that are trivially guessable,
they shouldn't be a problem.

I also see them on port 25 so I added a feature to my mail server so that AUTH on port 25 always succeeds, and
it puts the mail they try to send into the spam trap. I get far more of those.

--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[Doug Hardie]

> On Feb 6, 2026, at 14:07, John Levine <jo...@iecc.com> wrote:
>
> It appears that Doug Hardie <bc...@lafn.org> said:
>> I am seeing a number of unusual sockstat entries that look like:
>>
>> ?? ?? ?? ?? tcp4 10.0.1.230:587 178.16.54.22:63001
>>
>> The occur at the end of the output. Often there are about 10 or so entries. Most of them vanish after a few seconds. However, two are quite persistent. What
>> causes this type of entry?
>
> Port 587 is mail submission, so that's a spambot trying to break into your mail server.
>
> I see lots of them on my submission server. Unless you have usernames and passwords that are trivially guessable,
> they shouldn't be a problem.
>
> I also see them on port 25 so I added a feature to my mail server so that AUTH on port 25 always succeeds, and
> it puts the mail they try to send into the spam trap. I get far more of those.

That's the case for why the connection was originally established. However, many of them are not that. They are between my Freebsd servers. Those are not attacking. The real question is why those 4 sets of ?? instead of real values. What is causing that.

-- Doug

[Dag-Erling Smørgrav]

sockstat works by retrieving and cross-referencing information from two
separate lists, one that ties sockets to processes and another that ties
sockets to connections. If a socket is opened or closed while sockstat
is working, it may show up in one list but not in the other. It might
be better to drop incomplete entries by default.

Note that sockets owned by the kernel (e.g. NFS) will never show up in
the list of processes. Perhaps we should arrange things so they show up
with PID and UID 0.

DES
--
Dag-Erling Smørgrav - d...@FreeBSD.org

[Doug Hardie]

Thanks for the information.  That makes sense now.  I would think it would be better to not include the ?? ?? entries, but I can live with either approach now that I know what they mean.

I did find one unexpected case where sockstat shows 32K entries for blacklistd.  I find that quite unexpected as pftop only shows 26 entries for everything.  netstat shows the same 32K entries so those must be established connections.  Why are they still open when pftop doesn't show them.  I would think that would mean they were closed.  I would expect that having that many open connections would slow down the system.

-- Doug

[Doug Hardie]

On Feb 7, 2026, at 03:23, Dag-Erling Smørgrav <d...@freebsd.org> wrote:

Thanks for the information.  That makes sense now.  I would think it would be better to not include the ?? ?? entries, but I can live with either approach now that I know what they mean.

I did find one unexpected case where sockstat shows 32K entries for blacklistd.  I find that quite unexpected as pftop only shows 26 entries for everything.  netstat shows the same 32K entries so those must be established connections.  Why are they still open when pftop doesn't show them.  I would think that would mean they were closed.  I would expect that having that many open connections would slow down the system.

Some additional information: netstat -s shows:

TCP connection count by state:

31799 connections in CLOSED state

17 connections in LISTEN state

0 connections in SYN_SENT state

0 connections in SYN_RCVD state

23 connections in ESTABLISHED state

298 connections in CLOSE_WAIT state

0 connections in FIN_WAIT_1 state

0 connections in CLOSING state

1 connection  in LAST_ACK state

0 connections in FIN_WAIT_2 state

0 connections in TIME_WAIT state

Why do closed connections stick around?

-- Doug

[Dewayne Geraghty]

As mysterious as ?? appears in sockstat output it may convey a problem
that is occurring between the synchronisation of the two source lists.

Wouldn't displaying sockets owned by the kernel also be helpful in
diagnosing connection issues? It would be helpful to appear as PID/UID=0.

An aside, when the kernel is involved in TLS negotiation, does the
socket (currently) remain hidden until its handed to the process?

Dewayne

[Dag-Erling Smørgrav]

Dewayne Geraghty <dew...@heuristicsystems.com.au> writes:
> As mysterious as ?? appears in sockstat output it may convey a problem
> that is occurring between the synchronisation of the two source lists.
>
> Wouldn't displaying sockets owned by the kernel also be helpful in
> diagnosing connection issues? It would be helpful to appear as
> PID/UID=0.

Why are you repeating what I wrote four days ago back to me?

> An aside, when the kernel is involved in TLS negotiation, does the
> socket (currently) remain hidden until its handed to the process?

No.