Quoting Dmitry V. Levin (2016-05-08 00:29:36) > On Fri, May 06, 2016 at 10:08:55PM +0000, Fabien Siron wrote: > > Quoting Dmitry V. Levin (2016-05-06 01:20:27) > > > Hi, > > > > > > On Thu, May 05, 2016 at 10:04:51PM +0000, Fabien Siron wrote: > > > > Hi list, > > > > > > > > I did a quick netlink header parser for sendmsg/recvmsg which does the > > > > following: > > > > > > > > $ strace -qq -erecvmsg tests/netlink_inet_diag > /dev/null > > > > recvmsg(1, {msg_name(12)={sa_family=AF_NETLINK, pid=0, > > > > groups=00000000}, \ > > > > msg_iov(1)={len=96, type=20, flags=2, seq=0, pid=26615}, \ > > > > msg_controllen=0, msg_flags=0}, 0) = 672 > > > > > > > > Of course, this is just a draft to get an idea on how the futur parser > > > > will > > > > work (so forget about the flags for the moment). > > > > Logically, the next step would be to handle the different protocols, but > > > > how can I obtain the protocol of a netlink socket fd? > > > > > > > > I have two ideas: > > > > * keep all the pairs fd/protocol in a table when running the socket > > > > syscall. > > > > > > sockets could be closed, cloned, and passed via SCM_RIGHTS messages. > > > Can you track it in a reliable way? > > > > > > > * obtain the socket inode and then parse /proc/net/netlink to obtain the > > > > protocol. > > > > > > As a modern alternative to /proc/net/netlink, you can use > > > NETLINK_SOCK_DIAG with AF_NETLINK sockets, too > > > (available in linux >= 3.10-rc1). > > > > Nice, that's perfect. But do we have to handle the case where > > linux < 3.10-rc1? > > I wouldn't worry about new netlink decoding features on linux < 3.10-rc1.
Well, in fact, there is a small issue with this idea. Consider that the socket is not binded (like netlink socket in netlink_inet_diag test), NETLINK_SOCK_DIAG won't be aware of that socket until the first send/recv. It probably matters for netlink parsers because we need the netlink protocol for each send/recv. e.g.: $ ./strace -qq -yy -esendmsg,recvmsg tests/netlink_inet_diag > /dev/null sendmsg(1<NETLINK:[10856350]>, ... recvmsg(1<NETLINK:[NETLINK_SOCK_DIAG]>, ... An alternative would be to print the function arguments in recv/send functions only when the function is exiting. It seems to work like that. e.g.: SYS_FUNC(sendmsg) { if (!entering(tcp)) { /* print everything */ } return 0; } Cheers, -- Fabien Siron ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel