Commit Graph

3 Commits

Author SHA1 Message Date
Alexander V. Chernikov
30d7e724db route: show originator PID in netlink monitor
Replacing rtsock with netlink also means providing similar tracing facilities,
rtsock provides `route -n monitor` interface, where each message can be traced
to the originating PID.
This diff closes the feature gap between rtsock and netlink in that regard.

Netlink works slightly differently from rtsock, as it is a generic message
"broker". It calls some kernel KPIs and returns the result to the caller.
Other Netlink consumers gets notified on the changed kernel state using the
relevant subsystem callbacks. Typically, it is close to impossible to pass
some data through these KPIs to enhance the notification.

This diff approaches the problem by using osd(9) to assign the relevant
socket pointer (`'nlp`) to the per-socket taskqueue execution thread.
This change allows to recover the pointer in the aforementioned notification
callbacks and extract some additional data.
Using `osd(9)` (and adding additional metadata) to the notification receiver
comes with some additional cost attached, so this interface needs to be
enabled explicitly by using a newly-created `NETLINK_MSG_INFO` `SOL_NETLINK`
socket option.

The actual medatadata (which includes the originator PID) is provided via
control messages. To enable extensibility, the control message data is
encoded in the standard netlink(TLV-based) fashion. The list of the
currently-provided properties can be found in `nlmsginfo_attrs`.
snl(3) is extended to enable decoding of netlink messages with metadata
(`snl_read_message_dbg()` stores the parsed structure in the provided buffer).

Differential Revision: https://reviews.freebsd.org/D39391
2023-04-28 13:54:54 +00:00
Alexander V. Chernikov
03de61aabb netlink: fix NLMSG_SPACE() macro.
Reported by:	bapt
2022-10-31 15:02:12 +00:00
Alexander V. Chernikov
7e5bf68495 netlink: add netlink support
Netlinks is a communication protocol currently used in Linux kernel to modify,
 read and subscribe for nearly all networking state. Interfaces, addresses, routes,
 firewall, fibs, vnets, etc are controlled via netlink.
It is async, TLV-based protocol, providing 1-1 and 1-many communications.

The current implementation supports the subset of NETLINK_ROUTE
family. To be more specific, the following is supported:
* Dumps:
 - routes
 - nexthops / nexthop groups
 - interfaces
 - interface addresses
 - neighbors (arp/ndp)
* Notifications:
 - interface arrival/departure
 - interface address arrival/departure
 - route addition/deletion
* Modifications:
 - adding/deleting routes
 - adding/deleting nexthops/nexthops groups
 - adding/deleting neghbors
 - adding/deleting interfaces (basic support only)
* Rtsock interaction
 - route events are bridged both ways

The implementation also supports the NETLINK_GENERIC family framework.

Implementation notes:
Netlink is implemented via loadable/unloadable kernel module,
 not touching many kernel parts.
Each netlink socket uses dedicated taskqueue to support async operations
 that can sleep, such as interface creation. All message processing is
 performed within these taskqueues.

Compatibility:
Most of the Netlink data models specified above maps to FreeBSD concepts
 nicely. Unmodified ip(8) binary correctly works with
interfaces, addresses, routes, nexthops and nexthop groups. Some
software such as net/bird require header-only modifications to compile
and work with FreeBSD netlink.

Reviewed by:	imp
Differential Revision: https://reviews.freebsd.org/D36002
MFC after:	2 months
2022-10-01 14:15:35 +00:00