Announcing netlink crates

announcements
1

Hi,

Note: this is an announcement I also made on r/rust, I hope this won't be considered too spammy

Although these crates are not ready to be used in production, I'd like to announce a bunch of crates I've been working on for a few weeks, that are related to the netlink protocol.

What is netlink?

netlink is an inter process communication protocol available on Linux. Processes can open netlink sockets and communicate together by sending and receiving message through these sockets. man 7 netlink on Linux gives a bried overview of the protocol.

Many subprotocols have been implemented for netlink, but the one I'm most interested in is the route protocol, which is used to communicate with the kernel itself, and manipulate networking resources: interfaces, addresses, arp tables, and route tables. This protocol is described in more details in man 7 rtnetlink, and also in RFC3549. The route protocol is what powers the iproute2 utilities. When you do ip link show or ip addr add 10.0.0.1/24 dev eth0, a netlink socket is opened with the kernel and messages are exchanged.

Crates I'm working on

The repo is here GitHub - little-dude/netlink: netlink libraries for rust

I've split the code is three crates:

  • netlink-socket (doc) provides a netlink socket. Nothing too interesting here, it's just a few bindings.
  • rtnetlink (doc) provides netlink messages for the route sub-protocol. It is enough to work with netlink, but it still a bit painful to have to build messages manually (see this example to retrieve the list of interfaces)
  • that's where iproute2 (doc) comes into play. The goal is to provide higher level methods to work with netlink. The documentation has a few examples

State of the project, roadmap, and call for contributions

So far, I've covered a large part of the link messages. One can create, delete, dump and update links with iproute2 or rtnetlink. I think links are the biggest and most complex piece, so having implemented a large portion of it makes me confident I'm on the right path. But there are still lots of things to cover, in particular:

  • neighbors (ip neigh commands)
  • routes (ip route commands)
  • addresses (ip addr commands)
  • monitoring (ip monitor commands)

and other things.

That is a lot of messages to add to rtnetlink which is what takes most time. That is why I'm making this announce despite the project being in early stages: I'd like people to help. Helping with code is nice, but there are tons of things you can do to help:

  • code reviews (are the APIs in iproute2 convenient? efficient? the crate is pretty recent, so I don't mind doing big refactoring if needed)
  • feature requests (so that I can prioritize what I'm working on)
  • testing
  • documentation

Thank you for reading this far :slight_smile:

11 Likes