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 | @deffn {Scheme Procedure} connect @var{proto} @var{addr} |
244 | Creates a netlink socket for @var{proto} and binds it to @var{addr}. |
245 | |
246 | @var{proto} is the integer representing the protocol. For instance, rtnetlink |
247 | can be selected by usin @code{NETLINK_ROUTE} (defined in |
248 | @code{(netlink constant)}). |
249 | |
250 | @var{addr} is a bytevector, as returned by @code{get-addr}. |
251 | @end deffn |
252 | |
253 | @deffn {Scheme Procedure} connect-route [#:groups @code{0}] |
254 | This procedure is a wrapper for @code{connect} that creates a socket for the |
255 | rtnetlink protocol, binds it to the kernel and returns it. By passing the |
256 | optional @var{groups} keyword, you can select broadcast groups to subscribe to. |
257 | @end deffn |
258 | |
259 | @deffn {Scheme Procedure} close-socket @var{socket} |
260 | Closes a netlink socket. The socket cannot be used afterwards. |
261 | @end deffn |
262 | |
263 | @deffn {Scheme Procedure} send-msg @var{msg} @var{sock} [#:@var{addr}] |
264 | Send @var{msg} (it must be of type message, @xref{Netlink Headers}) to |
265 | @var{addr} using @var{sock}. If not passed, @var{addr} is the address of |
266 | the kernel. |
267 | @end deffn |
268 | |
269 | @deffn {Scheme Procedure} receive-msg @var{sock} [#:@var{addr}] |
270 | Receives a message from @var{sock} from @var{addr}. This procedure is blocking. |
271 | If not passed, @var{addr} defaults to the address of the kernel. This |
272 | procedure returns the message as a bytevector, that you can deserialize with |
273 | @code{deserialize} (@xref{Data Types}) |
274 | @end deffn |
275 | |
276 | @deffn {Scheme Procedure} receive-and-decode-msg @var{sock} @var{decoder} @ |
277 | [#:@var{addr}] |
278 | Receives one or more messages from @var{sock} from @var{addr}. this procedure |
279 | is blocking. If not passed, @var{addr} defaults to the address of the kernel. |
280 | This procedure returns a list of messages that were decoded using @var{decoder}. |
281 | |
282 | When the answer has the @code{NLM_F_MULTI} flag, this procedure decodes the next |
283 | message, until it receives a @code{NLMSG_DONE} message. It returns the list |
284 | of every netlink messages it received, including the @code{NLMSG_DONE}. |
285 | @end deffn |
286 | |
287 | @node Netlink API |
288 | @section Netlink API |
289 | |
290 | This section introduces the data structures used for all the netlink protocols. |
291 | First, we introduce the structure of a netlink message, then we present the |
292 | standard types of netlink messages, that can be used with every protocol. |
293 | |
294 | @node Netlink Headers |
295 | @subsection Netlink Headers |
296 | |
297 | The @code{(netlink message)} module defines the message structure that contains |
298 | a netlink message. It is composed of a header and a body, and is the data |
299 | structure to pass to @code{send-msg} (@xref{Netlink Connections}). |
300 | |
301 | This module defines the following data structure: |
302 | |
303 | @deffn {Datatype} message |
304 | @table @asis |
305 | @item @code{type} |
306 | The type of data in the body of the message. For instance, @code{RTM_GETLINK}. |
307 | |
308 | @item @code{flags} |
309 | The set of flags that are set in the header. For instance, |
310 | @code{(logior NLM_F_REQUEST NLM_F_DUMP)}. |
311 | |
312 | @item @code{seq} |
313 | The sequence number of the message. If this message is an answer to a request, |
314 | it must keep the same sequence number. Otherwise, you must generate a new and |
315 | unique sequence number, to track the answers. |
316 | |
317 | @item @code{pid} |
318 | The PID of the receiving process, or 0 for the kernel. |
319 | |
320 | @item @code{data} |
321 | The actual body, as an @code{nl-data} structure. |
322 | |
323 | @end table |
324 | @end deffn |
325 | |
326 | @node Standard Message Types |
327 | @subsection Standard Message Types |
328 | |
329 | The @code{(netlink standard)} module defines the set of standard message types |
330 | and their data type. |
331 | |
332 | @deffn {Datatype} error-message |
333 | @table @asis |
334 | @item @code{err} |
335 | The error code, as a negative number. |
336 | |
337 | @item @code{hdr} |
338 | The message on which this error applies. |
339 | |
340 | @end table |
341 | |
342 | @deffn {Scheme Variable} no-data |
343 | This variable defines the absence of data. This is useful when a structure |
344 | is expecting a body part, but the protocol specifically defines that it should |
345 | not take any data in some cases. For instance, a @code{NLMSG_NOOP} message |
346 | takes no data, so the @code{data} field of the message will contain this |
347 | @code{no-data} value. |
348 | @end deffn |
349 | |
350 | @end deffn |
351 | |
352 | @node Rtnetlink API |
353 | @section Rtnetlink API |
354 | @cindex rtnetlink |
355 | @cindex ROUTE_NETLINK |
356 | |
357 | This section describes the support for rtnetlink in guile-netlink. Rtnetlink |
358 | is the protocol responsible for everything related to network routing. It |
359 | allows you to manage links, addresses, routing tables, neighbor chaces, |
360 | routing rules, queueing disciplines, traffic classes, traffic filters and |
361 | more. |
362 | |
363 | @node Routing Attributes |
364 | @subsection Routing Attributes |
365 | |
366 | The @code{(netlink route attrs)} module defines the following data types: |
367 | |
368 | @deffn {Datatype} route-attr |
369 | This defines a header structure for the attribute, as well as its body. |
370 | |
371 | @table @asis |
372 | @item @code{type} |
373 | This is the type of the attribute, for instance @code{IFLA_ADDRESS}. |
374 | |
375 | @item @code{data} |
376 | This is the body of the attribute, ie.@: its value. |
377 | @end table |
378 | @end deffn |
379 | |
380 | The module also defines additional data types that are not represented as |
381 | a record, but by a simple type. For each of the following types, there is |
382 | a @code{make-*-route-attr} procedure to produce a @code{nl-data} value |
383 | for this type. There is also @code{deserialize-route-attr-data-*} procedure |
384 | to deserialize a value of this type. |
385 | |
386 | @table @asis |
387 | @item @code{u8} |
388 | A one-byte unsigned integer |
389 | @item @code{u16} |
390 | A two-bytes unsigned integer |
391 | @item @code{u32} |
392 | A four-bytes unsigned integer |
393 | @item @code{s32} |
394 | A four-bytes signed integer |
395 | @item @code{string} |
396 | A string |
397 | @item @code{ethernet} |
398 | An ethernet address. Its value is a string that represents that address, |
399 | for instnace @code{"01:23:45:67:89:ab"} |
400 | @item @code{ipv4} |
401 | An IPv4 address. Its value is a string that represents that address, |
402 | for instnace @code{"192.0.2.152"} |
403 | @item @code{ipv6} |
404 | An IPv6 address. Its value is a string that represents that address, |
405 | for instnace @code{"2001:db8::0123:4567:89ab:cdef"} |
406 | @item @code{bv} |
407 | A bytevector. This is used by default when the type is not supported. |
408 | @end table |
409 | |
410 | @node Link Messages |
411 | @subsection Link Messages |
412 | |
413 | The @code{(netlink route link)} package defines the following data type: |
414 | |
415 | @deffn {Datatype} link-message |
416 | This datatype represents a link message with its routing attributes. This type |
417 | of message is expected when using the @var{RTM_*LINK} message types. |
418 | |
419 | @table @asis |
420 | @item @code{family} |
421 | The network family, defined as @code{AF_UNSPEC} in the rtnetlink documentation, |
422 | although it holds different values in practice. |
423 | |
424 | @item @code{type} |
425 | The device type. |
426 | |
427 | @item @code{index} |
428 | The index of the device. This is used to select a specific device by its index, |
429 | or 0 to not filter by device index. |
430 | |
431 | @item @code{flags} |
432 | The device flags. See @code{man 7 netdevices} for a list. |
433 | |
434 | @item @code{attrs} |
435 | A list of attributes. This field must contain a list of @code{nl-data} |
436 | structures, not a structure by itself. |
437 | @end table |
438 | @end deffn |
439 | |
440 | @node Address Messages |
441 | @subsection Address Messages |
442 | |
443 | The @code{(netlink route addr)} package defines the following data type: |
444 | |
445 | @deffn {Datatype} addr-message |
446 | This datatype represents an address message with its routing attributes. This |
447 | type of message is expected when using the @var{RTM_*ADDR} message types. |
448 | |
449 | @table @asis |
450 | @item @code{family} |
451 | The network family, either @code{AF_INET} for IPv4 addresses, or @code{AF_INET6} |
452 | for IPv6 addresses. |
453 | |
454 | @item @code{prefix-len} |
455 | The prefix length, i.e.@: the length of the prefix mask, in bits, if defined |
456 | for the address family. |
457 | |
458 | @item @code{flags} |
459 | Address flags. This can be a flag word of @code{IFA_F_SECONDARY} for secondary |
460 | address (old alias interface), @code{IFA_F_PERMANENT} for a permanent |
461 | address set by the user and other undocumented flags. |
462 | |
463 | @item @code{scope} |
464 | The address scope. |
465 | |
466 | @item @code{index} |
467 | The index of the device this address is for. |
468 | |
469 | @item @code{attrs} |
470 | A list of attributes. This field must contain a list of @code{nl-data} |
471 | structures, not a structure by itself. |
472 | @end table |
473 | @end deffn |
474 | |
475 | @node IP Library |
476 | @chapter IP Library |
477 | |
478 | This library comes with higher-level procedures that let you access and modify |
479 | the state of network on your computer. |
480 | |
481 | @node Link |
482 | @section Link |
483 | |
484 | The @code{(ip link)} module introduces procedures to access and modify the |
485 | network links on your machine. They are equivalent to the @command{ip link} |
486 | family of commands, from @code{iproute2}. |
487 | |
488 | @deffn {Datatype} <link> |
489 | |
490 | Datatype representing the status of a network link. |
491 | |
492 | get-links |
493 | print-link |
494 | |
495 | <link> make-link link? |
496 | link-name link-id link-type link-flags link-mtu link-qdisc |
497 | link-state link-mode link-group link-qlen link-addr link-brd |
498 | |
499 | @table @asis |
500 | @item @code{name} |
501 | Name of the link, such as @code{"enp1s0"}. |
502 | |
503 | @item @code{id} |
504 | Index of the link, a unique number used to identify the link. |
505 | |
506 | @item @code{type} |
507 | Type of the link, as an integer. |
508 | |
509 | @item @code{flags} |
510 | Flags associated with the device, as a list of symbols, such as |
511 | @code{'(UP LOOPBACK)}. |
512 | |
513 | @item @code{mtu} |
514 | MTU of the link, as an integer. |
515 | |
516 | @item @code{qdisc} |
517 | Queuing discipline of the link, as a string, such as @code{"noqueue"}. |
518 | |
519 | @item @code{state} |
520 | State of the link, as an integer. Use @code{int->operstate} from |
521 | @code{(netlink constant)} to get a symbol, such as @code{IF_OPER_UP}. |
522 | |
523 | @item @code{mode} |
524 | Mode of the link. 0 means @code{DORMANT}, 1 means @code{DEFAULT}. |
525 | |
526 | @item @code{group} |
527 | Identifier of the group it belongs to. 0 for @code{default}. |
528 | |
529 | @item @code{qlen} |
530 | Size of the queue. |
531 | |
532 | @item @code{addr} |
533 | Ethernet address of the link, as a string. |
534 | |
535 | @item @code{brd} |
536 | Broadcast (ethernet) address of the link, as a string. |
537 | |
538 | @end table |
539 | @end deffn |
540 | |
541 | @deffn {Scheme Procedure} get-links |
542 | Returns the list of existing links in the system, as a list of @code{<link>} |
543 | objects. |
544 | @end deffn |
545 | |
546 | @deffn {Sceme Procedure} print-link @var{link} |
547 | Display @var{link} on the standard output, using a format similar to |
548 | @command{ip link} from @code{iproute2}. |
549 | @end deffn |
550 | |
551 | @deffn {Scheme Procedure} link-set @var{device} [#:up @code{#f}] @ |
552 | [#:down @code{#f}] [#:type @code{#f}] [#:arp-on @code{#f}] @ |
553 | [#:arp-off @code{#f}] [#:dynamic-on @code{#f}] [#:dynamic-off @code{#f}] @ |
554 | [#:multicast-on @code{#f}] [#:multicast-off @code{#f}] @ |
555 | [#:allmulticast-on @code{#f}] [#:allmulticast-off @code{#f}] @ |
556 | [#:promisc-on @code{#f}] [#:promisc-off @code{#f}] [#:trailers-on @code{#f}] @ |
557 | [#:trailers-off @code{#f}] [#:carrier-on @code{#f}] [#:carrier-off @code{#f}] @ |
558 | [#:txqueuelen @code{#f}] [#:name @code{#f}] [#:address @code{#f}] @ |
559 | [#:broadcast @code{#f}] [#:mtu @code{#f}] [#:netns @code{#f}] |
560 | Modify an existing link and set its flags and attributes to the ones specified |
561 | by the various keywords. When a keyword is omited, the corresponding attribute |
562 | is not changed. |
563 | |
564 | @var{device} can be a device index (as a number) or a device name (as a string). |
565 | |
566 | Do not set @code{#:up} and @code{#:down} at the same time. Do not set |
567 | @code{*-on} and @code{*-off} at the same time. |
568 | @end deffn |
569 | |
570 | @deffn {Scheme Procedure} link-show [#:device @code{#f}] [#:group @code{#f}] @ |
571 | [#:up @code{#f}] [#:master @code{#f}] [#:vrf @code{#f}] [#:type @code{#f}] |
572 | Print the set of devices on standard output. Setting any of the keyword to a |
573 | non-false value will filter the results to only show results that match the |
574 | corresponding value. You may set more than one keyword. |
575 | @end deffn |
576 | |
577 | @deffn {Scheme Procedure} link-add @var{name} @var{type} [#:type-args @code{'()}] |
578 | Add a new link with given name and type. Additional arguments can be passed to |
579 | control the state of the link at creation. @var{type-args} is an association |
580 | list containing additional values for the given type. |
581 | |
582 | When @var{type} is @code{"vlan"}, @var{type-args} can contain a number associated |
583 | with @code{'id}: the VLAN id to be created. |
584 | |
585 | When @var{type} is @code{"veth"}, @var{type-args} can contain a string associated |
586 | with @code{'peer}: the name of the peer. |
587 | |
588 | The following is an example in which we create a new veth (virtual ethernet) |
589 | pair and give them a name: |
590 | @example |
591 | ;; same as "ip l add v0p0 type veth peer v0p1" |
592 | (link-add "v0p0" "veth" #:type-args '((peer . "v0p1"))) |
593 | @end example |
594 | @end deffn |
595 | |
596 | @deffn {Scheme Procedure} link-del @var{device} |
597 | Delete a link. @var{device} can contain the name of the link, as a string, |
598 | or its index, as a number. |
599 | @end deffn |
600 | |
601 | @node Addr |
602 | @section Addr |
603 | |
604 | The @code{(ip addr)} module introduces procedures to access and modify the |
605 | network addresses on your machine. They are equivalent to the @command{ip addr} |
606 | family of commands, from @code{iproute2}. |
607 | |
608 | @deffn {Scheme Procedure} addr-add @var{device} @var{cidr} [@var{#:ipv6?} #f] |
609 | Add the address given in @var{cidr} to @var{device}. @var{device} can |
610 | contain the name of the link, as a string, or its index, as a number. |
611 | |
612 | @var{cidr} must be a string containing the address and prefix length, in |
613 | CIDR notation (@code{addr/prefix}). |
614 | |
615 | @example |
616 | (addr-add "enp1s0" "192.0.2.15/24") |
617 | @end example |
618 | |
619 | If you wish to add an IPv6 address instead, set @code{#:ipv6} to @code{#t}, |
620 | as in the following example. |
621 | |
622 | @example |
623 | (addr-add "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t) |
624 | @end example |
625 | |
626 | Note that using the wrong ip type with the wrong value for the @code{#:ipv6?} |
627 | flag will result in a @code{Bad address} exception from inet-pton. |
628 | @end deffn |
629 | |
630 | @deffn {Scheme Procedure} addr-del @var{device} @var{cidr} [@var{#:ipv6?} #f] |
631 | Delete the address given in @var{cidr} from @var{device}. @var{device} can |
632 | contain the name of the link, as a string, or its index, as a number. |
633 | |
634 | @var{cidr} must be a string containing the address and prefix length, in |
635 | CIDR notation (@code{addr/prefix}). |
636 | |
637 | @example |
638 | (addr-del "enp1s0" "192.0.2.15/24") |
639 | @end example |
640 | |
641 | If you wish to remove an IPv6 address instead, set @code{#:ipv6} to @code{#t}, |
642 | as in the following example. |
643 | |
644 | @example |
645 | (addr-del "enp1s0" "2001:db8::1a4c/64" #:ipv6? #t) |
646 | @end example |
647 | |
648 | Note that using the wrong ip type with the wrong value for the @code{#:ipv6?} |
649 | flag will result in a @code{Bad address} exception from inet-pton. |
650 | @end deffn |
651 | |
652 | @deffn {Scheme Procedure} addr-show [@var{device}] |
653 | Print the list of addresses for each device on standard output. Setting |
654 | @code{device} to a link name or link identifier will restrict the output |
655 | to addresses of that device. |
656 | @end deffn |
657 | |
658 | @node Route |
659 | @section Route |
660 | |
661 | The @code{(ip route)} module introduces procedures to access and modify the |
662 | network routes on your machine. They are equivalent to the @command{ip route} |
663 | family of commands, from @code{iproute2}. |
664 | |
665 | @deffn {Scheme Procedure} route-add @var{dest} [@var{#:ipv6?} #f] @ |
666 | [@var{#:device} #f] [@var{#:table} RT_TABLE_MAIN] [@var{#:protocol} #f] @ |
667 | [@var{#:scope} RT_SCOPE_LINK] [@var{#:type} RTN_UNICAST] @ |
668 | [@var{#:priority} #f] [@var{#:src} #f] [@var{#:via} #f] |
669 | Add the route described by the argmuents. @var{dest} is the destination network, |
670 | in cidr notation (@code{addr/prefix}) or the string @code{"default"}. |
671 | |
672 | @var{#:device} is the name or index of a network link. @var{#:table} is the |
673 | index of a routing table, one of @code{RT_TABLE_COMPAT}, @code{RT_TABLE_DEFAULT}, |
674 | @code{RT_TABLE_MAIN} or @code{RT_TABLE_LOCAL}, as defined in |
675 | @code{(netlink constant)}. |
676 | |
677 | If it is set, @var{#:protocol} must be the routing protocol, @code{RTPROT_*}, |
678 | as defined in @code{(netlink constant)}. |
679 | |
680 | @var{#:scope} must be the scope of the route, one of @code{RT_SCOPE_*}, as |
681 | defined in @code{(netlink constant)}. |
682 | |
683 | @var{#:type} must be the type of route, one of @code{RTN_*}, as defined in |
684 | @code{(netlink constant)}. |
685 | |
686 | If set, @var{#:priority} is a number specifying the priority of the rule |
687 | when the kernel is looking for a matching rule. This is also known as the |
688 | metric of the route. |
689 | |
690 | If set, @var{#:src} is the source address in cidr notation, or as a single |
691 | address. |
692 | |
693 | If set, @var{#:via} is the gateway address. This is not in cidr notation, as |
694 | the gateway is a single address, not a network. |
695 | |
696 | @example |
697 | (route-add "default" #:device "enp1s0" #:via "192.0.2.1") |
698 | (route-add "192.0.2.0/24" #:device "enp1s0" #:src "192.0.2.15") |
699 | @end example |
700 | |
701 | If you wish to add an IPv6 route instead, set @code{#:ipv6} to @code{#t}, |
702 | as in the following example. |
703 | |
704 | @example |
705 | (addr-add "2001:db8::/64" #:device "enp1s0" #:src "2001:db8::1a4c" #:ipv6? #t) |
706 | @end example |
707 | |
708 | Note that using the wrong ip type with the wrong value for the @code{#:ipv6?} |
709 | flag will result in a @code{Bad address} exception from inet-pton. |
710 | @end deffn |
711 | |
712 | @deffn {Scheme Procedure} route-del @var{dest} [@var{#:ipv6?} #f] @ |
713 | [@var{#:device} #f] [@var{#:table} RT_TABLE_MAIN] [@var{#:protocol} #f] @ |
714 | [@var{#:scope} #f] [@var{#:type} #f] [@var{#:priority} #f] @ |
715 | [@var{#:src} #f] [@var{#:via} #f] |
716 | Delete the route given in arguments. The arguments follow the same structure |
717 | as @code{route-add}. By specifying more arguments, you can narrow down the |
718 | search for the rule to delete further. Each call will only remove one route, |
719 | so being more precise ensures you target the rule you wish to delete. It |
720 | is not clear which route is deleted if multiple routes match your query. |
721 | @end deffn |
722 | |
723 | @deffn {Scheme Procedure} route-show [@var{#:table} RT_TABLE_MAIN] @ |
724 | [@var{#:family} AF_UNSPEC] |
725 | Print the list of routes on standard output. Note that, contrary to |
726 | @command{ip route show}, we show both IPv4 and IPv6 routes. To narrow down the |
727 | number of routes displayed, you can specify the family as in this example. |
728 | |
729 | @example |
730 | (route-show #:family AF_INET6) |
731 | @end example |
732 | @end deffn |
733 | |
734 | @bye |
735 |