The problem with tools like
lsof is that these work on snapshots of the network state. Connections that are reset during the setup will not show up with high probability.
While Wireshark can capture the TCP packets, it will not be able to tell the process ID that was responsible for it. This information is not provided in a normal Ethernet capture. There is a different mechanism (NFLOG) that can log packets as seen by Netfilter (iptables), but this may at most contain the User ID of the process that generated a packet.
One approach to tackle the issue is by stalling or completely dropping network traffic.
- Using Wireshark, you could for example determine that the port range is within 5037-5585.
Add a new firewall rule that drops newly initiated TCP traffic to the loopback interface for that port range:
sudo iptables -I INPUT -p tcp -i lo --dport 5037:5585 --syn -j DROP
Now you can use netstat, ss, etc. to find the offending program. For example:
sudo ss -tapn | grep '5[0-5]'
When done, remove the firewall rule again such that new connections can occur:
sudo iptables -D INPUT -p tcp -i lo --dport 5037:5585 --syn -j DROP
I used this approach to identify that the ADB daemon was trying to connect all the time to some local ports, presumably to locate an Android simulator.