Score:3

netstat reports UDP ports with no owning process

cn flag

When I run netstat -avp udp I get a slowly growing number of ports. It grows about 100 an hour but the rate varies considerably.

When I close the process, the ports do not disappear from the list. Similarly when I kill the process. Restarting the machine obviously resets the list but it just grows again. I have multiple machines showing the same symptom.

The majority of the ports listed are associated with mDNSResponder, but I think that is irrelevant as the issue is also associated with Chrome, Outlook and other programs.

After some time network access becomes compromised, presumably due to the exhaustion of ports in the 49000-65000 range where most of the UDP ports are allocated.

Running lsof -iUDP -n shows a mere 30 UDP ports, when netstat is reporting thousands.

The machines are iMac's running MacOS Monterey 12.0.1 and report that they are fully up to date with patches.

This is what the first few lines of netstat's output looks like:

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)     rhiwat shiwat    pid   epid  state    options
udp4       0      0  *.55317                *.*                                786896   9216    238  62261 0x0103 0x00010000
udp4       0      0  *.62074                *.*                                786896   9216    238    577 0x0103 0x00010000
udp4       0      0  *.51635                *.*                                786896   9216    238    301 0x0103 0x00010000
udp4       0      0  *.54799                *.*                                786896   9216    238    301 0x0103 0x00010000
udp4       0      0  *.57143                *.*                                786896   9216    238    301 0x0103 0x00010000
udp4       0      0  *.56933                *.*                                786896   9216    238    301 0x0103 0x00010000
udp4       0      0  *.51250                *.*                                786896   9216    238  63527 0x0103 0x00010000
udp4       0      0  *.61138                *.*                                786896   9216    238  63527 0x0103 0x00010000

The man page for netstat does not tell me what the right hand columns refer to I can guess that pid is "process ID", epid is "effective process ID" but what are rhiwat, shiwat, state and options and are they useful in resolving this issue?

I would appreciate any suggestion on how to proceed with investigating why these mac's appear to have an ever growing number of UDP sockets.

pw flag
I have the exact same issue, a shame that there is no answer @simon-g did you solve this?
cn flag
@AlexanderStolz - I did not solve it. One day it just stopped happening. I assumed that the issue had been patched by an automatic update.
Score:1
us flag

I am seeing the same thing (Monterey 12.1). The problem went away after upgrading to Montery 12.2.1.

Using 12.1, netstat -n -p udp | wc -l grows by 30 lines every minute. After four days my system becomes slow and I start getting isc_socket_bind: address not available errors. sudo lsof -nP -iUDP | wc -l does not grow.

After about four days:

nslookup www.ibm.com
nslookup: isc_socket_bind: address not available

Discussion on Reddit speculates Cisco AnyConnect is to blame. I am running Cisco AnyConnect.

I am still running Cisco AnyConnect with 12.2.1 and the problem seems to be resolved.

Score:1
in flag
BAQ

There is speculation that this problem was introduced by Apple with Monterey.

My personal experience is uninstalling the socket filter for Cisco Anyconnect is an effective work around until Apple releases a fix. It does not appear to impact the operation of the VPN, however you will want to check with your companies security folks before making such a change.

Note: After a reboot the Anyconnect socket filter will be re-installed, so you will need to remove after any reboots.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.