In FreeBSD they added support for the Netlink protocol used in Linux

FreeBSD

FreeBSD is well established as a system for building Internet and Intranet servers. It provides fairly reliable network services and efficient memory management.

Several days ago the news was released that the base code of FreeBSD has adopted a new implementation of the communication protocol netlink (RFC 3549) which is used in Linux to communicate between the kernel and processes in user space.

The socket family netlink is a Linux kernel interface that used for interprocess communication (IPC) between kernel and userspace processes and between different user space processes, similar to Unix domain sockets.

Similar to Unix domain sockets and unlike INET sockets, Netlink communication cannot traverse host boundaries. However, while Unix domain sockets use the file system namespace, Netlink processes are generally addressed by process identifiers (PIDs).

Netlink is designed and used to transfer miscellaneous network information between kernel space and user space processes. Network utilities, such as the iproute2 family and the utilities used to configure mac80211-based wireless drivers, use Netlink to communicate with the Linux kernel from user space. Netlink provides a standard socket-based interface for user space processes and a kernel-side API for internal use by kernel modules. Netlink originally used the AF_NETLINK family of sockets.

So far in its current form, Netlink support layer allows FreeBSD to use the Linux ip utility of the iproute2 packet to manage network interfaces, set IP addresses, configure routing, and manipulate nexthop objects that store the state used to forward a packet to the intended destination. After slightly changing the header files, it is possible to use Netlink in Bird's routing packet.

The Netlink implementation for FreeBSD is packaged as a loadable kernel module that, if possible, does not affect other kernel subsystems and creates separate task queues (tasqueue) to process incoming messages through the protocol and perform operations in asynchronous mode. The reason for porting Netlink is the lack of a standard mechanism to interact with kernel subsystems, leading to different subsystems and drivers inventing their own protocols.

netlink offers a unified communication layer and an extensible message format which can act as a middleman that automatically combines disparate data from different sources into a single request. For example, FreeBSD subsystems like devd, jail, and pfilctl can be ported to Netlink, now using their own ioctl calls, which will greatly simplify building applications to work with these subsystems. Additionally, using Netlink to modify nexthop objects and groups in the routing stack will allow for more efficient interaction with user space routing processes.

The interfaces, addresses, routes, firewall, fibs, vnets, etc. are controlled via netlink. It is a TLV-based asynchronous protocol that provides 1-1 and 1-many communications. The current implementation supports the subset of the NETLINK_ROUTE family. The implementation is also compatible with the NETLINK_GENERIC family framework.

Features currently implemented:

  • Obtain information about routes, nexthops objects and groups, network interfaces, addresses and neighboring hosts (arp/ndp).
  • Formation of notifications about the appearance and disconnection of network interfaces, configuration and removal of addresses, addition and removal of routes.
  • Add and remove routes, next hop objects and groups, gateways, network interfaces.
  • Integration with the Rtsock interface to manage the routing table.

It is worth mentioning that so far the project is limited to supporting the NETLINK_ROUTE family of operations to manage the state of the network subsystem in the kernel.

Finally, if you are interested in being able to know more about it, you can consult the details in the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.