Busybox, netstat, no -p
Solution 1
You can find the equivalent information in slightly uglier form (a.k.a. hexadecimal) in /proc/net/tcp
. There, you can find the inode of the connection, which you can look up under /proc/$pid/fd/
.
For example:
$ cat /proc/net/tcp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode
0: 00000000:0016 00000000:0000 0A 00000000:00000000 00:00000000 00000000 0 0 6115 1 f5adc4c0 300 0 0 2 -1
...
(In normal netstat, but not in busybox netstat, the -e
option also gives you that extra information.)
You can find the process which corresponds to the inode with the following command:
# for x in $(find /proc/ | grep /fd/); do ls -la $x 2>/dev/null done | grep 6115
...
lrwx------ 1 root root 64 7 jan 22.50 /proc/2560/fd/3 -> socket:[6115]
You need root access for the second step.
Not as convenient as the -p
option, obviously, but works in a bind. Could be scripted, if necessary.
Solution 2
This may not help, if you don't have the opportunity to rebuild Busybox, but in case it helps anyone...
Busybox does have a configuration option to support the -p
switch of Busybox netstat
. See option CONFIG_FEATURE_NETSTAT_PRG
, selected in busybox menuconfig via Networking Utilities → netstat → Enable PID/Program name output.
Solution 3
If you have or can get ss
on your device it can show you the PID too:
ss -ltp # for TCP
ss -lup # for UDP
Solution 4
A slight variant that might be easier for some:
- Identify interesting protocol and port from netstat or other source
- Convert port to hex: echo | awk '{ printf "%x\n", $1 }'
- cd /proc/net
- grep -i <hex_port> {upd|tcp} | awk '{ printf "local: %s inode: %s", $2, $10 }' If you get multiple lines, look for the one that has the matching hex_port in the second half of the "local" string.
- ls -al /proc//fd/ 2>/dev/null | grep
This should return a line similar to: lrwx------ 1 root root 64 May 22 20:02 /proc/1148/fd/26 -> socket:[4520]
Telling you that PID 1148 has a socket open on inode 4520
Example: Looking for the SSDP process on a Philips Hue Bridge V2.x:
root@Philips-hue:/proc# netstat -an | grep 1900
udp 2176 0 0.0.0.0:1900 0.0.0.0:*
root@Philips-hue:/proc# echo 1900 | awk '{ printf "%x\n", $1 }'
76c
root@Philips-hue:/proc# grep -i 76c /proc/net/udp | awk '{ printf "local: %s ino
de: %s\n", $2, $10 }'
local: 00000000:076C inode: 4520
root@Philips-hue:/proc# ls -al /proc/*/fd/* 2>/dev/null | grep 4520
lrwx------ 1 root root 64 May 22 20:02 /proc/1148/fd/26 -> socket:[4520]
So we identified process PID=1148 as the listener:
root@Philips-hue:/proc# ps w | grep 1148
1148 root 64016 S /usr/sbin/ipbridge -p /home/ipbridge/var -z /dev/ttyZigbee -u /etc/channel/channel-config -h /home -e ecb
1696 root 1284 S grep 1148
So now I know that the ipbridge daemon controls the SSDP listener among the many other things it controls on the Hue Bridge.
Related videos on Youtube
a1337q
Updated on September 17, 2022Comments
-
a1337q over 1 year
I have an ultra old (don't ask why) BusyBox (BusyBox v1.01 (2008.12.19-21:31+0000) Built-in shell (ash)) on my DreamBox. I would like to find out which process opened which connection using netstat. But I found out that BusyBox's netstat doesn't contain the -p option. What other possibilites do I have to find out which process has opened (and is using) the corresponding socket?
-
Zoredache over 13 yearsIs lsof part of that version of busybox?
-
a1337q over 13 yearsUnfortunately not.
-
-
a1337q over 13 yearsSounds cool, but my netstat doesn't work as it should, it outputs nothing additional with the -e option. I have 6 columns also with -e: Proto, Recv-Q, Send-Q, Local Address, Foreign Address, State. Is there a way with the ports? I can see the port..
-
Peter Eisentraut over 13 yearsYou're right, I must have messed up my tests. I edited it to give you a working solution.
-
ygoe about 5 yearsHow do you find the number "2560" you type in your second command? That's the question.
-
Sam almost 5 years@ygoe you have to use
6115
and use it like this:find /proc/ -type l | grep /fd/ | xargs ls -la 2>/dev/null | grep 6115
-
Andrew Lamarra over 3 yearsYou'll need a semicolon after the
2>/dev/null