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 | |
| 51 | @end detailmenu |
| 52 | @end menu |
| 53 | |
| 54 | @node Introduction |
| 55 | @chapter Introduction |
| 56 | |
| 57 | Netlink is an inter-process communication protocol that can be used for |
| 58 | communication between processes, or with the kernel. It is implemented by |
| 59 | Linux. |
| 60 | |
| 61 | Many protocols exist on top of Netlink. The most famous are used to configure |
| 62 | network-related functions in the kernel, such as firewall, route table or |
| 63 | IP addresses of interfaces. |
| 64 | |
| 65 | This library implements the low-level bits of the code by providing data |
| 66 | structures that are close to their C counterpart, and basic procedures to |
| 67 | initiate communication. |
| 68 | |
| 69 | @node API Reference |
| 70 | @chapter API Reference |
| 71 | |
| 72 | @node Common API |
| 73 | @section Common API |
| 74 | |
| 75 | Guile-netlink implements a common API for expressing other protocols. This |
| 76 | section describes how to use this API to augment guile-netlink with additional |
| 77 | protocols. |
| 78 | |
| 79 | @node Data Types |
| 80 | @subsection Data Types |
| 81 | |
| 82 | Guile-netlink defines data types that are used in the various Netlink protocols. |
| 83 | We need to be able to serialize and deserialize data that guile-netlink |
| 84 | understands, but we also want to let users of guile-netlink extend this process |
| 85 | easily. This need has lead to the creating of the following data structure, |
| 86 | defined in @code{(netlink data}). |
| 87 | |
| 88 | @deffn {Datatype} nl-data |
| 89 | |
| 90 | @table @asis |
| 91 | @item @code{data} |
| 92 | The data that is held by this record. |
| 93 | |
| 94 | @item @code{size-proc} |
| 95 | A procedure that takes a data (of the same type as the data recorded in the |
| 96 | @code{data} field) and returns the size of its serialization. |
| 97 | |
| 98 | @item @code{serialization-proc} |
| 99 | A procedure that takes a data (of the same type as the data recorded in the |
| 100 | @code{data} field), the position at which to start serializing, and a |
| 101 | bytevector in which to serialize. This procedure should modify the bytevector |
| 102 | and its return value is ignored. |
| 103 | |
| 104 | @end table |
| 105 | @end deffn |
| 106 | |
| 107 | The module also defines the following function, that takes a @code{nl-data} |
| 108 | structure and provides its serialization in a bytevector: |
| 109 | |
| 110 | @deffn {Scheme Procedure} serialize @var{data} @var{pos} @var{bv} |
| 111 | Takes a @code{nl-data} structure as @var{data}, a position @var{pos} in |
| 112 | the bytevector @var{bv}, and returns an unspecified value. |
| 113 | |
| 114 | This function updates the bytevector and adds the serialization of @var{data} |
| 115 | into @var{bv} at @var{pos}. |
| 116 | @end deffn |
| 117 | |
| 118 | By providing a @code{nl-data} structure, we defer the knowledge of how to |
| 119 | serialize the data to the structure itself, instead of the @code{serialize} |
| 120 | function. This allows for more flexibility and extensibility, as the user |
| 121 | of the procedure can pass any kind of data, even if it is not yet supported by |
| 122 | guile-netlink. |
| 123 | |
| 124 | Similarly, we need to be able to deserialize netlink answers into a data |
| 125 | structure. To do so, we also defer the knowledge of the datastructure to |
| 126 | deserialize to, to a decoder structure that is passed to the deserialization |
| 127 | procedure. @code{(netlink data)} also defines the following procedures to |
| 128 | deserialize data: |
| 129 | |
| 130 | @deffn {Scheme Procedure} deserialize @var{type} @var{decoder} @var{bv} @var{pos} |
| 131 | Takes a bytevector @var{bv} and starts deserializing the data starting at |
| 132 | position @var{pos}. To do so, it uses the @var{type} variable as the lookup |
| 133 | key in the @var{decoder}. @var{type} is a symbol that represents the type of |
| 134 | data to deserialize to. |
| 135 | |
| 136 | The decoder is a structure that associates each known type to its deserializer |
| 137 | (a function that takes a decoder, a bytevector and a position and returns some |
| 138 | data) and an alist that associates a type (an integer, as returned by the |
| 139 | protocol in use) to the proper decoder of that type. |
| 140 | @end deffn |
| 141 | |
| 142 | @deffn {Scheme Procedure} get-current-deserialize @var{decoder} @var{current-type} |
| 143 | Takes a decoder and a type, and returns the deserialization procedure associated |
| 144 | with the type (a symbol) in @var{decoder}. |
| 145 | @end deffn |
| 146 | |
| 147 | @deffn {Scheme Procedure} get-next-deserialize @var{decoder} @var{current-type} @ |
| 148 | @var{target-type} |
| 149 | Takes a decoder, a type (a symbol that represents the type of data being |
| 150 | deserialized) and another type (an integer as returned by the protocol), and |
| 151 | returns the deserialization procedure needed to continue decoding the data |
| 152 | associated with the currently being deserialized data. |
| 153 | |
| 154 | For example, when decoding an answer in the netlink protocol, we first deserialize |
| 155 | the header into a @code{message} structure. That header contains a type field |
| 156 | that contains an integer constant representing the type of data of the body. |
| 157 | Similarly, when deserializing a routing attribute in the rtnetlink protocol, |
| 158 | we first find a header of the attribute that defines an integer constant |
| 159 | corresponding to the type of attribute in the body. |
| 160 | |
| 161 | By knowing the context in which the type is declared, this procedure can return |
| 162 | the correct deserializing procedure. For instance, when deserializing a |
| 163 | @code{message}, type @code{16} means @code{RTM_NEWLINK} in the rtnetlink |
| 164 | protocol, whereas it means @code{IFLA_OPERSTATE} when deserializing a |
| 165 | @code{route-attribute}. |
| 166 | @end deffn |
| 167 | |
| 168 | guile-netlink provides the following default decoder for the rtnetlink |
| 169 | protocol in @code{(netlink deserialize)}: |
| 170 | |
| 171 | @deffn {Scheme Variable} %default-route-decoder |
| 172 | Contains the default decoder for the NETLINK_ROUTE protocol. |
| 173 | @end deffn |
| 174 | |
| 175 | For convenience, guile-netlink defines the following structures that can be used |
| 176 | to create a custom decoder. |
| 177 | |
| 178 | @deffn {Scheme Variable} %default-message-decoder |
| 179 | Contains the default association list for the common message types of netlink, |
| 180 | associating each of them to a deserialization procedure. |
| 181 | @end deffn |
| 182 | |
| 183 | @deffn {Scheme Procedure} default-route-attr-decoder @var{deserialize-addr} |
| 184 | Creates the default association list for a route protocol, given the specified |
| 185 | address deserializer. This is useful because the @code{IFA_ADDRESS}, |
| 186 | @code{IFA_BROADCAST}, etc, contain a different type of address depending on |
| 187 | the message type or its header. This is defined an @code{(netlink route attrs)} |
| 188 | and used by the following variables: |
| 189 | @end deffn |
| 190 | |
| 191 | @deffn {Scheme Variable} %default-route-link-attr-decoder |
| 192 | Contains the default association list for the known types of routing attributes |
| 193 | for link messages. This list is defined in @code{(netlink route attrs)}. |
| 194 | @end deffn |
| 195 | |
| 196 | @node Constants |
| 197 | @subsection Constants |
| 198 | |
| 199 | Guile-netlink defines constants used by the Netlink protocols in the |
| 200 | @code{(netlink constant)} module. The constants are the ones present in the |
| 201 | kernel and are too numerous to list here. Please see the source for the |
| 202 | complete list. |
| 203 | |
| 204 | The module also defines the following macro: |
| 205 | |
| 206 | @deffn {Scheme Macro} define-enum @var{integer->symbol} @var{name-spec} ... |
| 207 | This macros defines an enumeration. @var{integer->symbol} is the name of |
| 208 | a procedure that is publicly defined, that takes an integer and returns the |
| 209 | associated symbol in the enumeration. |
| 210 | |
| 211 | The macro also publicly defines variables whose names are in @var{name-spec} |
| 212 | to an integer. |
| 213 | |
| 214 | A @var{name-spec} is either a single name, and the associated value is 0 for |
| 215 | the first @var{name-spec}, or one more than the previous @var{name-spec}. |
| 216 | It can also be a pair of a name and an integer, in which case the associated |
| 217 | value is that integer. For instance: |
| 218 | |
| 219 | @example |
| 220 | (define-enum get-foo FOO0 FOO1 (FOO10 10) FOO11 FOO12) |
| 221 | (get-foo 9) -> #<unspecified> |
| 222 | (get-foo 0) -> FOO0 |
| 223 | FOO11 -> 11 |
| 224 | @end example |
| 225 | @end deffn |
| 226 | |
| 227 | @node Netlink Connections |
| 228 | @subsection Netlink Connections |
| 229 | |
| 230 | The @code{(netlink connection)} module defines the following procedures, used |
| 231 | to connect and communicate with another process or the kernel using a netlink |
| 232 | socket. |
| 233 | |
| 234 | @deffn {Scheme Procedure} get-addr @var{family} @var{pid} @var{groups} |
| 235 | Return a bytevector that represents a netlink address. @var{family} |
| 236 | should be @code{AF_NETLINK}, @var{pid} is the PID of the process with which |
| 237 | to communicate or 0 for the kernel. @var{groups} is an integer representing |
| 238 | the set of broadcast groups to which the connection subscribes. |
| 239 | @end deffn |
| 240 | |
| 241 | @deffn {Scheme Procedure} connect @var{proto} @var{addr} |
| 242 | Creates a netlink socket for @var{proto} and binds it to @var{addr}. |
| 243 | |
| 244 | @var{proto} is the integer representing the protocol. For instance, rtnetlink |
| 245 | can be selected by usin @code{NETLINK_ROUTE} (defined in |
| 246 | @code{(netlink constant)}). |
| 247 | |
| 248 | @var{addr} is a bytevector, as returned by @code{get-addr}. |
| 249 | @end deffn |
| 250 | |
| 251 | @deffn {Scheme Procedure} connect-route [#:groups @code{0}] |
| 252 | This procedure is a wrapper for @code{connect} that creates a socket for the |
| 253 | rtnetlink protocol, binds it to the kernel and returns it. By passing the |
| 254 | optional @var{groups} keyword, you can select broadcast groups to subscribe to. |
| 255 | @end deffn |
| 256 | |
| 257 | @deffn {Scheme Procedure} close-socket @var{socket} |
| 258 | Closes a netlink socket. The socket cannot be used afterwards. |
| 259 | @end deffn |
| 260 | |
| 261 | @deffn {Scheme Procedure} send-msg @var{msg} @var{sock} [#:@var{addr}] |
| 262 | Send @var{msg} (it must be of type message, @xref{Netlink Headers}) to |
| 263 | @var{addr} using @var{sock}. If not passed, @var{addr} is the address of |
| 264 | the kernel. |
| 265 | @end deffn |
| 266 | |
| 267 | @deffn {Scheme Procedure} receive-msg @var{sock} [#:@var{addr}] |
| 268 | Receives a message from @var{sock} from @var{addr}. This procedure is blocking. |
| 269 | If not passed, @var{addr} defaults to the address of the kernel. This |
| 270 | procedure returns the message as a bytevector, that you can deserialize with |
| 271 | @code{deserialize} (@xref{Data Types}) |
| 272 | @end deffn |
| 273 | |
| 274 | @deffn {Scheme Procedure} receive-and-decode-msg @var{sock} @var{decoder} @ |
| 275 | [#:@var{addr}] |
| 276 | Receives one or more messages from @var{sock} from @var{addr}. this procedure |
| 277 | is blocking. If not passed, @var{addr} defaults to the address of the kernel. |
| 278 | This procedure returns a list of messages that were decoded using @var{decoder}. |
| 279 | |
| 280 | When the answer has the @code{NLM_F_MULTI} flag, this procedure decodes the next |
| 281 | message, until it receives a @code{NLMSG_DONE} message. It returns the list |
| 282 | of every netlink messages it received, including the @code{NLMSG_DONE}. |
| 283 | @end deffn |
| 284 | |
| 285 | @node Netlink API |
| 286 | @section Netlink API |
| 287 | |
| 288 | This section introduces the data structures used for all the netlink protocols. |
| 289 | First, we introduce the structure of a netlink message, then we present the |
| 290 | standard types of netlink messages, that can be used with every protocol. |
| 291 | |
| 292 | @node Netlink Headers |
| 293 | @subsection Netlink Headers |
| 294 | |
| 295 | The @code{(netlink message)} module defines the message structure that contains |
| 296 | a netlink message. It is composed of a header and a body, and is the data |
| 297 | structure to pass to @code{send-msg} (@xref{Netlink Connections}). |
| 298 | |
| 299 | This module defines the following data structure: |
| 300 | |
| 301 | @deffn {Datatype} message |
| 302 | @table @asis |
| 303 | @item @code{type} |
| 304 | The type of data in the body of the message. For instance, @code{RTM_GETLINK}. |
| 305 | |
| 306 | @item @code{flags} |
| 307 | The set of flags that are set in the header. For instance, |
| 308 | @code{(logior NLM_F_REQUEST NLM_F_DUMP)}. |
| 309 | |
| 310 | @item @code{seq} |
| 311 | The sequence number of the message. If this message is an answer to a request, |
| 312 | it must keep the same sequence number. Otherwise, you must generate a new and |
| 313 | unique sequence number, to track the answers. |
| 314 | |
| 315 | @item @code{pid} |
| 316 | The PID of the receiving process, or 0 for the kernel. |
| 317 | |
| 318 | @item @code{data} |
| 319 | The actual body, as an @code{nl-data} structure. |
| 320 | |
| 321 | @end table |
| 322 | @end deffn |
| 323 | |
| 324 | @node Standard Message Types |
| 325 | @subsection Standard Message Types |
| 326 | |
| 327 | The @code{(netlink standard)} module defines the set of standard message types |
| 328 | and their data type. |
| 329 | |
| 330 | @deffn {Datatype} error-message |
| 331 | @table @asis |
| 332 | @item @code{err} |
| 333 | The error code, as a negative number. |
| 334 | |
| 335 | @item @code{hdr} |
| 336 | The message on which this error applies. |
| 337 | |
| 338 | @end table |
| 339 | |
| 340 | @deffn {Scheme Variable} no-data |
| 341 | This variable defines the absence of data. This is useful when a structure |
| 342 | is expecting a body part, but the protocol specifically defines that it should |
| 343 | not take any data in some cases. For instance, a @code{NLMSG_NOOP} message |
| 344 | takes no data, so the @code{data} field of the message will contain this |
| 345 | @code{no-data} value. |
| 346 | @end deffn |
| 347 | |
| 348 | @end deffn |
| 349 | |
| 350 | @node Rtnetlink API |
| 351 | @section Rtnetlink API |
| 352 | @cindex rtnetlink |
| 353 | @cindex ROUTE_NETLINK |
| 354 | |
| 355 | This section describes the support for rtnetlink in guile-netlink. Rtnetlink |
| 356 | is the protocol responsible for everything related to network routing. It |
| 357 | allows you to manage links, addresses, routing tables, neighbor chaces, |
| 358 | routing rules, queueing disciplines, traffic classes, traffic filters and |
| 359 | more. |
| 360 | |
| 361 | @node Routing Attributes |
| 362 | @subsection Routing Attributes |
| 363 | |
| 364 | The @code{(netlink route attrs)} module defines the following data types: |
| 365 | |
| 366 | @deffn {Datatype} route-attr |
| 367 | This defines a header structure for the attribute, as well as its body. |
| 368 | |
| 369 | @table @asis |
| 370 | @item @code{type} |
| 371 | This is the type of the attribute, for instance @code{IFLA_ADDRESS}. |
| 372 | |
| 373 | @item @code{data} |
| 374 | This is the body of the attribute, ie.@: its value. |
| 375 | @end table |
| 376 | @end deffn |
| 377 | |
| 378 | The module also defines additional data types that are not represented as |
| 379 | a record, but by a simple type. For each of the following types, there is |
| 380 | a @code{make-*-route-attr} procedure to produce a @code{nl-data} value |
| 381 | for this type. There is also @code{deserialize-route-attr-data-*} procedure |
| 382 | to deserialize a value of this type. |
| 383 | |
| 384 | @table @asis |
| 385 | @item @code{u8} |
| 386 | A one-byte unsigned integer |
| 387 | @item @code{u16} |
| 388 | A two-bytes unsigned integer |
| 389 | @item @code{u32} |
| 390 | A four-bytes unsigned integer |
| 391 | @item @code{s32} |
| 392 | A four-bytes signed integer |
| 393 | @item @code{string} |
| 394 | A string |
| 395 | @item @code{ethernet} |
| 396 | An ethernet address. Its value is a string that represents that address, |
| 397 | for instnace @code{"01:23:45:67:89:ab"} |
| 398 | @item @code{ipv4} |
| 399 | An IPv4 address. Its value is a string that represents that address, |
| 400 | for instnace @code{"192.0.2.152"} |
| 401 | @item @code{ipv6} |
| 402 | An IPv6 address. Its value is a string that represents that address, |
| 403 | for instnace @code{"2001:db8::0123:4567:89ab:cdef"} |
| 404 | @item @code{bv} |
| 405 | A bytevector. This is used by default when the type is not supported. |
| 406 | @end table |
| 407 | |
| 408 | @node Link Messages |
| 409 | @subsection Link Messages |
| 410 | |
| 411 | The @code{(netlink route link)} package defines the following data type: |
| 412 | |
| 413 | @deffn {Datatype} link-message |
| 414 | This datatype represents a link message with its routing attributes. This type |
| 415 | of message is expected when using the @var{RTM_*LINK} message types. |
| 416 | |
| 417 | @table @asis |
| 418 | @item @code{family} |
| 419 | The network family, defined as @code{AF_UNSPEC} in the rtnetlink documentation, |
| 420 | although it holds different values in practice. |
| 421 | |
| 422 | @item @code{type} |
| 423 | The device type. |
| 424 | |
| 425 | @item @code{index} |
| 426 | The index of the device. This is used to select a specific device by its index, |
| 427 | or 0 to not filter by device index. |
| 428 | |
| 429 | @item @code{flags} |
| 430 | The device flags. See @code{man 7 netdevices} for a list. |
| 431 | |
| 432 | @item @code{attrs} |
| 433 | A list of attributes. This field must contain a list of @code{nl-data} |
| 434 | structures, not a structure by itself. |
| 435 | @end table |
| 436 | @end deffn |
| 437 | |
| 438 | @node Address Messages |
| 439 | @subsection Address Messages |
| 440 | |
| 441 | The @code{(netlink route addr)} package defines the following data type: |
| 442 | |
| 443 | @deffn {Datatype} addr-message |
| 444 | This datatype represents an address message with its routing attributes. This |
| 445 | type of message is expected when using the @var{RTM_*ADDR} message types. |
| 446 | |
| 447 | @table @asis |
| 448 | @item @code{family} |
| 449 | The network family, either @code{AF_INET} for IPv4 addresses, or @code{AF_INET6} |
| 450 | for IPv6 addresses. |
| 451 | |
| 452 | @item @code{prefix-len} |
| 453 | The prefix length, i.e.@: the length of the prefix mask, in bits, if defined |
| 454 | for the address family. |
| 455 | |
| 456 | @item @code{flags} |
| 457 | Address flags. This can be a flag word of @code{IFA_F_SECONDARY} for secondary |
| 458 | address (old alias interface), @code{IFA_F_PERMANENT} for a permanent |
| 459 | address set by the user and other undocumented flags. |
| 460 | |
| 461 | @item @code{scope} |
| 462 | The address scope. |
| 463 | |
| 464 | @item @code{index} |
| 465 | The index of the device this address is for. |
| 466 | |
| 467 | @item @code{attrs} |
| 468 | A list of attributes. This field must contain a list of @code{nl-data} |
| 469 | structures, not a structure by itself. |
| 470 | @end table |
| 471 | @end deffn |
| 472 | |
| 473 | @node IP Library |
| 474 | @chapter IP Library |
| 475 | |
| 476 | This library comes with higher-level procedures that let you access and modify |
| 477 | the state of network on your computer. |
| 478 | |
| 479 | @node Link |
| 480 | @section Link |
| 481 | |
| 482 | The @code{(ip link)} module introduces procedures to access and modify the |
| 483 | network links on your machine. They are equivalent to the @command{ip link} |
| 484 | family of commands, from @code{iproute2}. |
| 485 | |
| 486 | @deffn {Scheme Procedure} link-set @var{device} [#:up @code{#f}] @ |
| 487 | [#:down @code{#f}] [#:type @code{#f}] [#:arp-on @code{#f}] @ |
| 488 | [#:arp-off @code{#f}] [#:dynamic-on @code{#f}] [#:dynamic-off @code{#f}] @ |
| 489 | [#:multicast-on @code{#f}] [#:multicast-off @code{#f}] @ |
| 490 | [#:allmulticast-on @code{#f}] [#:allmulticast-off @code{#f}] @ |
| 491 | [#:promisc-on @code{#f}] [#:promisc-off @code{#f}] [#:trailers-on @code{#f}] @ |
| 492 | [#:trailers-off @code{#f}] [#:carrier-on @code{#f}] [#:carrier-off @code{#f}] @ |
| 493 | [#:txqueuelen @code{#f}] [#:name @code{#f}] [#:address @code{#f}] @ |
| 494 | [#:broadcast @code{#f}] [#:mtu @code{#f}] [#:netns @code{#f}] |
| 495 | Modify an existing link and set its flags and attributes to the ones specified |
| 496 | by the various keywords. When a keyword is omited, the corresponding attribute |
| 497 | is not changed. |
| 498 | |
| 499 | @var{device} can be a device index (as a number) or a device name (as a string). |
| 500 | |
| 501 | Do not set @code{#:up} and @code{#:down} at the same time. Do not set |
| 502 | @code{*-on} and @code{*-off} at the same time. |
| 503 | @end deffn |
| 504 | |
| 505 | @deffn {Scheme Procedure} link-show [#:device @code{#f}] [#:group @code{#f}] @ |
| 506 | [#:up @code{#f}] [#:master @code{#f}] [#:vrf @code{#f}] [#:type @code{#f}] |
| 507 | Print the set of devices on standard output. Setting any of the keyword to a |
| 508 | non-false value will filter the results to only show results that match the |
| 509 | corresponding value. You may set more than one keyword. |
| 510 | @end deffn |
| 511 | |
| 512 | @deffn {Scheme Procedure} link-add @var{name} @var{type} [#:type-args @code{'()}] |
| 513 | Add a new link with given name and type. Additional arguments can be passed to |
| 514 | control the state of the link at creation. @var{type-args} is an association |
| 515 | list containing additional values for the given type. |
| 516 | |
| 517 | When @var{type} is @code{"vlan"}, @var{type-args} can contain a number associated |
| 518 | with @code{'id}: the VLAN id to be created. |
| 519 | |
| 520 | When @var{type} is @code{"veth"}, @var{type-args} can contain a string associated |
| 521 | with @code{'peer}: the name of the peer. |
| 522 | |
| 523 | The following is an example in which we create a new veth (virtual ethernet) |
| 524 | pair and give them a name: |
| 525 | @example |
| 526 | ;; same as "ip l add v0p0 type veth peer v0p1" |
| 527 | (link-add "v0p0" "veth" #:type-args '((peer . "v0p1"))) |
| 528 | @end example |
| 529 | @end deffn |
| 530 | |
| 531 | @deffn {Scheme Procedure} link-del @var{device} |
| 532 | Delete a link. @var{device} can contain the name of the link, as a string, |
| 533 | or its index, as a number. |
| 534 | @end deffn |
| 535 | |
| 536 | @bye |
| 537 |