IP and port associated with a socket fd
Masatake YAMATO
yamato at redhat.com
Wed Aug 6 03:31:36 UTC 2014
> On Tue 05 Aug 2014 09:24:04 Zubin Mithra wrote:
>> 1. A sample output of running it on the client and the server can be
>> found here :-
>> - client : https://gist.github.com/eQu1NoX/3a325de729b4705dc9c3
>> - server : https://gist.github.com/eQu1NoX/3713abc3bae2657d4d6e
>
> pretty cool. some thoughts:
> - should lookup IP addresses
> - should lookup ports using getservent
> - add a flag to enable that look up logic since it'll probably be too slow
> for default behavior
>
>> 2. Currently, the ip and port associated with a file descriptor is
>> obtained in a similar way as netstat does it(print_remote_ipport of
>> the patch corresponds to tcp_do_one in netstat;
>
> i don't think we want to use that model. the /proc net filesystem is known to
> have limitations. instead i think we should do what iproute2's ss tool does
> -- use netlink sockets.
> -mike
I strongly agree with Mike.
I inspected this area once. netlink is promised for this kind of
purpose:
http://www.spinics.net/lists/netdev/msg265315.html
About unix socket, with netlink, you can know the peer procss for a
given socket. unix socket is not in the scope of the patch, but it is
wonderful if strace can attach the peer procss automatically (like -f
option).
A problem is that many libraries wrapping netlink interface are
distributed under term of GPL or LGPL. I'm not sure the code using the
library is acceptable to strace project. If not acceptable, you have
to decode the packet of netlink by yourself.
I hope it is acceptable because I would like to use elfutils to get
stack trace in strace. With an option of configure script, a user can
choose whether using or not using the code.
Masatake YAMATO
More information about the Strace-devel
mailing list