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 | * IP Library:: High-level functions for network devices. |
36 | |
37 | @detailmenu |
38 | --- The Detailed Node Listing --- |
39 | |
40 | API Reference |
41 | |
42 | * Common API:: Common functions and data types for defining netlink |
43 | protocols. |
44 | * Netlink API:: Common structures and data types for every protocols. |
45 | * Rtnetlink API:: The ROUTE_NETLINK protocol. |
46 | |
47 | IP Library |
48 | |
49 | * Link:: Actions on network links. |
50 | * Addr:: Actions on network addresses. |
51 | * Route:: Actions on network routes. |
52 | |
53 | @end detailmenu |
54 | @end menu |
55 | |
56 | @node Introduction |
57 | @chapter Introduction |
58 | |
59 | Netlink is an inter-process communication protocol that can be used for |
60 | communication between processes, or with the kernel. It is implemented by |
61 | Linux. |
62 | |
63 | Many protocols exist on top of Netlink. The most famous are used to configure |
64 | network-related functions in the kernel, such as firewall, route table or |
65 | IP addresses of interfaces. |
66 | |
67 | This library implements the low-level bits of the code by providing data |
68 | structures that are close to their C counterpart, and basic procedures to |
69 | initiate communication. |
70 | |
71 | @node API Reference |
72 | @chapter API Reference |
73 | |
74 | @node Common API |
75 | @section Common API |
76 | |
77 | Guile-netlink implements a common API for expressing other protocols. This |
78 | section describes how to use this API to augment guile-netlink with additional |
79 | protocols. |
80 | |
81 | @node Data Types |
82 | @subsection Data Types |
83 | |
84 | Guile-netlink defines data types that are used in the various Netlink protocols. |
85 | We need to be able to serialize and deserialize data that guile-netlink |
86 | understands, but we also want to let users of guile-netlink extend this process |
87 | easily. This need has lead to the creating of the following data structure, |
88 | defined in @code{(netlink data}). |
89 | |
90 | @deffn {Datatype} nl-data |
91 | |
92 | @table @asis |
93 | @item @code{data} |
94 | The data that is held by this record. |
95 | |
96 | @item @code{size-proc} |
97 | A procedure that takes a data (of the same type as the data recorded in the |
98 | @code{data} field) and returns the size of its serialization. |
99 | |
100 | @item @code{serialization-proc} |
101 | A procedure that takes a data (of the same type as the data recorded in the |
102 | @code{data} field), the position at which to start serializing, and a |
103 | bytevector in which to serialize. This procedure should modify the bytevector |
104 | and its return value is ignored. |
105 | |
106 | @end table |
107 | @end deffn |
108 | |
109 | The module also defines the following function, that takes a @code{nl-data} |
110 | structure and provides its serialization in a bytevector: |
111 | |
112 | @deffn {Scheme Procedure} serialize @var{data} @var{pos} @var{bv} |
113 | Takes a @code{nl-data} structure as @var{data}, a position @var{pos} in |
114 | the bytevector @var{bv}, and returns an unspecified value. |
115 | |
116 | This function updates the bytevector and adds the serialization of @var{data} |
117 | into @var{bv} at @var{pos}. |
118 | @end deffn |
119 | |
120 | By providing a @code{nl-data} structure, we defer the knowledge of how to |
121 | serialize the data to the structure itself, instead of the @code{serialize} |
122 | function. This allows for more flexibility and extensibility, as the user |
123 | of the procedure can pass any kind of data, even if it is not yet supported by |
124 | guile-netlink. |
125 | |
126 | Similarly, we need to be able to deserialize netlink answers into a data |
127 | structure. To do so, we also defer the knowledge of the datastructure to |
128 | deserialize to, to a decoder structure that is passed to the deserialization |
129 | procedure. @code{(netlink data)} also defines the following procedures to |
130 | deserialize data: |
131 | |
132 | @deffn {Scheme Procedure} deserialize @var{type} @var{decoder} @var{bv} @var{pos} |
133 | Takes a bytevector @var{bv} and starts deserializing the data starting at |
134 | position @var{pos}. To do so, it uses the @var{type} variable as the lookup |
135 | key in the @var{decoder}. @var{type} is a symbol that represents the type of |
136 | data to deserialize to. |
137 | |
138 | The decoder is a structure that associates each known type to its deserializer |
139 | (a function that takes a decoder, a bytevector and a position and returns some |
140 | data) and an alist that associates a type (an integer, as returned by the |
141 | protocol in use) to the proper decoder of that type. |
142 | @end deffn |
143 | |
144 | @deffn {Scheme Procedure} get-current-deserialize @var{decoder} @var{current-type} |
145 | Takes a decoder and a type, and returns the deserialization procedure associated |
146 | with the type (a symbol) in @var{decoder}. |
147 | @end deffn |
148 | |
149 | @deffn {Scheme Procedure} get-next-deserialize @var{decoder} @var{current-type} @ |
150 | @var{target-type} |
151 | Takes a decoder, a type (a symbol that represents the type of data being |
152 | deserialized) and another type (an integer as returned by the protocol), and |
153 | returns the deserialization procedure needed to continue decoding the data |
154 | associated with the currently being deserialized data. |
155 | |
156 | For example, when decoding an answer in the netlink protocol, we first deserialize |
157 | the header into a @code{message} structure. That header contains a type field |
158 | that contains an integer constant representing the type of data of the body. |
159 | Similarly, when deserializing a routing attribute in the rtnetlink protocol, |
160 | we first find a header of the attribute that defines an integer constant |
161 | corresponding to the type of attribute in the body. |
162 | |
163 | By knowing the context in which the type is declared, this procedure can return |
164 | the correct deserializing procedure. For instance, when deserializing a |
165 | @code{message}, type @code{16} means @code{RTM_NEWLINK} in the rtnetlink |
166 | protocol, whereas it means @code{IFLA_OPERSTATE} when deserializing a |
167 | @code{route-attribute}. |
168 | @end deffn |
169 | |
170 | guile-netlink provides the following default decoder for the rtnetlink |
171 | protocol in @code{(netlink deserialize)}: |
172 | |
173 | @deffn {Scheme Variable} %default-route-decoder |
174 | Contains the default decoder for the NETLINK_ROUTE protocol. |
175 | @end deffn |
176 | |
177 | For convenience, guile-netlink defines the following structures that can be used |
178 | to create a custom decoder. |
179 | |
180 | @deffn {Scheme Variable} %default-message-decoder |
181 | Contains the default association list for the common message types of netlink, |
182 | associating each of them to a deserialization procedure. |
183 | @end deffn |
184 | |
185 | @deffn {Scheme Procedure} default-route-attr-decoder @var{deserialize-addr} |
186 | Creates the default association list for a route protocol, given the specified |
187 | address deserializer. This is useful because the @code{IFA_ADDRESS}, |
188 | @code{IFA_BROADCAST}, etc, contain a different type of address depending on |
189 | the message type or its header. This is defined an @code{(netlink route attrs)} |
190 | and used by the following variables: |
191 | @end deffn |
192 | |
193 | @deffn {Scheme Variable} %default-route-link-attr-decoder |
194 | Contains the default association list for the known types of routing attributes |
195 | for link messages. This list is defined in @code{(netlink route attrs)}. |
196 | @end deffn |
197 | |
198 | @node Constants |
199 | @subsection Constants |
200 | |
201 | Guile-netlink defines constants used by the Netlink protocols in the |
202 | @code{(netlink constant)} module. The constants are the ones present in the |
203 | kernel and are too numerous to list here. Please see the source for the |
204 | complete list. |
205 | |
206 | The module also defines the following macro: |
207 | |
208 | @deffn {Scheme Macro} define-enum @var{integer->symbol} @var{name-spec} ... |
209 | This macros defines an enumeration. @var{integer->symbol} is the name of |
210 | a procedure that is publicly defined, that takes an integer and returns the |
211 | associated symbol in the enumeration. |
212 | |
213 | The macro also publicly defines variables whose names are in @var{name-spec} |
214 | to an integer. |
215 | |
216 | A @var{name-spec} is either a single name, and the associated value is 0 for |
217 | the first @var{name-spec}, or one more than the previous @var{name-spec}. |
218 | It can also be a pair of a name and an integer, in which case the associated |
219 | value is that integer. For instance: |
220 | |
221 | @example |
222 | (define-enum get-foo FOO0 FOO1 (FOO10 10) FOO11 FOO12) |
223 | (get-foo 9) -> #<unspecified> |
224 | (get-foo 0) -> FOO0 |
225 | FOO11 -> 11 |
226 | @end example |
227 | @end deffn |
228 | |
229 | @node Netlink Connections |
230 | @subsection Netlink Connections |
231 | |
232 | The @code{(netlink connection)} module defines the following procedures, used |
233 | to connect and communicate with another process or the kernel using a netlink |
234 | socket. |
235 | |
236 | @deffn {Scheme Procedure} get-addr @var{family} @var{pid} @var{groups} |
237 | Return a bytevector that represents a netlink address. @var{family} |
238 | should be @code{AF_NETLINK}, @var{pid} is the PID of the process with which |
239 | to communicate or 0 for the kernel. @var{groups} is an integer representing |
240 | the set of broadcast groups to which the connection subscribes. |
241 | @end deffn |
242 | |
243 | @cindex non-blocking socket |
244 | @deffn {Scheme Procedure} connect @var{proto} @var{addr} [#:flags 0] |
245 | Creates a netlink socket for @var{proto} and binds it to @var{addr}. |
246 | |
247 | @var{proto} is the integer representing the protocol. For instance, rtnetlink |
248 | can be selected by usin @code{NETLINK_ROUTE} (defined in |
249 | @code{(netlink constant)}). |
250 | |
251 | @var{addr} is a bytevector, as returned by @code{get-addr}. |
252 | |
253 | @var{flags} is a set of additional flags to pass as the second argument |
254 | to the @code{socket} system call---e.g., @code{SOCK_NONBLOCK}. |
255 | @end deffn |
256 | |
257 | @deffn {Scheme Procedure} connect-route [#:groups 0] [#:flags 0] |
258 | This procedure is a wrapper for @code{connect} that creates a socket for the |
259 | rtnetlink protocol, binds it to the kernel and returns it. By passing the |
260 | optional @var{groups} keyword, you can select broadcast groups to subscribe to. |
261 | |
262 | @var{flags} is a set of additional flags to pass as the second argument |
263 | to the @code{socket} system call---e.g., @code{SOCK_NONBLOCK}. |
264 | @end deffn |
265 | |
266 | @cindex subscribing, to an rtnetlink group |
267 | @deffn {Scheme Procedure} add-socket-membership @var{sock} @var{group} |
268 | Make @var{sock} a member of @var{group}, an @code{RTNLGRP_} constant, |
269 | meaning that it will be subscribed to events of that group. |
270 | |
271 | For example, here is how you could create a netlink socket and subscribe |
272 | it to the ``link'' group so that it receives notifications for new and |
273 | removed links: |
274 | |
275 | @lisp |
276 | (let ((sock (connect-route))) |
277 | (add-socket-membership sock RTNLGRP_LINK) |
278 | @dots{}) |
279 | @end lisp |
280 | |
281 | This procedure is implemented as a @code{setsockopt} call. |
282 | @end deffn |
283 | |
284 | @deffn {Scheme Procedure} send-msg @var{msg} @var{sock} [#:@var{addr}] |
285 | Send @var{msg} (it must be of type message, @xref{Netlink Headers}) to |
286 | @var{addr} using @var{sock}. If not passed, @var{addr} is the address of |
287 | the kernel. |
288 | @end deffn |
289 | |
290 | @deffn {Scheme Procedure} receive-msg @var{sock} [#:@var{addr}] |
291 | Receives a message from @var{sock} from @var{addr}. This procedure is blocking. |
292 | If not passed, @var{addr} defaults to the address of the kernel. This |
293 | procedure returns the message as a bytevector, that you can deserialize with |
294 | @code{deserialize} (@xref{Data Types}) |
295 | @end deffn |
296 | |
297 | @deffn {Scheme Procedure} receive-and-decode-msg @var{sock} @var{decoder} @ |
298 | [#:@var{addr}] |
299 | Receives one or more messages from @var{sock} from @var{addr}. this procedure |
300 | is blocking. If not passed, @var{addr} defaults to the address of the kernel. |
301 | This procedure returns a list of messages that were decoded using @var{decoder}. |
302 | |
303 | When the answer has the @code{NLM_F_MULTI} flag, this procedure decodes the next |
304 | message, until it receives a @code{NLMSG_DONE} message. It returns the list |
305 | of every netlink messages it received, including the @code{NLMSG_DONE}. |
306 | @end deffn |
307 | |
308 | @node Netlink API |
309 | @section Netlink API |
310 | |
311 | This section introduces the data structures used for all the netlink protocols. |
312 | First, we introduce the structure of a netlink message, then we present the |
313 | standard types of netlink messages, that can be used with every protocol. |
314 | |
315 | @node Netlink Headers |
316 | @subsection Netlink Headers |
317 | |
318 | The @code{(netlink message)} module defines the message structure that contains |
319 | a netlink message. It is composed of a header and a body, and is the data |
320 | structure to pass to @code{send-msg} (@xref{Netlink Connections}). |
321 | |
322 | This module defines the following data structure: |
323 | |
324 | @deffn {Datatype} message |
325 | @table @asis |
326 | @item @code{type} |
327 | The type of data in the body of the message. For instance, @code{RTM_GETLINK}. |
328 | |
329 | @item @code{flags} |
330 | The set of flags that are set in the header. For instance, |
331 | @code{(logior NLM_F_REQUEST NLM_F_DUMP)}. |
332 | |
333 | @item @code{seq} |
334 | The sequence number of the message. If this message is an answer to a request, |
335 | it must keep the same sequence number. Otherwise, you must generate a new and |
336 | unique sequence number, to track the answers. |
337 | |
338 | @item @code{pid} |
339 | The PID of the receiving process, or 0 for the kernel. |
340 | |
341 | @item @code{data} |
342 | The actual body, as an @code{nl-data} structure. |
343 | |
344 | @end table |
345 | @end deffn |
346 | |
347 | @node Standard Message Types |
348 | @subsection Standard Message Types |
349 | |
350 | The @code{(netlink standard)} module defines the set of standard message types |
351 | and their data type. |
352 | |
353 | @deffn {Datatype} error-message |
354 | @table @asis |
355 | @item @code{err} |
356 | The error code, as a negative number. |
357 | |
358 | @item @code{hdr} |
359 | The message on which this error applies. |
360 | |
361 | @end table |
362 | |
363 | @deffn {Scheme Variable} no-data |
364 | This variable defines the absence of data. This is useful when a structure |
365 | is expecting a body part, but the protocol specifically defines that it should |
366 | not take any data in some cases. For instance, a @code{NLMSG_NOOP} message |
367 | takes no data, so the @code{data} field of the message will contain this |
368 | @code{no-data} value. |
369 | @end deffn |
370 | |
371 | @end deffn |
372 | |
373 | @node Rtnetlink API |
374 | @section Rtnetlink API |
375 | @cindex rtnetlink |
376 | @cindex ROUTE_NETLINK |
377 | |
378 | This section describes the support for rtnetlink in guile-netlink. Rtnetlink |
379 | is the protocol responsible for everything related to network routing. It |
380 | allows you to manage links, addresses, routing tables, neighbor chaces, |
381 | routing rules, queueing disciplines, traffic classes, traffic filters and |
382 | more. |
383 | |
384 | @node Routing Attributes |
385 | @subsection Routing Attributes |
386 | |
387 | The @code{(netlink route attrs)} module defines the following data types: |
388 | |
389 | @deffn {Datatype} route-attr |
390 | This defines a header structure for the attribute, as well as its body. |
391 | |
392 | @table @asis |
393 | @item @code{type} |
394 | This is the type of the attribute, for instance @code{IFLA_ADDRESS}. |
395 | |
396 | @item @code{data} |
397 | This is the body of the attribute, ie.@: its value. |
398 | @end table |
399 | @end deffn |
400 | |
401 | The module also defines additional data types that are not represented as |
402 | a record, but by a simple type. For each of the following types, there is |
403 | a @code{make-*-route-attr} procedure to produce a @code{nl-data} value |
404 | for this type. There is also @code{deserialize-route-attr-data-*} procedure |
405 | to deserialize a value of this type. |
406 | |
407 | @table @asis |
408 | @item @code{u8} |
409 | A one-byte unsigned integer |
410 | @item @code{u16} |
411 | A two-bytes unsigned integer |
412 | @item @code{u32} |
413 | A four-bytes unsigned integer |
414 | @item @code{s32} |
415 | A four-bytes signed integer |
416 | @item @code{string} |
417 | A string |
418 | @item @code{ethernet} |
419 | An ethernet address. Its value is a string that represents that address, |
420 | for instnace @code{"01:23:45:67:89:ab"} |
421 | @item @code{ipv4} |
422 | An IPv4 address. Its value is a string that represents that address, |
423 | for instnace @code{"192.0.2.152"} |
424 | @item @code{ipv6} |
425 | An IPv6 address. Its value is a string that represents that address, |
426 | for instnace @code{"2001:db8::0123:4567:89ab:cdef"} |
427 | @item @code{bv} |
428 | A bytevector. This is used by default when the type is not supported. |
429 | @end table |
430 | |
431 | @node Link Messages |
432 | @subsection Link Messages |
433 | |
434 | The @code{(netlink route link)} package defines the following data type: |
435 | |
436 | @deffn {Datatype} link-message |
437 | This datatype represents a link message with its routing attributes. This type |
438 | of message is expected when using the @var{RTM_*LINK} message types. |
439 | |
440 | @table @asis |
441 | @item @code{family} |
442 | The network family, defined as @code{AF_UNSPEC} in the rtnetlink documentation, |
443 | although it holds different values in practice. |
444 | |
445 | @item @code{type} |
446 | The device type. |
447 | |
448 | @item @code{index} |
449 | The index of the device. This is used to select a specific device by its index, |
450 | or 0 to not filter by device index. |
451 | |
452 | @item @code{flags} |
453 | The device flags. See @code{man 7 netdevices} for a list. |
454 | |
455 | @item @code{attrs} |
456 | A list of attributes. This field must contain a list of @code{nl-data} |
457 | structures, not a structure by itself. |
458 | @end table |
459 | @end deffn |
460 | |
461 | @node Address Messages |
462 | @subsection Address Messages |
463 | |
464 | The @code{(netlink route addr)} package defines the following data type: |
465 | |
466 | @deffn {Datatype} addr-message |
467 | This datatype represents an address message with its routing attributes. This |
468 | type of message is expected when using the @var{RTM_*ADDR} message types. |
469 | |
470 | @table @asis |
471 | @item @code{family} |
472 | The network family, either @code{AF_INET} for IPv4 addresses, or @code{AF_INET6} |
473 | for IPv6 addresses. |
474 | |
475 | @item @code{prefix-len} |
476 | The prefix length, i.e.@: the length of the prefix mask, in bits, if defined |
477 | for the address family. |
478 | |
479 | @item @code{flags} |
480 | Address flags. This can be a flag word of @code{IFA_F_SECONDARY} for secondary |
481 | address (old alias interface), @code{IFA_F_PERMANENT} for a permanent |
482 | address set by the user and other undocumented flags. |
483 | |
484 | @item @code{scope} |
485 | The address scope. |
486 | |
487 | @item @code{index} |
488 | The index of the device this address is for. |
489 | |
490 | @item @code{attrs} |
491 | A list of attributes. This field must contain a list of @code{nl-data} |
492 | structures, not a structure by itself. |
493 | @end table |
494 | @end deffn |
495 | |
496 | @node IP Library |
497 | @chapter IP Library |
498 | |
499 | This library comes with higher-level procedures that let you access and modify |
500 | the state of network on your computer. |
501 | |
502 | @node Link |
503 | @section Link |
504 | |
505 | The @code{(ip link)} module introduces procedures to access and modify the |
506 | network links on your machine. They are equivalent to the @command{ip link} |
507 | family of commands, from @code{iproute2}. |
508 | |
509 | @deffn {Datatype} <link> |
510 | |
511 | Datatype representing the status of a network link. |
512 | |
513 | get-links |
514 | print-link |
515 | |
516 | <link> make-link link? |
517 | link-name link-id link-type link-flags link-mtu link-qdisc |
518 | link-state link-mode link-group link-qlen link-addr link-brd |
519 | |
520 | @table @asis |
521 | @item @code{name} |
522 | Name of the link, such as @code{"enp1s0"}. |
523 | |
524 | @item @code{id} |
525 | Index of the link, a unique number used to identify the link. |
526 | |
527 | @item @code{type} |
528 | Type of the link, as an integer. |
529 | |
530 | @item @code{flags} |
531 | Flags associated with the device, as a list of symbols, such as |
532 | @code{'(UP LOOPBACK)}. |
533 | |
534 | @item @code{mtu} |
535 | MTU of the link, as an integer. |
536 | |
537 | @item @code{qdisc} |
538 | Queuing discipline of the link, as a string, such as @code{"noqueue"}. |
539 | |
540 | @item @code{state} |
541 | State of the link, as an integer. Use @code{int->operstate} from |
542 | @code{(netlink constant)} to get a symbol, such as @code{IF_OPER_UP}. |
543 | |
544 | @item @code{mode} |
545 | Mode of the link. 0 means @code{DORMANT}, 1 means @code{DEFAULT}. |
546 | |
547 | @item @code{group} |
548 | Identifier of the group it belongs to. 0 for @code{default}. |
549 | |
550 | @item @code{qlen} |
551 | Size of the queue. |
552 | |
553 | @item @code{addr} |
554 | Ethernet address of the link, as a string. |
555 | |
556 | @item @code{brd} |
557 | Broadcast (ethernet) address of the link, as a string. |
558 | |
559 | @end table |
560 | @end deffn |
561 | |
562 | @deffn {Scheme Procedure} get-links |
563 | Returns the list of existing links in the system, as a list of @code{<link>} |
564 | objects. |
565 | @end deffn |
566 | |
567 | @deffn {Sceme Procedure} print-link @var{link} |
568 | Display @var{link} on the standard output, using a format similar to |
569 | @command{ip link} from @code{iproute2}. |
570 | @end deffn |
571 | |
572 | @deffn {Scheme Procedure} link-set @var{device} [#:up @code{#f}] @ |
573 | [#:down @code{#f}] [#:type @code{#f}] [#:arp-on @code{#f}] @ |
574 | [#:arp-off @code{#f}] [#:dynamic-on @code{#f}] [#:dynamic-off @code{#f}] @ |
575 | [#:multicast-on @code{#f}] [#:multicast-off @code{#f}] @ |
576 | [#:allmulticast-on @code{#f}] [#:allmulticast-off @code{#f}] @ |
577 | [#:promisc-on @code{#f}] [#:promisc-off @code{#f}] [#:trailers-on @code{#f}] @ |
578 | [#:trailers-off @code{#f}] [#:carrier-on @code{#f}] [#:carrier-off @code{#f}] @ |
579 | [#:txqueuelen @code{#f}] [#:name @code{#f}] [#:address @code{#f}] @ |
580 | [#:broadcast @code{#f}] [#:mtu @code{#f}] [#:netns @code{#f}] |
581 | Modify an existing link and set its flags and attributes to the ones specified |
582 | by the various keywords. When a keyword is omited, the corresponding attribute |
583 | is not changed. |
584 | |
585 | @var{device} can be a device index (as a number) or a device name (as a string). |
586 | |
587 | Do not set @code{#:up} and @code{#:down} at the same time. Do not set |
588 | @code{*-on} and @code{*-off} at the same time. |
589 | @end deffn |
590 | |
591 | @deffn {Scheme Procedure} link-show [#:device @code{#f}] [#:group @code{#f}] @ |
592 | [#:up @code{#f}] [#:master @code{#f}] [#:vrf @code{#f}] [#:type @code{#f}] |
593 | Print the set of devices on standard output. Setting any of the keyword to a |
594 | non-false value will filter the results to only show results that match the |
595 | corresponding value. You may set more than one keyword. |
596 | @end deffn |
597 | |
598 | @deffn {Scheme Procedure} link-add @var{name} @var{type} [#:type-args @code{'()}] |
599 | Add a new link with given name and type. Additional arguments can be passed to |
600 | control the state of the link at creation. @var{type-args} is an association |
601 | list containing additional values for the given type. |
602 | |
603 | When @var{type} is @code{"vlan"}, @var{type-args} can contain a number associated |
604 | with @code{'id}: the VLAN id to be created and a link name associated with |
605 | @code{"link"}: the name of the link on which the vlan is created. |
606 | |
607 | The following is an example in which we create a new vlan link: |
608 | @example |
609 | ;; same as "ip l add link eth0 name eth0.7 type vlan id 7" |
610 | (link-add "eth0.7" "vlan" #:type-args '((id . 7) (link . "eth0"))) |
611 | @end example |
612 | |
613 | When @var{type} is @code{"veth"}, @var{type-args} can contain a string associated |
614 | with @code{'peer}: the name of the peer. |
615 | |
616 | The following is an example in which we create a new veth (virtual ethernet) |
617 | pair and give them a name: |
618 | @example |
619 | ;; same as "ip l add v0p0 type veth peer v0p1" |
620 | (link-add "v0p0" "veth" #:type-args '((peer . "v0p1"))) |
621 | @end example |
622 | @end deffn |
623 | |
624 | @deffn {Scheme Procedure} link-del @var{device} |
625 | Delete a link. @var{device} can contain the name of the link, as a string, |
626 | or its index, as a number. |
627 | @end deffn |
628 | |
629 | @node Addr |
630 | @section Addr |
631 | |
632 | The @code{(ip addr)} module introduces procedures to access and modify the |
633 | network addresses on your machine. They are equivalent to the @command{ip addr} |
634 | family of commands, from @code{iproute2}. |
635 | |
636 | @deffn {Scheme Procedure} addr-add @var{device} @var{cidr} [@var{#:ipv6?} #f] @ |
637 | [@var{#:peer} @code{(cidr->addr cidr)}] [@var{#:broadcast} #f] @ |
638 | [@var{#:anycast} #f] [@var{#:label} #f] [@var{#:scope} @code{'global}] @ |
639 | [@var{#:metric} #f] [@var{#:home?} #f] [@var{#:mngtmpaddr?} #f] @ |
640 | [@var{#:nodad?} #f] [@var{optimistic?} #f] [@var{noprefixroute?} #f] @ |
641 | [@var{#:autojoin?} #f] |
642 | Add the address given in @var{cidr} to @var{device}. @var{device} can |
643 | contain the name of the link, as a string, or its index, as a number. |
644 | |
645 | @var{cidr} must be a string containing the address and prefix length, in |
646 | CIDR notation (@code{addr/prefix}). |
647 | |
648 | @example |
649 | (addr-add "enp1s0" "192.0.2.15/24") |
650 | @end example |
651 | |
652 | If you wish to add an IPv6 address instead, set @code{#:ipv6} to @code{#t}, |
653 | as in the following example. |
654 | |
655 | @example |
656 | (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t) |
657 | @end example |
658 | |
659 | Note that using the wrong ip type with the wrong value for the @code{#:ipv6?} |
660 | flag will result in a @code{Bad address} exception from inet-pton. |
661 | |
662 | Additional flags are available; they follow the same semantics as Iproute2. |
663 | For pointopoint interfaces, you can specify the address of the remote endpoint |
664 | with @var{#:peer}. You can specify a broadcast or anycast address with |
665 | @var{#:broadcast} and @var{#:anycast}. All three require an IP address passed |
666 | as a string when specified. |
667 | |
668 | You can specify a label for the address with @var{#:label}. The parameter must |
669 | be a string that is either the name of the device, or starts with the name of |
670 | the device, followed by a colon and must contain at most 15 characters. |
671 | |
672 | You can specify a scope with @var{#:scope}, whose value is either @code{'global}, |
673 | @code{'link}, @code{'host} or a numeric value. |
674 | |
675 | You can specify the priority of the prefix route associated with this address |
676 | using @code{#:metric}, a number. |
677 | |
678 | Finally, this procedures accepts address configuration flags, whose values are |
679 | booleans. They are unset by default. Some flags only work for IPv6 addresses, |
680 | those are @var{#:home?} to designate this address as the ``home address'', |
681 | @var{#:mngtmpaddr?}, @var{#:nodad?} and @var{#:optimistic?}. The flags |
682 | @var{#:noprefixroute?} and @var{#:autojoin?} can be set for IPv4 and IPv6 |
683 | addresses. |
684 | @end deffn |
685 | |
686 | @deffn {Scheme Procedure} addr-del @var{device} @var{cidr} [@var{#:ipv6?} #f] @ |
687 | [@var{#:peer} @code{(cidr->addr cidr)}] [@var{#:broadcast} #f] @ |
688 | [@var{#:anycast} #f] [@var{#:label} #f] [@var{#:scope} @code{'global}] @ |
689 | [@var{#:metric} #f] [@var{#:home?} #f] [@var{#:mngtmpaddr?} #f] @ |
690 | [@var{#:nodad?} #f] [@var{optimistic?} #f] [@var{noprefixroute?} #f] @ |
691 | [@var{#:autojoin?} #f] |
692 | Delete the address given in @var{cidr} from @var{device}. @var{device} can |
693 | contain the name of the link, as a string, or its index, as a number. |
694 | |
695 | @var{cidr} must be a string containing the address and prefix length, in |
696 | CIDR notation (@code{addr/prefix}). |
697 | |
698 | @example |
699 | (addr-del "enp1s0" "192.0.2.15/24") |
700 | @end example |
701 | |
702 | If you wish to remove an IPv6 address instead, set @code{#:ipv6} to @code{#t}, |
703 | as in the following example. |
704 | |
705 | @example |
706 | (addr-del "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t) |
707 | @end example |
708 | |
709 | Note that using the wrong ip type with the wrong value for the @code{#:ipv6?} |
710 | flag will result in a @code{Bad address} exception from inet-pton. |
711 | |
712 | Additional flags are available, see the description in @code{addr-add} for more |
713 | details. |
714 | @end deffn |
715 | |
716 | @deffn {Scheme Procedure} addr-show [@var{device}] |
717 | Print the list of addresses for each device on standard output. Setting |
718 | @code{device} to a link name or link identifier will restrict the output |
719 | to addresses of that device. |
720 | @end deffn |
721 | |
722 | @node Route |
723 | @section Route |
724 | |
725 | The @code{(ip route)} module introduces procedures to access and modify the |
726 | network routes on your machine. They are equivalent to the @command{ip route} |
727 | family of commands, from @code{iproute2}. |
728 | |
729 | @deffn {Scheme Procedure} route-add @var{dest} [@var{#:ipv6?} #f] @ |
730 | [@var{#:device} #f] [@var{#:table} RT_TABLE_MAIN] [@var{#:protocol} #f] @ |
731 | [@var{#:scope} RT_SCOPE_LINK] [@var{#:type} RTN_UNICAST] @ |
732 | [@var{#:priority} #f] [@var{#:src} #f] [@var{#:via} #f] |
733 | Add the route described by the argmuents. @var{dest} is the destination network, |
734 | in cidr notation (@code{addr/prefix}) or the string @code{"default"}. |
735 | |
736 | @var{#:device} is the name or index of a network link. @var{#:table} is the |
737 | index of a routing table, one of @code{RT_TABLE_COMPAT}, @code{RT_TABLE_DEFAULT}, |
738 | @code{RT_TABLE_MAIN} or @code{RT_TABLE_LOCAL}, as defined in |
739 | @code{(netlink constant)}. |
740 | |
741 | If it is set, @var{#:protocol} must be the routing protocol, @code{RTPROT_*}, |
742 | as defined in @code{(netlink constant)}. |
743 | |
744 | @var{#:scope} must be the scope of the route, one of @code{RT_SCOPE_*}, as |
745 | defined in @code{(netlink constant)}. |
746 | |
747 | @var{#:type} must be the type of route, one of @code{RTN_*}, as defined in |
748 | @code{(netlink constant)}. |
749 | |
750 | If set, @var{#:priority} is a number specifying the priority of the rule |
751 | when the kernel is looking for a matching rule. This is also known as the |
752 | metric of the route. |
753 | |
754 | If set, @var{#:src} is the source address in cidr notation, or as a single |
755 | address. |
756 | |
757 | If set, @var{#:via} is the gateway address. This is not in cidr notation, as |
758 | the gateway is a single address, not a network. |
759 | |
760 | @example |
761 | (route-add "default" #:device "enp1s0" #:via "192.0.2.1") |
762 | (route-add "192.0.2.0/24" #:device "enp1s0" #:src "192.0.2.15") |
763 | @end example |
764 | |
765 | If you wish to add an IPv6 route instead, set @code{#:ipv6} to @code{#t}, |
766 | as in the following example. |
767 | |
768 | @example |
769 | (addr-add "2001:db8::/64" #:device "enp1s0" #:src "2001:db8::1a4c" #:ipv6? #t) |
770 | @end example |
771 | |
772 | Note that using the wrong ip type with the wrong value for the @code{#:ipv6?} |
773 | flag will result in a @code{Bad address} exception from inet-pton. |
774 | @end deffn |
775 | |
776 | @deffn {Scheme Procedure} route-del @var{dest} [@var{#:ipv6?} #f] @ |
777 | [@var{#:device} #f] [@var{#:table} RT_TABLE_MAIN] [@var{#:protocol} #f] @ |
778 | [@var{#:scope} #f] [@var{#:type} #f] [@var{#:priority} #f] @ |
779 | [@var{#:src} #f] [@var{#:via} #f] |
780 | Delete the route given in arguments. The arguments follow the same structure |
781 | as @code{route-add}. By specifying more arguments, you can narrow down the |
782 | search for the rule to delete further. Each call will only remove one route, |
783 | so being more precise ensures you target the rule you wish to delete. It |
784 | is not clear which route is deleted if multiple routes match your query. |
785 | @end deffn |
786 | |
787 | @deffn {Scheme Procedure} route-show [@var{#:table} RT_TABLE_MAIN] @ |
788 | [@var{#:family} AF_UNSPEC] |
789 | Print the list of routes on standard output. Note that, contrary to |
790 | @command{ip route show}, we show both IPv4 and IPv6 routes. To narrow down the |
791 | number of routes displayed, you can specify the family as in this example. |
792 | |
793 | @example |
794 | (route-show #:family AF_INET6) |
795 | @end example |
796 | @end deffn |
797 | |
798 | @bye |
799 |