guile-netlink.texi
1 | \input texinfo |
2 | @setfilename guile-netlink.info |
3 | @documentencoding UTF-8 |
4 | @settitle guile-netlink |
5 | |
6 | @include version.texi |
7 | |
8 | @copying |
9 | Copyright @copyright{} 2020 Julien Lepiller |
10 | |
11 | @quotation |
12 | Permission is granted to copy, distribute and/or modify this document |
13 | under the terms of the GNU Free Documentation License, Version 1.3 or |
14 | any later version published by the Free Software Foundation; with no |
15 | Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A |
16 | copy of the license is included in the section entitled ``GNU Free |
17 | Documentation License''. |
18 | @end quotation |
19 | @end copying |
20 | |
21 | @titlepage |
22 | @end titlepage |
23 | |
24 | @contents |
25 | |
26 | @node Top |
27 | @top guile-netlink |
28 | |
29 | This document describes guile-netlink version @value{VERSION}, a guile |
30 | implementation of the netlink protocol. |
31 | |
32 | @menu |
33 | * Introduction:: What is netlink? |
34 | * API Reference:: Description of the library interface. |
35 | |
36 | @detailmenu |
37 | --- The Detailed Node Listing --- |
38 | |
39 | API Reference |
40 | |
41 | * Common API:: Common functions and data types for defining netlink |
42 | protocols. |
43 | * Netlink API:: Common structures and data types for every protocols. |
44 | * Rtnetlink API:: The ROUTE_NETLINK protocol. |
45 | |
46 | @end detailmenu |
47 | @end menu |
48 | |
49 | @node Introduction |
50 | @chapter Introduction |
51 | |
52 | Netlink is an inter-process communication protocol that can be used for |
53 | communication between processes, or with the kernel. It is implemented by |
54 | Linux. |
55 | |
56 | Many protocols exist on top of Netlink. The most famous are used to configure |
57 | network-related functions in the kernel, such as firewall, route table or |
58 | IP addresses of interfaces. |
59 | |
60 | This library implements the low-level bits of the code by providing data |
61 | structures that are close to their C counterpart, and basic procedures to |
62 | initiate communication. |
63 | |
64 | @node API Reference |
65 | @chapter API Reference |
66 | |
67 | @node Common API |
68 | @section Common API |
69 | |
70 | Guile-netlink implements a common API for expressing other protocols. This |
71 | section describes how to use this API to augment guile-netlink with additional |
72 | protocols. |
73 | |
74 | @node Data Types |
75 | @subsection Data Types |
76 | |
77 | Guile-netlink defines data types that are used in the various Netlink protocols. |
78 | We need to be able to serialize and deserialize data that guile-netlink |
79 | understands, but we also want to let users of guile-netlink extend this process |
80 | easily. This need has lead to the creating of the following data structure, |
81 | defined in @code{(netlink data}). |
82 | |
83 | @deffn {Datatype} nl-data |
84 | |
85 | @table @asis |
86 | @item @code{data} |
87 | The data that is held by this record. |
88 | |
89 | @item @code{size-proc} |
90 | A procedure that takes a data (of the same type as the data recorded in the |
91 | @code{data} field) and returns the size of its serialization. |
92 | |
93 | @item @code{serialization-proc} |
94 | A procedure that takes a data (of the same type as the data recorded in the |
95 | @code{data} field), the position at which to start serializing, and a |
96 | bytevector in which to serialize. This procedure should modify the bytevector |
97 | and its return value is ignored. |
98 | |
99 | @end table |
100 | @end deffn |
101 | |
102 | The module also defines the following function, that takes a @code{nl-data} |
103 | structure and provides its serialization in a bytevector: |
104 | |
105 | @deffn {Scheme Procedure} serialize @var{data} @var{pos} @var{bv} |
106 | Takes a @code{nl-data} structure as @var{data}, a position @var{pos} in |
107 | the bytevector @var{bv}, and returns an unspecified value. |
108 | |
109 | This function updates the bytevector and adds the serialization of @var{data} |
110 | into @var{bv} at @var{pos}. |
111 | @end deffn |
112 | |
113 | By providing a @code{nl-data} structure, we defer the knowledge of how to |
114 | serialize the data to the structure itself, instead of the @code{serialize} |
115 | function. This allows for more flexibility and extensibility, as the user |
116 | of the procedure can pass any kind of data, even if it is not yet supported by |
117 | guile-netlink. |
118 | |
119 | Similarly, we need to be able to deserialize netlink answers into a data |
120 | structure. To do so, we also defer the knowledge of the datastructure to |
121 | deserialize to, to a decoder structure that is passed to the deserialization |
122 | procedure. @code{(netlink data)} also defines the following procedures to |
123 | deserialize data: |
124 | |
125 | @deffn {Scheme Procedure} deserialize @var{type} @var{decoder} @var{bv} @var{pos} |
126 | Takes a bytevector @var{bv} and starts deserializing the data starting at |
127 | position @var{pos}. To do so, it uses the @var{type} variable as the lookup |
128 | key in the @var{decoder}. @var{type} is a symbol that represents the type of |
129 | data to deserialize to. |
130 | |
131 | The decoder is a structure that associates each known type to its deserializer |
132 | (a function that takes a decoder, a bytevector and a position and returns some |
133 | data) and an alist that associates a type (an integer, as returned by the |
134 | protocol in use) to the proper decoder of that type. |
135 | @end deffn |
136 | |
137 | @deffn {Scheme Procedure} get-current-deserialize @var{decoder} @var{current-type} |
138 | Takes a decoder and a type, and returns the deserialization procedure associated |
139 | with the type (a symbol) in @var{decoder}. |
140 | @end deffn |
141 | |
142 | @deffn {Scheme Procedure} get-next-deserialize @var{decoder} @var{current-type} @ |
143 | @var{target-type} |
144 | Takes a decoder, a type (a symbol that represents the type of data being |
145 | deserialized) and another type (an integer as returned by the protocol), and |
146 | returns the deserialization procedure needed to continue decoding the data |
147 | associated with the currently being deserialized data. |
148 | |
149 | For example, when decoding an answer in the netlink protocol, we first deserialize |
150 | the header into a @code{message} structure. That header contains a type field |
151 | that contains an integer constant representing the type of data of the body. |
152 | Similarly, when deserializing a routing attribute in the rtnetlink protocol, |
153 | we first find a header of the attribute that defines an integer constant |
154 | corresponding to the type of attribute in the body. |
155 | |
156 | By knowing the context in which the type is declared, this procedure can return |
157 | the correct deserializing procedure. For instance, when deserializing a |
158 | @code{message}, type @code{16} means @code{RTM_NEWLINK} in the rtnetlink |
159 | protocol, whereas it means @code{IFLA_OPERSTATE} when deserializing a |
160 | @code{route-attribute}. |
161 | @end deffn |
162 | |
163 | guile-netlink provides the following default decoder for the rtnetlink |
164 | protocol in @code{(netlink deserialize)}: |
165 | |
166 | @deffn {Scheme Variable} %default-route-decoder |
167 | Contains the default decoder for the NETLINK_ROUTE protocol. |
168 | @end deffn |
169 | |
170 | For convenience, guile-netlink defines the following structures that can be used |
171 | to create a custom decoder. |
172 | |
173 | @deffn {Scheme Variable} %default-message-decoder |
174 | Contains the default association list for the common message types of netlink, |
175 | associating each of them to a deserialization procedure. |
176 | @end deffn |
177 | |
178 | @deffn {Scheme Variable} %default-route-attr-decoder |
179 | Contains the default association list for the known types of routing attributes. |
180 | This list is defined in @code{(netlink route attrs)}. |
181 | @end deffn |
182 | |
183 | @node Constants |
184 | @subsection Constants |
185 | |
186 | Guile-netlink defines constants used by the Netlink protocols in the |
187 | @code{(netlink constant)} module. The constants are the ones present in the |
188 | kernel and are too numerous to list here. Please see the source for the |
189 | complete list. |
190 | |
191 | The module also defines the following macro: |
192 | |
193 | @deffn {Scheme Macro} define-enum @var{integer->symbol} @var{name-spec} ... |
194 | This macros defines an enumeration. @var{integer->symbol} is the name of |
195 | a procedure that is publicly defined, that takes an integer and returns the |
196 | associated symbol in the enumeration. |
197 | |
198 | The macro also publicly defines variables whose names are in @var{name-spec} |
199 | to an integer. |
200 | |
201 | A @var{name-spec} is either a single name, and the associated value is 0 for |
202 | the first @var{name-spec}, or one more than the previous @var{name-spec}. |
203 | It can also be a pair of a name and an integer, in which case the associated |
204 | value is that integer. For instance: |
205 | |
206 | @example |
207 | (define-enum get-foo FOO0 FOO1 (FOO10 10) FOO11 FOO12) |
208 | (get-foo 9) -> #<unspecified> |
209 | (get-foo 0) -> FOO0 |
210 | FOO11 -> 11 |
211 | @end example |
212 | @end deffn |
213 | |
214 | @node Netlink Connections |
215 | @subsection Netlink Connections |
216 | |
217 | The @code{(netlink connection)} module defines the following procedures, used |
218 | to connect and communicate with another process or the kernel using a netlink |
219 | socket. |
220 | |
221 | @deffn {Scheme Procedure} get-addr @var{family} @var{pid} @var{groups} |
222 | Return a bytevector that represents a netlink address. @var{family} |
223 | should be @code{AF_NETLINK}, @var{pid} is the PID of the process with which |
224 | to communicate or 0 for the kernel. @var{groups} is an integer representing |
225 | the set of broadcast groups to which the connection subscribes. |
226 | @end deffn |
227 | |
228 | @deffn {Scheme Procedure} connect @var{proto} @var{addr} |
229 | Creates a netlink socket for @var{proto} and binds it to @var{addr}. |
230 | |
231 | @var{proto} is the integer representing the protocol. For instance, rtnetlink |
232 | can be selected by usin @code{NETLINK_ROUTE} (defined in |
233 | @code{(netlink constant)}). |
234 | |
235 | @var{addr} is a bytevector, as returned by @code{get-addr}. |
236 | @end deffn |
237 | |
238 | @deffn {Scheme Procedure} connect-route [#:groups @code{0}] |
239 | This procedure is a wrapper for @code{connect} that creates a socket for the |
240 | rtnetlink protocol, binds it to the kernel and returns it. By passing the |
241 | optional @var{groups} keyword, you can select broadcast groups to subscribe to. |
242 | @end deffn |
243 | |
244 | @deffn {Scheme Procedure} close-socket @var{socket} |
245 | Closes a netlink socket. The socket cannot be used afterwards. |
246 | @end deffn |
247 | |
248 | @deffn {Scheme Procedure} send-msg @var{msg} @var{sock} [#:@var{addr}] |
249 | Send @var{msg} (it must be of type message, @xref{Netlink Headers}) to |
250 | @var{addr} using @var{sock}. If not passed, @var{addr} is the address of |
251 | the kernel. |
252 | @end deffn |
253 | |
254 | @deffn {Scheme Procedure} receive-msg @var{sock} [#:@var{addr}] |
255 | Receives a message from @var{sock} from @var{addr}. This procedure is blocking. |
256 | If not passed, @var{addr} defaults to the address of the kernel. This |
257 | procedure returns the message as a bytevector, that you can deserialize with |
258 | @code{deserialize} (@xref{Data Types}) |
259 | @end deffn |
260 | |
261 | @node Netlink API |
262 | @section Netlink API |
263 | |
264 | This section introduces the data structures used for all the netlink protocols. |
265 | First, we introduce the structure of a netlink message, then we present the |
266 | standard types of netlink messages, that can be used with every protocol. |
267 | |
268 | @node Netlink Headers |
269 | @subsection Netlink Headers |
270 | |
271 | The @code{(netlink message)} module defines the message structure that contains |
272 | a netlink message. It is composed of a header and a body, and is the data |
273 | structure to pass to @code{send-msg} (@xref{Netlink Connections}). |
274 | |
275 | This module defines the following data structure: |
276 | |
277 | @deffn {Datatype} message |
278 | @table @asis |
279 | @item @code{type} |
280 | The type of data in the body of the message. For instance, @code{RTM_GETLINK}. |
281 | |
282 | @item @code{flags} |
283 | The set of flags that are set in the header. For instance, |
284 | @code{(logior NLM_F_REQUEST NLM_F_DUMP)}. |
285 | |
286 | @item @code{seq} |
287 | The sequence number of the message. If this message is an answer to a request, |
288 | it must keep the same sequence number. Otherwise, you must generate a new and |
289 | unique sequence number, to track the answers. |
290 | |
291 | @item @code{pid} |
292 | The PID of the receiving process, or 0 for the kernel. |
293 | |
294 | @item @code{data} |
295 | The actual body, as an @code{nl-data} structure. |
296 | |
297 | @end table |
298 | @end deffn |
299 | |
300 | @node Standard Message Types |
301 | @subsection Standard Message Types |
302 | |
303 | The @code{(netlink standard)} module defines the set of standard message types |
304 | and their data type. |
305 | |
306 | @deffn {Datatype} error-message |
307 | @table @asis |
308 | @item @code{err} |
309 | The error code, as a negative number. |
310 | |
311 | @item @code{hdr} |
312 | The message on which this error applies. |
313 | |
314 | @end table |
315 | |
316 | @deffn {Scheme Variable} no-data |
317 | This variable defines the absence of data. This is useful when a structure |
318 | is expecting a body part, but the protocol specifically defines that it should |
319 | not take any data in some cases. For instance, a @code{NLMSG_NOOP} message |
320 | takes no data, so the @code{data} field of the message will contain this |
321 | @code{no-data} value. |
322 | @end deffn |
323 | |
324 | @end deffn |
325 | |
326 | @node Rtnetlink API |
327 | @section Rtnetlink API |
328 | @cindex rtnetlink |
329 | @cindex ROUTE_NETLINK |
330 | |
331 | This section describes the support for rtnetlink in guile-netlink. Rtnetlink |
332 | is the protocol responsible for everything related to network routing. It |
333 | allows you to manage links, addresses, routing tables, neighbor chaces, |
334 | routing rules, queueing disciplines, traffic classes, traffic filters and |
335 | more. |
336 | |
337 | @node Routing Attributes |
338 | @subsection Routing Attributes |
339 | |
340 | The @code{(netlink route attrs)} module defines the following data types: |
341 | |
342 | @deffn {Datatype} route-attr |
343 | This defines a header structure for the attribute, as well as its body. |
344 | |
345 | @table @asis |
346 | @item @code{type} |
347 | This is the type of the attribute, for instance @code{IFLA_ADDRESS}. |
348 | |
349 | @item @code{data} |
350 | This is the body of the attribute, ie.@: its value. |
351 | @end table |
352 | @end deffn |
353 | |
354 | The module also defines additional data types that are not represented as |
355 | a record, but by a simple type. For each of the following types, there is |
356 | a @code{make-*-route-attr} procedure to produce a @code{nl-data} value |
357 | for this type. There is also @code{deserialize-route-attr-data-*} procedure |
358 | to deserialize a value of this type. |
359 | |
360 | @table @asis |
361 | @item @code{u8} |
362 | A one-byte unsigned integer |
363 | @item @code{u16} |
364 | A two-bytes unsigned integer |
365 | @item @code{u32} |
366 | A four-bytes unsigned integer |
367 | @item @code{s32} |
368 | A four-bytes signed integer |
369 | @item @code{string} |
370 | A string |
371 | @item @code{ethernet} |
372 | An ethernet address. Its value is a string that represents that address, |
373 | for instnace @code{"01:23:45:67:89:ab"} |
374 | @item @code{bv} |
375 | A bytevector. This is used by default when the type is not supported. |
376 | @end table |
377 | |
378 | @node Link Messages |
379 | @subsection Link Messages |
380 | |
381 | The @code{(netlink route link)} package defines the following data type: |
382 | |
383 | @deffn {Datatype} link-message |
384 | This datatype represents a link message with its routing attributes. This type |
385 | of message is expected when using the @var{RTM_*LINK} message types. |
386 | |
387 | @table @asis |
388 | @item @code{family} |
389 | The network family, defined as @code{AF_UNSPEC} in the rtnetlink documentation, |
390 | although it holds different values in practice. |
391 | |
392 | @item @code{type} |
393 | The device type. |
394 | |
395 | @item @code{index} |
396 | The index of the device. This is used to select a specific device by its index, |
397 | or 0 to not filter by device index. |
398 | |
399 | @item @code{flags} |
400 | The device flags. See @code{man 7 netdevices} for a list. |
401 | |
402 | @item @code{attrs} |
403 | A list of attributes. This field must contain a list of @code{nl-data} |
404 | structures, not a structure by itself. |
405 | @end table |
406 | @end deffn |
407 | |
408 | @bye |
409 |