Netlink header decoding

Dmitry V. Levin ldv at altlinux.org
Sun May 8 00:29:36 UTC 2016


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.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160508/3782da91/attachment.bin>


More information about the Strace-devel mailing list