1 .\" Copyright (c) 1996-1999 Whistle Communications, Inc.
2 .\" All rights reserved.
4 .\" Subject to the following obligations and disclaimer of warranty, use and
5 .\" redistribution of this software, in source or object code forms, with or
6 .\" without modifications are expressly permitted by Whistle Communications;
7 .\" provided, however, that:
8 .\" 1. Any and all reproductions of the source or object code must include the
9 .\" copyright notice above and the following disclaimer of warranties; and
10 .\" 2. No rights are granted, in any manner or form, to use Whistle
11 .\" Communications, Inc. trademarks, including the mark "WHISTLE
12 .\" COMMUNICATIONS" on advertising, endorsements, or otherwise except as
13 .\" such appears in the above copyright notice or in the software.
15 .\" THIS SOFTWARE IS BEING PROVIDED BY WHISTLE COMMUNICATIONS "AS IS", AND
16 .\" TO THE MAXIMUM EXTENT PERMITTED BY LAW, WHISTLE COMMUNICATIONS MAKES NO
17 .\" REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, REGARDING THIS SOFTWARE,
18 .\" INCLUDING WITHOUT LIMITATION, ANY AND ALL IMPLIED WARRANTIES OF
19 .\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
20 .\" WHISTLE COMMUNICATIONS DOES NOT WARRANT, GUARANTEE, OR MAKE ANY
21 .\" REPRESENTATIONS REGARDING THE USE OF, OR THE RESULTS OF THE USE OF THIS
22 .\" SOFTWARE IN TERMS OF ITS CORRECTNESS, ACCURACY, RELIABILITY OR OTHERWISE.
23 .\" IN NO EVENT SHALL WHISTLE COMMUNICATIONS BE LIABLE FOR ANY DAMAGES
24 .\" RESULTING FROM OR ARISING OUT OF ANY USE OF THIS SOFTWARE, INCLUDING
25 .\" WITHOUT LIMITATION, ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
26 .\" PUNITIVE, OR CONSEQUENTIAL DAMAGES, PROCUREMENT OF SUBSTITUTE GOODS OR
27 .\" SERVICES, LOSS OF USE, DATA OR PROFITS, HOWEVER CAUSED AND UNDER ANY
28 .\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
29 .\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
30 .\" THIS SOFTWARE, EVEN IF WHISTLE COMMUNICATIONS IS ADVISED OF THE POSSIBILITY
33 .\" Authors: Julian Elischer <julian@FreeBSD.org>
34 .\" Archie Cobbs <archie@FreeBSD.org>
36 .\" $Whistle: netgraph.4,v 1.7 1999/01/28 23:54:52 julian Exp $
44 .Nd "graph based kernel networking subsystem"
48 system provides a uniform and modular system for the implementation
49 of kernel objects which perform various networking functions.
52 can be arranged into arbitrarily complicated graphs.
55 which are used to connect two nodes together, forming the edges in the graph.
56 Nodes communicate along the edges to process data, implement protocols, etc.
60 is to supplement rather than replace the existing kernel networking
66 A flexible way of combining protocol and link level drivers.
68 A modular way to implement new protocols.
70 A common framework for kernel entities to inter-communicate.
72 A reasonably fast, kernel-based implementation.
75 The most fundamental concept in
79 All nodes implement a number of predefined methods which allow them
80 to interact with other nodes in a well defined manner.
84 which is a static property of the node determined at node creation time.
85 A node's type is described by a unique
88 The type implies what the node does and how it may be connected
91 In object-oriented language, types are classes, and nodes are instances
92 of their respective class.
93 All node types are subclasses of the generic node
94 type, and hence inherit certain common functionality and capabilities
95 (e.g., the ability to have an
99 Nodes may be assigned a globally unique
102 used to refer to the node.
103 The name must not contain the characters
109 characters (including the terminating
113 Each node instance has a unique
115 which is expressed as a 32-bit hexadecimal value.
116 This value may be used to refer to a node when there is no
120 Nodes are connected to other nodes by connecting a pair of
123 Data flows bidirectionally between nodes along
124 connected pairs of hooks.
125 A node may have as many hooks as it
126 needs, and may assign whatever meaning it wants to a hook.
128 Hooks have these properties:
133 name which is unique among all hooks
134 on that node (other hooks on other nodes may have the same name).
135 The name must not contain the characters
142 characters (including the terminating
146 A hook is always connected to another hook.
148 created at the time they are connected, and breaking an edge by
149 removing either hook destroys both hooks.
151 A hook can be set into a state where incoming packets are always queued
152 by the input queueing system, rather than being delivered directly.
153 This can be used when the data is sent from an interrupt handler,
154 and processing must be quick so as not to block other interrupts.
156 A hook may supply overriding receive data and receive message functions,
157 which should be used for data and messages received through that hook
158 in preference to the general node-wide methods.
161 A node may decide to assign special meaning to some hooks.
162 For example, connecting to the hook named
165 the node to start sending debugging information to that hook.
167 Two types of information flow between nodes: data messages and
169 Data messages are passed in
172 in the graph, one edge at a time.
175 in a chain must have the
178 Each node decides how to handle data received through one of its hooks.
180 Along with data, nodes can also receive control messages.
181 There are generic and type-specific control messages.
182 Control messages have a common
183 header format, followed by type-specific data, and are binary structures
185 However, node types may also support conversion of the
186 type-specific data between binary and
189 for debugging and human interface purposes (see the
193 generic control messages below).
194 Nodes are not required to support these conversions.
196 There are three ways to address a control message.
197 If there is a sequence of edges connecting the two nodes, the message
200 by specifying the corresponding sequence
203 hook names as the destination address for the message (relative
205 If the destination is adjacent to the source, then the source
206 node may simply specify (as a pointer in the code) the hook across which the
207 message should be sent.
208 Otherwise, the recipient node's global
211 (or equivalent ID-based name) is used as the destination address
212 for the message (absolute addressing).
216 may be combined, by specifying an absolute start node and a sequence
220 addressing modes are available to control programs outside the kernel;
221 use of direct pointers is limited to kernel modules.
223 Messages often represent commands that are followed by a reply message
224 in the reverse direction.
225 To facilitate this, the recipient of a
226 control message is supplied with a
228 that is suitable for addressing a reply.
230 Each control message contains a 32-bit value, called a
232 indicating the type of the message, i.e.\& how to interpret it.
233 Typically each type defines a unique typecookie for the messages
235 However, a node may choose to recognize and
236 implement more than one type of messages.
238 If a message is delivered to an address that implies that it arrived
239 at that node through a particular hook (as opposed to having been directly
240 addressed using its ID or global name) then that hook is identified to the
242 This allows a message to be re-routed or passed on, should
243 a node decide that this is required, in much the same way that data packets
244 are passed around between nodes.
246 messages for flow control and link management purposes are
247 defined by the base system that are usually
248 passed around in this manner.
249 Flow control message would usually travel
250 in the opposite direction to the data to which they pertain.
251 .Ss Netgraph is (Usually) Functional
252 In order to minimize latency, most
254 operations are functional.
255 That is, data and control messages are delivered by making function
256 calls rather than by using queues and mailboxes.
258 A wishes to send a data
260 to neighboring node B, it calls the
263 data delivery function.
264 This function in turn locates
268 There are exceptions to this.
270 Each node has an input queue, and some operations can be considered to
273 in that they alter the state of the node.
275 world it would be bad if the state of a node were changed while another
276 data packet were transiting the node.
277 For this purpose, the input queue implements a
279 semantic so that when there is a writer in the node, all other requests
280 are queued, and while there are readers, a writer, and any following
282 In the case where there is no reason to queue the
283 data, the input method is called directly, as mentioned above.
285 A node may declare that all requests should be considered as writers,
286 or that requests coming in over a particular hook should be considered to
287 be a writer, or even that packets leaving or entering across a particular
288 hook should always be queued, rather than delivered directly (often useful
289 for interrupt routines who want to get back to the hardware quickly).
290 By default, all control message packets are considered to be writers
291 unless specifically declared to be a reader in their definition.
295 .In netgraph/ng_message.h . )
297 While this mode of operation
298 results in good performance, it has a few implications for node
302 Whenever a node delivers a data or control message, the node
303 may need to allow for the possibility of receiving a returning
304 message before the original delivery function call returns.
307 provides internal synchronization between nodes.
314 is a node that interfaces between
316 and some other part of the system.
319 include device drivers, the
320 .Vt socket , ether , tty ,
326 the calling thread directly executes code in the node, and from that code
329 framework to deliver data across some edge
331 From an execution point of view, the calling thread will execute the
333 framework methods, and if it can acquire a lock to do so,
334 the input methods of the next node.
335 This continues until either the data is discarded or queued for some
336 device or system entity, or the thread is unable to acquire a lock on
338 In that case, the data is queued for the node, and execution rewinds
339 back to the original calling entity.
340 The queued data will be picked up and processed by either the current
341 holder of the lock when they have completed their operations, or by
344 thread that is activated when there are such items
347 It is possible for an infinite loop to occur if the graph contains cycles.
350 So far, these issues have not proven problematical in practice.
351 .Ss Interaction with Other Parts of the Kernel
352 A node may have a hidden interaction with other components of the
353 kernel outside of the
355 subsystem, such as device hardware,
356 kernel protocol stacks, etc.
357 In fact, one of the benefits of
359 is the ability to join disparate kernel networking entities together in a
360 consistent communication framework.
364 node type which is both a
368 in the protocol family
370 Socket nodes allow user processes to participate in
372 Other nodes communicate with socket nodes using the usual methods, and the
373 node hides the fact that it is also passing information to and from a
374 cooperating user process.
376 Another example is a device driver that presents
377 a node interface to the hardware.
379 Nodes are notified of the following actions via function calls
380 to the following node methods,
381 and may accept or reject that action (by returning the appropriate
384 .It Creation of a new node
385 The constructor for the type is called.
386 If creation of a new node is allowed, constructor method may allocate any
387 special resources it needs.
388 For nodes that correspond to hardware, this is typically done during the
389 device attach routine.
392 name corresponding to the
393 device name is assigned here as well.
394 .It Creation of a new hook
395 The hook is created and tentatively
396 linked to the node, and the node is told about the name that will be
397 used to describe this hook.
398 The node sets up any special data structures
399 it needs, or may reject the connection, based on the name of the hook.
400 .It Successful connection of two hooks
401 After both ends have accepted their
402 hooks, and the links have been made, the nodes get a chance to
403 find out who their peer is across the link, and can then decide to reject
405 Tear-down is automatic.
406 This is also the time at which
407 a node may decide whether to set a particular hook (or its peer) into
411 .It Destruction of a hook
412 The node is notified of a broken connection.
413 The node may consider some hooks
414 to be critical to operation and others to be expendable: the disconnection
415 of one hook may be an acceptable event while for another it
416 may effect a total shutdown for the node.
417 .It Preshutdown of a node
418 This method is called before real shutdown, which is discussed below.
419 While in this method, the node is fully operational and can send a
421 message to its peers, or it can exclude itself from the chain and reconnect
422 its peers together, like the
425 .It Shutdown of a node
426 This method allows a node to clean up
427 and to ensure that any actions that need to be performed
428 at this time are taken.
429 The method is called by the generic (i.e., superclass)
430 node destructor which will get rid of the generic components of the node.
431 Some nodes (usually associated with a piece of hardware) may be
433 in that a shutdown breaks all edges and resets the node,
434 but does not remove it.
435 In this case, the shutdown method should not
436 free its resources, but rather, clean up and then call the
438 macro to signal the generic code that the shutdown is aborted.
439 In the case where the shutdown is started by the node itself due to hardware
440 removal or unloading (via
441 .Fn ng_rmnode_self ) ,
444 flag to signal to its own shutdown method that it is not to persist.
446 .Ss Sending and Receiving Data
447 Two other methods are also supported by all nodes:
449 .It Receive data message
452 .Em queueable request item ,
453 usually referred to as an
455 is received by this function.
456 The item contains a pointer to an
459 The node is notified on which hook the item has arrived,
460 and can use this information in its processing decision.
461 The receiving node must always
465 on completion or error, or pass it on to another node
466 (or kernel module) which will then be responsible for freeing it.
469 must be freed if it is not to be passed on to another node, by using the
472 If the item still holds references to
475 freeing then they will also be appropriately freed.
476 Therefore, if there is any chance that the
479 changed or freed separately from the item, it is very important
480 that it be retrieved using the
482 macro that also removes the reference within the item.
483 (Or multiple frees of the same object will occur.)
485 If it is only required to examine the contents of the
487 then it is possible to use the
489 macro to both read and rewrite
491 pointer inside the item.
493 If developer needs to pass any meta information along with the
501 specific meta-data format is obsoleted now.
504 The receiving node may decide to defer the data by queueing it in the
506 NETISR system (see below).
507 It achieves this by setting the
509 flag in the flags word of the hook on which that data will arrive.
510 The infrastructure will respect that bit and queue the data for delivery at
511 a later time, rather than deliver it directly.
512 A node may decide to set
515 node, so that its own output packets are queued.
517 The node may elect to nominate a different receive data function
518 for data received on a particular hook, to simplify coding.
520 .Fn NG_HOOK_SET_RCVDATA hook fn
522 The function receives the same arguments in every way
523 other than it will receive all (and only) packets from that hook.
524 .It Receive control message
525 This method is called when a control message is addressed to the node.
526 As with the received data, an
528 is received, with a pointer to the control message.
529 The message can be examined using the
531 macro, or completely extracted from the item using the
533 which also removes the reference within the item.
534 If the item still holds a reference to the message when it is freed
537 macro), then the message will also be freed appropriately.
539 reference has been removed, the node must free the message itself using the
542 A return address is always supplied, giving the address of the node
543 that originated the message so a reply message can be sent anytime later.
544 The return address is retrieved from the
550 All control messages and replies are
555 however it is more convenient to use the
559 macros to allocate and fill out a message.
560 Messages must be freed using the
564 If the message was delivered via a specific hook, that hook will
565 also be made known, which allows the use of such things as flow-control
566 messages, and status change messages, where the node may want to forward
567 the message out another hook to that on which it arrived.
569 The node may elect to nominate a different receive message function
570 for messages received on a particular hook, to simplify coding.
572 .Fn NG_HOOK_SET_RCVMSG hook fn
574 The function receives the same arguments in every way
575 other than it will receive all (and only) messages from that hook.
578 Much use has been made of reference counts, so that nodes being
579 freed of all references are automatically freed, and this behaviour
580 has been tested and debugged to present a consistent and trustworthy
587 framework provides an unambiguous and simple to use method of specifically
588 addressing any single node in the graph.
589 The naming of a node is
590 independent of its type, in that another node, or external component
591 need not know anything about the node's type in order to address it so as
592 to send it a generic message type.
593 Node and hook names should be
594 chosen so as to make addresses meaningful.
596 Addresses are either absolute or relative.
597 An absolute address begins
598 with a node name or ID, followed by a colon, followed by a sequence of hook
599 names separated by periods.
600 This addresses the node reached by starting
601 at the named node and following the specified sequence of hooks.
602 A relative address includes only the sequence of hook names, implicitly
603 starting hook traversal at the local node.
605 There are a couple of special possibilities for the node name.
610 always refers to the local node.
611 Also, nodes that have no global name may be addressed by their ID numbers,
612 by enclosing the hexadecimal representation of the ID number within
614 Here are some examples of valid
617 .Bd -literal -offset indent
626 The following set of nodes might be created for a site with
627 a single physical frame relay line having two active logical DLCI channels,
628 with RFC 1490 frames on DLCI 16 and PPP frames over DLCI 20:
630 [type SYNC ] [type FRAME] [type RFC1490]
631 [ "Frame1" ](uplink)<-->(data)[<un-named>](dlci16)<-->(mux)[<un-named> ]
632 [ A ] [ B ](dlci20)<---+ [ C ]
639 One could always send a control message to node C from anywhere
641 .Dq Li Frame1:uplink.dlci16 .
642 In this case, node C would also be notified that the message
643 reached it via its hook
646 .Dq Li Frame1:uplink.dlci20
647 could reliably be used to reach node D, and node A could refer
652 Conversely, B can refer to A as
656 could be used by both nodes C and D to address a message to node A.
658 Note that this is only for
659 .Em control messages .
660 In each of these cases, where a relative addressing mode is
661 used, the recipient is notified of the hook on which the
662 message arrived, as well as
663 the originating node.
664 This allows the option of hop-by-hop distribution of messages and
668 routed one hop at a time, by specifying the departing
669 hook, with each node making
670 the next routing decision.
671 So when B receives a frame on hook
673 it decodes the frame relay header to determine the DLCI,
674 and then forwards the unwrapped frame to either C or D.
676 In a similar way, flow control messages may be routed in the reverse
677 direction to outgoing data.
679 .Dq "buffer nearly full"
682 would be passed to node B
683 which might decide to send similar messages to both nodes
686 .Em "direct hook pointer"
687 addressing to route the messages.
688 The message may have travelled from
691 as a synchronous reply, saving time and cycles.
692 .Ss Netgraph Structures
693 Structures are defined in
694 .In netgraph/netgraph.h
695 (for kernel structures only of interest to nodes)
697 .In netgraph/ng_message.h
698 (for message definitions also of interest to user programs).
700 The two basic object types that are of interest to node authors are
704 These two objects have the following
705 properties that are also of interest to the node writers.
707 .It Vt "struct ng_node"
708 Node authors should always use the following
711 their pointers, and should never actually declare the structure.
713 .Fd "typedef struct ng_node *node_p;"
715 The following properties are associated with a node, and can be
716 accessed in the following manner:
719 A driver or interrupt routine may want to check whether
720 the node is still valid.
721 It is assumed that the caller holds a reference
722 on the node so it will not have been freed, however it may have been
723 disabled or otherwise shut down.
725 .Fn NG_NODE_IS_VALID node
726 macro will return this state.
727 Eventually it should be almost impossible
728 for code to run in an invalid node but at this time that work has not been
730 .It Node ID Pq Vt ng_ID_t
731 This property can be retrieved using the macro
732 .Fn NG_NODE_ID node .
734 Optional globally unique name,
738 is a value in here, it is the name of the node.
739 .Bd -literal -offset indent
740 if (NG_NODE_NAME(node)[0] != '\e0') ...
742 if (strcmp(NG_NODE_NAME(node), "fred") == 0) ...
744 .It A node dependent opaque cookie
745 Anything of the pointer type can be placed here.
747 .Fn NG_NODE_SET_PRIVATE node value
749 .Fn NG_NODE_PRIVATE node
750 set and retrieve this property, respectively.
753 .Fn NG_NODE_NUMHOOKS node
755 to retrieve this value.
757 The node may have a number of hooks.
758 A traversal method is provided to allow all the hooks to be
759 tested for some condition.
760 .Fn NG_NODE_FOREACH_HOOK node fn arg rethook
763 is a function that will be called for each hook
766 and returning 0 to terminate the search.
767 If the search is terminated, then
769 will be set to the hook at which the search was terminated.
771 .It Vt "struct ng_hook"
772 Node authors should always use the following
777 .Fd "typedef struct ng_hook *hook_p;"
779 The following properties are associated with a hook, and can be
780 accessed in the following manner:
782 .It A hook dependent opaque cookie
783 Anything of the pointer type can be placed here.
785 .Fn NG_HOOK_SET_PRIVATE hook value
787 .Fn NG_HOOK_PRIVATE hook
788 set and retrieve this property, respectively.
789 .It \&An associate node
791 .Fn NG_HOOK_NODE hook
792 finds the associated node.
793 .It A peer hook Pq Vt hook_p
794 The other hook in this connected pair.
796 .Fn NG_HOOK_PEER hook
797 macro finds the peer.
802 .Fn NG_HOOK_UNREF hook
804 increment and decrement the hook reference count accordingly.
805 After decrement you should always assume the hook has been freed
806 unless you have another reference still valid.
807 .It Override receive functions
809 .Fn NG_HOOK_SET_RCVDATA hook fn
811 .Fn NG_HOOK_SET_RCVMSG hook fn
812 macros can be used to set override methods that will be used in preference
813 to the generic receive data and receive message functions.
814 To unset these, use the macros to set them to
816 They will only be used for data and
817 messages received on the hook on which they are set.
820 The maintenance of the names, reference counts, and linked list
821 of hooks for each node is handled automatically by the
824 Typically a node's private info contains a back-pointer to the node or hook
825 structure, which counts as a new reference that must be included
826 in the reference count for the node.
827 When the node constructor is called,
828 there is already a reference for this calculated in, so that
829 when the node is destroyed, it should remember to do a
833 From a hook you can obtain the corresponding node, and from
834 a node, it is possible to traverse all the active hooks.
836 A current example of how to define a node can always be seen in
837 .Pa src/sys/netgraph/ng_sample.c
838 and should be used as a starting point for new node writers.
840 .Ss Netgraph Message Structure
841 Control messages have the following structure:
843 #define NG_CMDSTRSIZ 32 /* Max command string (including null) */
847 u_char version; /* Must equal NG_VERSION */
848 u_char spare; /* Pad to 4 bytes */
850 uint32_t arglen; /* Length of cmd/resp data */
851 uint32_t cmd; /* Command identifier */
852 uint32_t flags; /* Message status flags */
853 uint32_t token; /* Reply should have the same token */
854 uint32_t typecookie; /* Node type understanding this message */
855 u_char cmdstr[NG_CMDSTRSIZ]; /* cmd string + \0 */
857 char data[]; /* placeholder for actual data */
860 #define NG_ABI_VERSION 12 /* Netgraph kernel ABI version */
861 #define NG_VERSION 8 /* Netgraph message version */
862 #define NGF_ORIG 0x00000000 /* The msg is the original request */
863 #define NGF_RESP 0x00000001 /* The message is a response */
866 Control messages have the fixed header shown above, followed by a
867 variable length data section which depends on the type cookie
869 Each field is explained below:
870 .Bl -tag -width indent
872 Indicates the version of the
874 message protocol itself.
875 The current version is
878 This is the length of any extra arguments, which begin at
881 Indicates whether this is a command or a response control message.
885 is a means by which a sender can match a reply message to the
886 corresponding command message; the reply always has the same token.
888 The corresponding node type's unique 32-bit value.
889 If a node does not recognize the type cookie it must reject the message
893 Each type should have an include file that defines the commands,
894 argument format, and cookie for its own messages.
896 ensures that the same header file was included by both sender and
897 receiver; when an incompatible change in the header file is made,
901 The de-facto method for generating unique type cookies is to take the
902 seconds from the Epoch at the time the header file is written
904 .Dq Nm date Fl u Li +%s ) .
906 There is a predefined typecookie
907 .Dv NGM_GENERIC_COOKIE
911 a corresponding set of generic messages which all nodes understand.
912 The handling of these messages is automatic.
914 The identifier for the message command.
915 This is type specific,
916 and is defined in the same header file as the typecookie.
918 Room for a short human readable version of
920 (for debugging purposes only).
923 Some modules may choose to implement messages from more than one
924 of the header files and thus recognize more than one type cookie.
925 .Ss Control Message ASCII Form
926 Control messages are in binary format for efficiency.
928 debugging and human interface purposes, and if the node type supports
929 it, control messages may be converted to and from an equivalent
934 form is similar to the binary form, with two exceptions:
939 header field must contain the
941 name of the command, corresponding to the
945 The arguments field contains a
949 string version of the message arguments.
952 In general, the arguments field of a control message can be any
953 arbitrary C data type.
955 includes parsing routines to support
956 some pre-defined datatypes in
958 with this simple syntax:
961 Integer types are represented by base 8, 10, or 16 numbers.
963 Strings are enclosed in double quotes and respect the normal
964 C language backslash escapes.
966 IP addresses have the obvious form.
968 Arrays are enclosed in square brackets, with the elements listed
969 consecutively starting at index zero.
970 An element may have an optional index and equals sign
974 does not have an explicit index, the index is implicitly the previous
975 element's index plus one.
977 Structures are enclosed in curly braces, and each field is specified
979 .Ar fieldname Ns = Ns Ar value .
981 Any array element or structure field whose value is equal to its
984 For integer types, the default value
985 is usually zero; for string types, the empty string.
987 Array elements and structure fields may be specified in any order.
990 Each node type may define its own arbitrary types by providing
991 the necessary routines to parse and unparse.
994 for a specific node type are documented in the corresponding man page.
995 .Ss Generic Control Messages
996 There are a number of standard predefined messages that will work
997 for any node, as they are supported directly by the framework itself.
999 .In netgraph/ng_message.h
1000 along with the basic layout of messages and other similar information.
1001 .Bl -tag -width indent
1003 Connect to another node, using the supplied hook names on either end.
1005 Construct a node of the given type and then connect to it using the
1006 supplied hook names.
1008 The target node should disconnect from all its neighbours and shut down.
1009 Persistent nodes such as those representing physical hardware
1010 might not disappear from the node namespace, but only reset themselves.
1011 The node must disconnect all of its hooks.
1012 This may result in neighbors shutting themselves down, and possibly a
1013 cascading shutdown of the entire connected graph.
1015 Assign a name to a node.
1016 Nodes can exist without having a name, and this
1017 is the default for nodes created using the
1020 Such nodes can only be addressed relatively or by their ID number.
1022 Ask the node to break a hook connection to one of its neighbours.
1023 Both nodes will have their
1026 Either node may elect to totally shut down as a result.
1028 Asks the target node to describe itself.
1029 The four returned fields
1030 are the node name (if named), the node type, the node ID and the
1031 number of hooks attached.
1032 The ID is an internal number unique to that node.
1033 .It Dv NGM_LISTHOOKS
1034 This returns the information given by
1037 includes an array of fields describing each link, and the description for
1038 the node at the far end of that link.
1039 .It Dv NGM_LISTNAMES
1040 This returns an array of node descriptions (as for
1042 where each entry of the array describes a named node.
1043 All named nodes will be described.
1044 .It Dv NGM_LISTNODES
1047 except that all nodes are listed regardless of whether they have a name or not.
1048 .It Dv NGM_LISTTYPES
1049 This returns a list of all currently installed
1052 .It Dv NGM_TEXT_STATUS
1053 The node may return a text formatted status message.
1054 The status information is determined entirely by the node type.
1058 that requires any support within the node itself and as such the node may
1059 elect to not support this message.
1060 The text response must be less than
1062 bytes in length (presently 1024).
1063 This can be used to return general
1064 status information in human readable form.
1065 .It Dv NGM_BINARY2ASCII
1066 This message converts a binary control message to its
1069 The entire control message to be converted is contained within the
1070 arguments field of the
1071 .Dv NGM_BINARY2ASCII
1073 If successful, the reply will contain the same control
1077 A node will typically only know how to translate messages that it
1078 itself understands, so the target node of the
1079 .Dv NGM_BINARY2ASCII
1080 is often the same node that would actually receive that message.
1081 .It Dv NGM_ASCII2BINARY
1083 .Dv NGM_BINARY2ASCII .
1084 The entire control message to be converted, in
1087 in the arguments section of the
1088 .Dv NGM_ASCII2BINARY
1089 and need only have the
1090 .Va flags , cmdstr ,
1093 header fields filled in, plus the
1095 -terminated string version of
1096 the arguments in the arguments field.
1097 If successful, the reply
1098 contains the binary version of the control message.
1100 .Ss Flow Control Messages
1101 In addition to the control messages that affect nodes with respect to the
1102 graph, there are also a number of
1105 At present these are
1107 handled automatically by the system, so
1108 nodes need to handle them if they are going to be used in a graph utilising
1109 flow control, and will be in the likely path of these messages.
1110 The default action of a node that does not understand these messages should
1111 be to pass them onto the next node.
1112 Hopefully some helper functions will assist in this eventually.
1113 These messages are also defined in
1114 .In netgraph/ng_message.h
1115 and have a separate cookie
1117 to help identify them.
1118 They will not be covered in depth here.
1122 code may either be statically compiled
1123 into the kernel or else loaded dynamically as a KLD via
1125 In the former case, include
1127 .D1 Cd "options NETGRAPH"
1129 in your kernel configuration file.
1130 You may also include selected
1131 node types in the kernel compilation, for example:
1133 .D1 Cd "options NETGRAPH"
1134 .D1 Cd "options NETGRAPH_SOCKET"
1135 .D1 Cd "options NETGRAPH_ECHO"
1139 subsystem is loaded, individual node types may be loaded at any time
1144 knows how to automatically do this; when a request to create a new
1145 node of unknown type
1149 will attempt to load the KLD module
1150 .Pa ng_ Ns Ao Ar type Ac Ns Pa .ko .
1152 Types can also be installed at boot time, as certain device drivers
1153 may want to export each instance of the device as a
1157 In general, new types can be installed at any time from within the
1160 supplying a pointer to the type's
1161 .Vt "struct ng_type"
1166 macro automates this process by using a linker set.
1167 .Sh EXISTING NODE TYPES
1168 Several node types currently exist.
1169 Each is fully documented in its own man page:
1170 .Bl -tag -width indent
1172 The socket type implements two new sockets in the new protocol domain
1174 The new sockets protocols are
1180 Typically one of each is associated with a socket node.
1181 When both sockets have closed, the node will shut down.
1184 socket is used for sending and receiving data, while the
1186 socket is used for sending and receiving control messages.
1187 Data and control messages are passed using the
1191 system calls, using a
1192 .Vt "struct sockaddr_ng"
1195 Responds only to generic messages and is a
1199 Always accepts new hooks.
1201 Responds only to generic messages and always echoes data back through the
1202 hook from which it arrived.
1203 Returns any non-generic messages as their own response.
1205 Always accepts new hooks.
1207 This node is useful for
1210 .Va left , right , left2right ,
1213 Data entering from the
1219 and data entering from the
1234 Encapsulates/de-encapsulates frames encoded according to RFC 1490.
1235 Has a hook for the encapsulated packets
1238 for each protocol (i.e., IP, PPP, etc.).
1240 Encapsulates/de-encapsulates Frame Relay frames.
1241 Has a hook for the encapsulated packets
1246 Automatically handles frame relay
1248 (link management interface) operations and packets.
1249 Automatically probes and detects which of several LMI standards
1250 is in use at the exchange.
1252 This node is also a line discipline.
1253 It simply converts between
1255 frames and sequential serial data, allowing a TTY to appear as a
1258 It has a programmable
1262 This node encapsulates and de-encapsulates asynchronous frames
1263 according to RFC 1662.
1264 This is used in conjunction with the TTY node
1265 type for supporting PPP links over asynchronous serial lines.
1267 This node is attached to every Ethernet interface in the system.
1268 It allows capturing raw Ethernet frames from the network, as well as
1269 sending frames out of the interface.
1271 This node is also a system networking interface.
1272 It has hooks representing each protocol family (IP, IPv6)
1273 and appears in the output of
1275 The interfaces are named
1280 This node implements a simple round-robin multiplexer.
1282 for example to make several LAN ports act together to get a higher speed
1283 link between two machines.
1284 .It Various PPP related nodes
1285 There is a full multilink PPP implementation that runs in
1289 port can use these modules to make a very low latency high
1290 capacity PPP system.
1293 VPNs using the PPTP node.
1295 A server and client side implementation of PPPoE.
1296 Used in conjunction with
1303 This node, together with the Ethernet nodes, allows a very flexible
1304 bridging system to be implemented.
1306 This intriguing node looks like a socket to the system but diverts
1307 all data to and from the
1309 system for further processing.
1311 such things as UDP tunnels to be almost trivially implemented from the
1315 Refer to the section at the end of this man page for more nodes types.
1317 Whether a named node exists can be checked by trying to send a control message
1319 .Dv NGM_NODEINFO ) .
1320 If it does not exist,
1324 All data messages are
1330 Nodes are responsible for freeing what they allocate.
1331 There are three exceptions:
1335 sent across a data link are never to be freed by the sender.
1337 case of error, they should be considered freed.
1339 Messages sent using one of
1341 family macros are freed by the recipient.
1342 As in the case above, the addresses
1343 associated with the message are freed by whatever allocated them so the
1344 recipient should copy them if it wants to keep that information.
1346 Both control messages and data are delivered and queued with a
1349 The item must be freed using
1350 .Fn NG_FREE_ITEM item
1351 or passed on to another node.
1354 .Bl -tag -width indent
1355 .It In netgraph/netgraph.h
1356 Definitions for use solely within the kernel by
1359 .It In netgraph/ng_message.h
1360 Definitions needed by any file that needs to deal with
1363 .It In netgraph/ng_socket.h
1364 Definitions needed to use
1368 .It In netgraph/ng_ Ns Ao Ar type Ac Ns Pa .h
1369 Definitions needed to use
1372 nodes, including the type cookie definition.
1373 .It Pa /boot/kernel/netgraph.ko
1376 subsystem loadable KLD module.
1377 .It Pa /boot/kernel/ng_ Ns Ao Ar type Ac Ns Pa .ko
1378 Loadable KLD module for node type
1380 .It Pa src/sys/netgraph/ng_sample.c
1384 Use this as a starting point for new node types.
1386 .Sh USER MODE SUPPORT
1387 There is a library for supporting user-mode programs that wish
1388 to interact with the
1395 Two user-mode support programs,
1399 are available to assist manual configuration and debugging.
1401 There are a few useful techniques for debugging new node types.
1402 First, implementing new node types in user-mode first
1403 makes debugging easier.
1406 node type is also useful for debugging, especially in conjunction with
1412 .Pa /usr/share/examples/netgraph
1413 for solutions to several
1414 common networking problems, solved using
1422 .Xr ng_bluetooth 4 ,
1433 .Xr ng_frame_relay 4 ,
1435 .Xr ng_gif_demux 4 ,
1473 system was designed and first implemented at Whistle Communications, Inc.\&
1476 customized for the Whistle InterJet.
1477 It first made its debut in the main tree in
1481 .An Julian Elischer Aq Mt julian@FreeBSD.org ,
1482 with contributions by
1483 .An Archie Cobbs Aq Mt archie@FreeBSD.org .