Difference between revisions of "Libnetstack"

From dankwiki
 
(One intermediate revision by the same user not shown)
Line 3: Line 3:
 
Code lives at https://github.com/dankamongmen/libnetstack.
 
Code lives at https://github.com/dankamongmen/libnetstack.
  
{{#github:README.md|dankamongmen/libnetstack}}.
+
==rtnetlink==
 +
<tt>rtnetlink(7)</tt> (originally implemented AFAIK by Alexey Kuznetsov, the Mad Russian, whom I haven't seen post to [[LKML]] in many years, and miss) provides the <tt>NETLINK_ROUTE</tt> protocol for the <tt>AF_NETLINK</tt> family of sockets. According to <tt>netlink(7)</tt>,<blockquote>Netlink  is  a datagram-oriented service. Both <tt>SOCK_RAW</tt> and <tt>SOCK_DGRAM</tt> are valid values for socket_type. However, the netlink  protocol  does not distinguish between datagram and raw sockets."—<tt>netlink(7)</tt>, Linux man pages 5.03</blockquote> Creating and using such a socket does not require any special permissions, though <tt>CAP_NET_ADMIN</tt> is needed for many control messages (verified kernel-side, of course). Once established,
 +
We can directly request dumps of networking stack state with the <tt>RTM_GET*</tt> set of messages, and/or simply subscribe to the appropriate multicast groups, sit back, and let new events roll to us.
 +
 
 +
{|class="wikitable"
 +
! Group !! Messages
 +
|-
 +
| <tt>RTNLGRP_LINK</tt> || <tt>RTM_NEWLINK</tt>, <tt>RTM_DELLINK</tt>
 +
|-
 +
| <tt>RTNLGRP_IPV4_IFADDR</tt> || <tt>RTM_NEWADDR</tt>, <tt>RTM_DELADDR</tt> (AF_INET only)
 +
|-
 +
| <tt>RTNLGRP_IPV6_IFADDR</tt> || <tt>RTM_NEWADDR</tt>, <tt>RTM_DELADDR</tt> (AF_INET6 only)
 +
|-
 +
| <tt>RTNLGRP_IPV4_ROUTE</tt> || <tt>RTM_NEWROUTE</tt>, <tt>RTM_DELROUTE</tt> (AF_INET only)
 +
|-
 +
| <tt>RTNLGRP_IPV6_ROUTE</tt> || <tt>RTM_NEWROUTE</tt>, <tt>RTM_DELROUTE</tt> (AF_INET6 only)
 +
|-
 +
| <tt>RTNLGRP_NEIGH</tt> || <tt>RTM_NEWNEIGH</tt>, <tt>RTM_DELNEIGH</tt>
 +
|-
 +
|}
 +
 
 +
{{#github:README.md|dankamongmen/libnetstack}}
 +
 
 +
==See also==
 +
* "[https://inai.de/documents/Netlink_Protocol.pdf The Netlink protocol: Mysteries Uncovered]", Jan Engelhardt 2010-10-30
  
 
[[CATEGORY: Projects]]
 
[[CATEGORY: Projects]]

Latest revision as of 17:24, 4 November 2019

AF_NETLINK sockets allow one to enumerate networking stack elements, and subscribe to events regarding changes, additions, and deletions thereof. Netlink is kind of a pain in the ass to work with directly, though. My libnetlink enumerates all existing networking stack elements, subscribes to events, and makes all of this available to the user via queries and/or realtime callbacks. libnetstack has been designed to provide responsive service even in the presence of millions of routes with rapid churning of the route tables.

Code lives at https://github.com/dankamongmen/libnetstack.

rtnetlink

rtnetlink(7) (originally implemented AFAIK by Alexey Kuznetsov, the Mad Russian, whom I haven't seen post to LKML in many years, and miss) provides the NETLINK_ROUTE protocol for the AF_NETLINK family of sockets. According to netlink(7),

Netlink is a datagram-oriented service. Both SOCK_RAW and SOCK_DGRAM are valid values for socket_type. However, the netlink protocol does not distinguish between datagram and raw sockets."—netlink(7), Linux man pages 5.03

Creating and using such a socket does not require any special permissions, though CAP_NET_ADMIN is needed for many control messages (verified kernel-side, of course). Once established,

We can directly request dumps of networking stack state with the RTM_GET* set of messages, and/or simply subscribe to the appropriate multicast groups, sit back, and let new events roll to us.

Group Messages
RTNLGRP_LINK RTM_NEWLINK, RTM_DELLINK
RTNLGRP_IPV4_IFADDR RTM_NEWADDR, RTM_DELADDR (AF_INET only)
RTNLGRP_IPV6_IFADDR RTM_NEWADDR, RTM_DELADDR (AF_INET6 only)
RTNLGRP_IPV4_ROUTE RTM_NEWROUTE, RTM_DELROUTE (AF_INET only)
RTNLGRP_IPV6_ROUTE RTM_NEWROUTE, RTM_DELROUTE (AF_INET6 only)
RTNLGRP_NEIGH RTM_NEWNEIGH, RTM_DELNEIGH



See also