I know this is an old thread, but in case anyone else is having the same issue, I had...
What may be happening is that your process had a TCP port open when it crashed or otherwise exited without explicitly closing it. Normally the OS cleans up these sorts of things, but only when the process record goes away. While the process may not appear to be running any more, there is at least one thing that can keep a record of it around, in order to prevent reuse of its PID. This is the existence of a child process that is not detached from the parent.
If your program spawned any processes while it was running, try killing them. That should cause its process record to be freed and the TCP port to be cleaned up. Apparently windows does this when the record is released not when the process exits as I would have expected.
Linux auditing can help. It will at least locate users and processes making datagram network connections. UDP packets are datagrams.
First, install the auditd framework on your platform and ensure that auditctl -l returns something, even if it says that no rules are defined.
Then, add a rule to watch the system call socket() and tag it for easy finding later (-k). I need to assume that you are on a 64-bit architecture, but you can substitute b32 in place of the b64 if you aren't.
auditctl -a exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
You have to pick through man pages and header files to build this, but what it captures is essentially this system call: socket(PF_INET, SOCK_DGRAM|X, Y), where the third parameter is unspecified but frequently zero. PF_INET is 2 and SOCK_DGRAM is 2. TCP connections would use SOCK_STREAM which would set a1=1. (SOCK_DGRAM in the second parameter may be ORed with SOCK_NONBLOCK or SOCK_CLOEXEC, hence the &= comparison.) The -k SOCKET is our keyword we want to use when searching audit trails later. It can be anything, but I like to keep it simple.
Let a few moments go by and review the audit trails. Optionally, you could force a couple of packets by pinging a host out on the net, which will cause a DNS lookup to occur, which uses UDP, which should trip our audit alert.
ausearch -i -ts today -k SOCKET
And output similar to the section below will appear. I'm abbreviating it to highlight the important parts
type=SYSCALL ... arch=x86_64 syscall=socket success=yes exit=1 a0=2 a1=2 ... pid=14510 ... auid=zlagtime uid=zlagtime ... euid=zlagtime ... comm=ping exe=/usr/bin/ping key=SOCKET
In the above output, we can see that the ping command caused the socket to be opened. I could then run strace -p 14510 on the process, if it was still running. The ppid (parent process ID) is also listed in case it is a script that spawns the problem child a lot.
Now, if you have a lot of UDP traffic, this isn't going to be good enough and you'll have to resort to OProfile or SystemTap, both of which are currently beyond my expertise.
This should help narrow things down in the general case.
When you are done, remove the audit rule by using the same line you used to create it, only substitute -a with -d.
auditctl -d exit,always -F arch=b64 -F a0=2 -F a1\&=2 -S socket -k SOCKET
Best Answer
Take a look at the man page, you'll find that you can use the
-poption to specify a process id, and the-ioption to limit the display to internet domain sockets (-i4for just ipv4 and-i6for just ipv6). So if you string them together......you get not quite what you want, because by default
lsofwill or together your requests. So add the-a(and) flag......and you'll get a list of the IPv4 sockets open by the specified process id.