---

   netlink - обмен информацией между ядром и пользовательским пространством

---

---

ОБЗОР

#include <asm/types.h>
#include <sys/socket.h>
#include <linux/netlink.h>
netlink_socket = socket(AF_NETLINK, socket_type, netlink_family);

---

ОПИСАНИЕ

Netlink обеспечивает для приложений сервис передачи датаграмм. В качестве socket_type могут использоваться типы сокетов как SOCK_RAW, так и SOCK_DGRAM. Несмотря на это, протокол netlink не различает датаграмные и неструктурированные (raw) сокеты.

По значению netlink_family выбирается модуль ядра или группа netlink для связи. В данный момент определены следующие семейства netlink:

NETLINK_ROUTE Получает обновления маршрутов и состояние подключений (link); может использоваться для изменения таблицы маршрутизации (IPv4 и IPv6), IP-адресов, параметров подключения, настроек взаимодействия с ответной стороной (neighbor), параметров работы очереди, классов трафика и классификаторов пакетов (см. rtnetlink(7)).

NETLINK_W1 Сообщения из однопроводной подсистемы.

NETLINK_USERSOCK Зарезервировано для будущих протоколов сокетов пространства пользователя.

NETLINK_FIREWALL Переправляет пакеты IPv4 из netfilter в пространство пользователя Используется модулем ядра ip_queue.

NETLINK_INET_DIAG Следит за сокетом INET.

NETLINK_NFLOG Netfilter/iptables ULOG.

NETLINK_XFRM IPsec.

NETLINK_SELINUX Уведомляет о событиях SELinux.

NETLINK_ISCSI Open-iSCSI.

NETLINK_AUDIT Ведёт контроль за системой.

NETLINK_FIB_LOOKUP Доступ к таблице FIB из пользовательского пространства.

NETLINK_CONNECTOR Точка связи с ядром. Дополнительную информацию смотрите в файле Documentation/connector/* дерева исходного кода ядра Linux.

NETLINK_NETFILTER Подсистема netfilter.

NETLINK_IP6_FW Переправляет пакеты IPv6 из netfilter в пространство пользователя. Используется модулем ядра ip6_queue.

NETLINK_DNRTMSG Сообщения маршрутизации DECnet.

NETLINK_KOBJECT_UEVENT Сообщения ядра в пользовательском пространстве.

NETLINK_GENERIC Обобщённое семейство netlink для использования netlink.

NETLINK_CRYPTO (начиная с Linux 3.2) Интерфейс netlink для запроса информации о зарегистрированных алгоритмах шифрования с помощью программного интерфейса ядра шифрования, а также настройки программного интерфейса ядра шифрования.

Сообщения netlink состоят из потока байтов с одним или несколькими заголовками nlmsghdr и присоединённой полезной нагрузкой. Доступ к потоку байтов нужно осуществлять только с помощью стандартных макросов NLMSG_*. Подробности смотрите в netlink(3).

В первом и всех последующих заголовках сообщений, состоящих из нескольких частей (несколько заголовков nlmsghdr с полезной нагрузкой в одном потоке байт), установлен флаг NLM_F_MULTI. Последний заголовок имеет тип NLMSG_DONE и этот флаг не устанавливается.

После каждого nlmsghdr следует полезная нагрузка:

struct nlmsghdr {
    __u32 nlmsg_len;    /* длина сообщения, включая заголовок */
    __u16 nlmsg_type;   /* тип содержимого сообщения */
    __u16 nlmsg_flags;  /* дополнительные флаги */
    __u32 nlmsg_seq;    /* номер в последовательности */
    __u32 nlmsg_pid;    /* ID порта отправителя */
};

Значение nlmsg_type может быть одним из стандартных типов сообщения: сообщения NLMSG_NOOP должны игнорироваться, сообщение NLMSG_ERROR сообщает об ошибке и в нагрузке содержится структура nlmsgerr, сообщение NLMSG_DONE заканчивает сообщение, состоящее из нескольких частей.

struct nlmsgerr {
    int error;        /* отрицательный errno или
                         0 для подтверждений */
    struct nlmsghdr msg;  /* заголовок сообщения, вызвавшего
                             ошибку */
};

Семейство netlink обычно определяет и другие типы сообщений (см. соответствующие справочные страницы, например, rtnetlink(7) о NETLINK_ROUTE).

Стандартные биты флагов в nlmsg_flags

Дополнительные биты флагов для запросов GET

Заметим, что NLM_F_ATOMIC требует мандата CAP_NET_ADMIN или эффективного UID 0.

Дополнительные биты флагов для запросов NEW

Поля nlmsg_seq и nlmsg_pid используются для отслеживания передачи сообщений. В nlmsg_pid указывается источник сообщения. Заметим, что нет связи 1:1 между nlmsg_pid и PID процесса, если сообщение возникло из сокета netlink. Дополнительную информацию ищите в разделе ФОРМАТЫ АДРЕСА.

Тип поля nlmsg_seq и nlmsg_pid скрыт в ядре netlink.

Netlink не является надежным протоколом. Он делает всё возможное для доставки сообщения по адресу (адресам), но может отбрасывать пакеты при нехватке памяти или возникновении других ошибок в работе. Для повышения надёжности передачи отправитель может запросить подтверждение от получателя, установив флаг NLM_F_ACK. Подтверждающим является пакет NLMSG_ERROR с полем ошибки, равным нулю. Приложение должно само создавать подтверждения полученным сообщениям. Ядро пытается послать сообщение NLMSG_ERROR всем ошибочным пакетам. Процесс пользователя также должен следовать этому соглашению.

