SUMMARY: pfiles cannot find an established tcp connection - why?

 Hello List,
some people help me to understand why pfiles doesn't recognize this (and
other) network Connections.
The effect occur if TLI/XLI endpoints are used instead of socket endpoints.
(http://docs.sun.com/app/docs/doc/806-4125/6jd7pe6c9?l=fr&a=view)
pfiles only support sockets, while lsof supports both.

Special Thanks to Casper, Ric and Crist.

Also see at
http://groups.google.com/group/comp.unix.solaris/browse_thread/thread/bb05c7f
5220e32b4/18e0706da997a5d5?lnk=st&q=pfiles+tcp&rnum=2#18e0706da997a5d5

kindly regards,
Aleks

> -----Urspr|ngliche Nachricht-----
> Von: Pavic, Aleksander
> Gesendet: Donnerstag, 1. Dezember 2005 14:55
> An: sunmanagers@sunmanagers.org
> Betreff: SUMMARY: pfiles cannot find an established tcp
> connection - why?
>
>
> Hello List,
> afaik, no solution exists to identify this process with the
> pfiles command.
>
> Some people say that pfiles only extract the source ip and
> port. That's not correct and not the problem.
> Other people send me shellcode, but the pfiles problem is
> still the same. Some highly recommend lsof to do the job.
> As I said, lsof is not an option in the production enviroment.
>
> On a testing Machine I was able to clone the Problem and try
> to get the info with lsof. lsof works.
> But the question is still not answered. pfiles and lsof uses
> apparently different methods to get these infos.
>
> kindly regards,
> Aleks
>
> # netstat -an | grep 4100
> x.x.x.x.49294  x.x.x.x.4100   24820      0 24820      0 ESTABLISHED
> # lsof -i 4 | grep :4100
> xxx   505 user   11u  IPv4 0x30001a43e40  0t5493552  TCP
> external_port:49294->remote:4100 (ESTABLISHED)
> xxx   518 user    9u  IPv4 0x3000155ae60 0t14877273  TCP
> external_port:32858->remote:4100 (BOUND)
> xxx   519 user    9u  IPv4 0x3000155ae60 0t14877273  TCP
> external_port:32858->remote:4100 (BOUND)
> # pfiles 505
> 505:    /path_to/app/and_opts
>   Current rlimit: 1024 file descriptors
>    0: S_IFREG mode:0755 dev:136,5 ino:198353 uid:xxx gid:xxx size:897
>       O_RDONLY|O_LARGEFILE
>    1: S_IFCHR mode:0666 dev:136,1 ino:367025 uid:xxx gid:xxx rdev:13,2
>       O_WRONLY|O_APPEND
>    2: S_IFCHR mode:0666 dev:136,1 ino:367025 uid:xxx gid:xxx rdev:13,2
>       O_WRONLY|O_APPEND
>    3: S_IFDOOR mode:0444 dev:258,0 ino:29619 uid:xxx gid:xxx size:0
>       O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[184]
>    4: S_IFSOCK mode:0666 dev:253,0 ino:42549 uid:xxx gid:xxx size:0
>       O_RDWR
>         sockname: AF_INET 0.0.0.0  port: 32814
>    5: S_IFSOCK mode:0666 dev:253,0 ino:42549 uid:xxx gid:xxx size:0
>       O_RDWR
>         sockname: AF_INET 0.0.0.0  port: 32816
>    6: S_IFREG mode:0644 dev:136,5 ino:243 uid:xxx gid:xxx size:68240
>       O_WRONLY
>    7: S_IFIFO mode:0000 dev:254,0 ino:236 uid:xxx gid:xxx size:0
>       O_RDWR|O_NDELAY
>    8: S_IFIFO mode:0000 dev:254,0 ino:236 uid:xxx gid:xxx size:0
>       O_RDWR|O_NDELAY
>   10: S_IFIFO mode:0000 dev:254,0 ino:237 uid:xxx gid:xxx size:0
>       O_RDWR
>   11: S_IFCHR mode:0000 dev:136,1 ino:9257 uid:xxx gid:xxx rdev:42,101
>       O_RDWR|O_NDELAY
> #
>
>
> <--- original message --->
> Hello list,
> I need to identify a process which uses an ip4/tcp connection.
> lsof is not an option.
>
> I use the following line to do that:
>
> for i in `ps -e | awk '{print $1}'`; do echo $i; pfiles $i | sed -n
> '/port: 4100/p'; done
>
> I don't get data from this line when I search for this port.
> But netstat says that this connection is established:
>
> bash-2.05# netstat -an | grep 4100
> x.x.x.x.32858 x.x.x.x.4100 24820 0 24820 0 ESTABLISHED
>
> And I know that this connection must work, because it is part if an
> application that works without any problem.
> It works for any other connection, but not for this one. Does anyone
> know why?
> This is unlikely a rootkit effect, because I can reproduce
> this behavior
> on different physical separated machines.
>
> regards,
> Aleks
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers
> </--- original message --->
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers