Scrpt to list TCP and UDP open ports and services on AIX

OK, I made this script to list the TCP open ports and their running service

netstat -aAn|grep LISTEN|while read socket b c d puerto resto;do echo "PUERTO: "`echo $puerto|cut -f2 -d"."`  ------\>  `rmsock $socket tcpcb|sed 's/^.* \([0-9][0-9]*\)/PID \1/'`;done

Similar I made this one for UDP (but does not works, it takes toooo long time and does not show the list)
netstat -aAn|grep udp|grep "*.[0-9]"|while read socket b c d puerto resto;do echo "PUERTO: "`echo $puerto|sed s'/\*\.//'` -----\> `rmsock $socket inpcb|sed 's/^.* \([0-9][0-9]*\)/PID \1/'`;done

I know with lsof -i :$port shows the service that is listening. This could be another way...

Can you help me to improve this script to list all TCP and UDP ports and their listening's service ?

Who is Participating?

sorry for the delay, I maust have overlooked this Q, whyever.

OK, testing your scripts I realized that "read" doesn't seem to work.
Also, the many cuts and seds seem a bit overengineered.

How about just awk (well, a bit grep and even read to make it easier)?

Please have a look at my versions below.
Note that I filtered for sockets actually being held by processes, by greping rmsock's output for "held".  All other ports will just be displayed without additional output.


netstat -Aan |grep -E "\*.[0-9].+LISTEN" |awk  '{print $1, substr($5,3)}' |while read socket port
  echo "Port: " $port "--->" $(rmsock $socket tcpcb | grep held | awk -F'proccess|\\(|\\)' '{print "PID:", $2, "CMD:", $3}')

Open in new window

netstat -Aan |grep -E "udp.+\*.[0-9]" |awk  '{print $1, substr($5,3)}' |while read socket port
  echo "Port: " $port "--->" $(rmsock $socket inpcb | grep held | awk -F'proccess|\\(|\\)' '{print "PID:", $2, "CMD:", $3}')

Open in new window

sminfoAuthor Commented:
Hi wmp,

The TCP works fine, but in UDP doesn't. When I run the script it freezes, stopped and take too long to show the output, for example here the portmap daemon is not shown:

rmsock : Unable to read kernel address ffffffffffffff58, errno = 14  <-----
Port:  111 --->
Port:  161 ---> PID: 217230 CMD: snmpdv3ne
Port:  514 ---> PID: 196720 CMD: syslogd
Port:  657 ---> PID: 151802 CMD: rmcd

I see also rmsock does not have an option like timeout to make the output faster.

Any idea on how to make the UDP faster?



port 111 always gives:

"Wait for exiting processes to be cleaned up before removing the socket"

so there's nothing to display from rmsock.

As for the delay - it's not related to portmap, so what's in "netstat -Aan" just above port 111?
Maybe we must filter out some weird candidates.
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

sminfoAuthor Commented:

We used rmsock in our backup script to see what was connected to a database, when we wanted to bring it down.
a couple weeks back we had an AIX system panic.
This is what IBM posted back to our PMR.


The PMR has been transferred to me based on the rmsock command.

I reviewed this issue and found the following explanation from development:

"rmsock can crash the system if it is run on a socket that has already been removed ... such a scenario is a current limitation of rmsock."

"The rmsock implementation has known timing issues which can lead to a system panic. The changes to resolve this are too large to put into an APAR. I would recommend opening a DCR (Design Change Request) for this issue. The gest of the DCR would be to move the processing that rmsock does down into the kernel and use the proper locking and serialization to locate and close the specified socket. The DCR will take long time get analyze because large number of design change requests so resolution may not be immediate."

DCR #MR0616117316 was submitted in June 2011 for this rmsock issue. The latest status is that a resolver has been assigned to review the request.

Based on the information above, we will have to wait for the DCR process to complete in order for this rmsock limitation to be lifted.

based on the outage we took, and the explanation above, I'd recommend using an lsof solution that only "looks", and does not actually try to remove the socket.
If a process completes between your netstat and your rmsock, you could panic the system, as we did.
The nature of what you're writting, depending on how often you run it, increases the odds of that occurance happening.  Our script was running for a year without issue, but one night, major outage ......

sminfoAuthor Commented:
Thanks Tom for your update.. In deed this script will be used from time to time, not daily.. but it's strange because rmsock is recommended by IBM:

just two examples that IBM says you can use rmsock to see the opened ports. BUT the real world is sometimes different to what is written on the paper. I don't use lsof because it's nos installed on all AIX boxes.
I can't speak to the mag article, those are usually good, but, sometimes it's folks wanting to be published.

As for the IBM site posting, what they're referring to is a more stable environment.
You are trying to bring up a service, and someone else is on the port (and holding it).  the odds of that holder going away are slimmer, as that is why you've run into the situation of having to hunt them down.  


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.