Однако, надёжная передача от ядра пользователю в любом случае невозможна. Ядро не может послать сообщение netlink, если заполнен буфер сокета: сообщение будет отброшено и ядро и пользовательский процесс будут иметь разное понятие о состоянии ядра. В обязанность приложения входит обнаружение такой ситуации (посредством ошибки ENOBUFS, возвращаемой recvmsg(2)) и выполнение восстановления синхронизации.

Форматы адресов

struct sockaddr_nl {
    sa_family_t     nl_family;  /* AF_NETLINK */
    unsigned short  nl_pad;     /* ноль */
    pid_t           nl_pid;     /* ID порта */
    __u32           nl_groups;  /* маска многоадресных групп */
};

nl_pid — одиночный адрес сокета netlink. Он всегда равен 0, если местом назначения является ядро. Для процесса пользовательского пространства значение nl_pid, обычно, равно PID процесса, которому принадлежит сокет назначения. Однако, значением nl_pid определяется сокет netlink, а не процесс. Если процессу принадлежит несколько сокетов netlink, то значение nl_pid может быть равно ID процесса только у одного сокета. Есть два способа назначить nl_pid сокету netlink. Если приложение задаёт nl_pid до вызова bind(2), то приложение само должно убедиться, что значение nl_pid уникально. Если приложение устанавливает его равным 0, то присвоение уникального значения выполняется ядром. Первому сокету netlink ядро назначает ID процесса, который его открыл, а всем последующим создаваемым процессом сокетам netlink, будет назначено уникальное значение nl_pid.

Значение nl_groups — это битовая маска, где каждый бит представляет номер группы netlink. Каждое семейство netlink имеет набор из 32-х многоадресных групп. Когда для сокета вызывается bind(2), то поле nl_groups структуры sockaddr_nl должно содержать битовую маску групп, которые оно хочет прослушивать. По умолчанию значение этого поля равно нулю, что означает, что многоадресные передачи не будут приниматься. Сокет может передавать многоадресные сообщения любой из многоадресных групп, присвоив nl_groups битовую маску групп, которым он желает передавать данные вызовом sendmsg(2) или при выполнении connect(2). Принимать или посылать сообщения многоадресной группы netlink могут только процессы с эффективным UID, равным 0, или имеющие мандат CAP_NET_ADMIN. Начиная с Linux 2.6.13, сообщения не могут вещаться в многоадресные группы. Любые ответы на сообщение, полученное многоадресной группой, должны быть отправлены посылающему процессу с PID и многоадресной группе. Некоторые подсистемы ядра Linux могут разрешать отправку и/или приём сообщений другим пользователям. Начиная с Linux 3.0, в группах NETLINK_KOBJECT_UEVENT, NETLINK_GENERIC, NETLINK_ROUTE и NETLINK_SELINUX разрешено принимать сообщения от других пользователей. Отправлять сообщения другим пользователям запрещено.

ВЕРСИИ

Linux 2.0 поддерживал более примитивный интерфейс на основе устройств (который всё ещё доступен для совместимости). Этот устаревший интерфейс здесь не описывается.

NETLINK_SELINUX появился в Linux 2.6.4.

NETLINK_AUDIT появился в Linux 2.6.6.

NETLINK_KOBJECT_UEVENT появился в Linux 2.6.10.

NETLINK_W1 и NETLINK_FIB_LOOKUP появились в Linux 2.6.13.

NETLINK_INET_DIAG, NETLINK_CONNECTOR и NETLINK_NETFILTER появились в Linux 2.6.14.

NETLINK_GENERIC и NETLINK_ISCSI появились в Linux 2.6.15.

---

ЗАМЕЧАНИЯ

ДЕФЕКТЫ

---

ПРИМЕР

struct sockaddr_nl sa;
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
sa.nl_groups = RTMGRP_LINK | RTMGRP_IPV4_IFADDR;
fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
bind(fd, (struct sockaddr *) &sa, sizeof(sa));

В следующем примере показано как отправить сообщение netlink ядру (pid 0). Заметим, что приложение должно управлять нумерацией сообщений, чтобы отслеживать подтверждения о доставке.

struct nlmsghdr *nh; /* отправляется nlmsghdr с полезной нагрузкой */
struct sockaddr_nl sa;
struct iovec iov = { nh, nh->nlmsg_len };
struct msghdr msg;
msg = { &sa, sizeof(sa), &iov, 1, NULL, 0, 0 };
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
nh->nlmsg_pid = 0;
nh->nlmsg_seq = ++sequence_number;
/* для запроса подтверждения от ядра, устанавливаем NLM_F_ACK */
nh->nlmsg_flags |= NLM_F_ACK;
sendmsg(fd, &msg, 0);

И последний пример о том, как выполнять чтение сообщения netlink.

int len;
char buf[4096];
struct iovec iov = { buf, sizeof(buf) };
struct sockaddr_nl sa;
struct msghdr msg;
struct nlmsghdr *nh;
msg = { &sa, sizeof(sa), &iov, 1, NULL, 0, 0 };
len = recvmsg(fd, &msg, 0);
for (nh = (struct nlmsghdr *) buf; NLMSG_OK (nh, len);
     nh = NLMSG_NEXT (nh, len)) {
    /* конец сообщения из нескольких частей */
    if (nh->nlmsg_type == NLMSG_DONE)
        return;
    if (nh->nlmsg_type == NLMSG_ERROR)
        /* выполняем обработку ошибок */
    ...
    /* разбираем полезную нагрузку */
    ...
}