1.\" Copyright (c) 1996-1999 Whistle Communications, Inc.
2.\" All rights reserved.
3.\"
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.
14.\"
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
31.\" OF SUCH DAMAGE.
32.\"
33.\" Authors: Julian Elischer <julian@FreeBSD.org>
34.\" Archie Cobbs <archie@FreeBSD.org>
35.\"
36.\" $FreeBSD: head/share/man/man4/netgraph.4 69027 2000-11-22 09:35:58Z ru $
37.\" $Whistle: netgraph.4,v 1.7 1999/01/28 23:54:52 julian Exp $
38.\"
39.Dd January 19, 1999
40.Dt NETGRAPH 4
41.Os FreeBSD
42.Sh NAME
43.Nm netgraph
44.Nd graph based kernel networking subsystem
45.Sh DESCRIPTION
46The
47.Nm
48system provides a uniform and modular system for the implementation
49of kernel objects which perform various networking functions. The objects,
50known as
51.Em nodes ,
52can be arranged into arbitrarily complicated graphs. Nodes have
53.Em hooks
54which are used to connect two nodes together, forming the edges in the graph.
55Nodes communicate along the edges to process data, implement protocols, etc.
56.Pp
57The aim of
58.Nm
59is to supplement rather than replace the existing kernel networking
60infrastructure. It provides:
61.Pp
62.Bl -bullet -compact -offset 2n
63.It
64A flexible way of combining protocol and link level drivers
65.It
66A modular way to implement new protocols
67.It
68A common framework for kernel entities to inter-communicate
69.It
70A reasonably fast, kernel-based implementation
71.El
72.Sh Nodes and Types
73The most fundamental concept in
74.Nm
75is that of a
76.Em node .
77All nodes implement a number of predefined methods which allow them
78to interact with other nodes in a well defined manner.
79.Pp
80Each node has a
81.Em type ,
82which is a static property of the node determined at node creation time.
83A node's type is described by a unique
84.Tn ASCII
85type name.
86The type implies what the node does and how it may be connected
87to other nodes.
88.Pp
89In object-oriented language, types are classes and nodes are instances
90of their respective class. All node types are subclasses of the generic node
91type, and hence inherit certain common functionality and capabilities
92(e.g., the ability to have an
93.Tn ASCII
94name).
95.Pp
96Nodes may be assigned a globally unique
97.Tn ASCII
98name which can be
99used to refer to the node.
100The name must not contain the characters
101.Dq \&.
102or
103.Dq \&:
104and is limited to
105.Dv "NG_NODELEN + 1"
106characters (including NUL byte).
107.Pp
108Each node instance has a unique
109.Em ID number
110which is expressed as a 32-bit hex value. This value may be used to
111refer to a node when there is no
112.Tn ASCII
113name assigned to it.
114.Sh Hooks
115Nodes are connected to other nodes by connecting a pair of
116.Em hooks ,
117one from each node. Data flows bidirectionally between nodes along
118connected pairs of hooks. A node may have as many hooks as it
119needs, and may assign whatever meaning it wants to a hook.
120.Pp
121Hooks have these properties:
122.Pp
123.Bl -bullet -compact -offset 2n
124.It
125A hook has an
126.Tn ASCII
127name which is unique among all hooks
128on that node (other hooks on other nodes may have the same name).
129The name must not contain a
130.Dq \&.
131or a
132.Dq \&:
133and is
134limited to
135.Dv "NG_HOOKLEN + 1"
136characters (including NUL byte).
137.It
138A hook is always connected to another hook. That is, hooks are
139created at the time they are connected, and breaking an edge by
140removing either hook destroys both hooks.
141.El
142.Pp
143A node may decide to assign special meaning to some hooks.
144For example, connecting to the hook named
145.Dq debug
146might trigger
147the node to start sending debugging information to that hook.
148.Sh Data Flow
149Two types of information flow between nodes: data messages and
150control messages. Data messages are passed in mbuf chains along the edges
151in the graph, one edge at a time. The first mbuf in a chain must have the
152.Dv M_PKTHDR
153flag set. Each node decides how to handle data coming in on its hooks.
154.Pp
155Control messages are type-specific C structures sent from one node
156directly to some arbitrary other node. Control messages have a common
157header format, followed by type-specific data, and are binary structures
158for efficiency. However, node types also may support conversion of the
159type specific data between binary and
160.Tn ASCII
161for debugging and human interface purposes (see the
162.Dv NGM_ASCII2BINARY
163and
164.Dv NGM_BINARY2ASCII
165generic control messages below). Nodes are not required to support
166these conversions.
167.Pp
168There are two ways to address a control message. If
169there is a sequence of edges connecting the two nodes, the message
170may be
171.Dq source routed
172by specifying the corresponding sequence
173of hooks as the destination address for the message (relative
174addressing). Otherwise, the recipient node global
175.Tn ASCII
176name
177(or equivalent ID based name) is used as the destination address
178for the message (absolute addressing). The two types of addressing
179may be combined, by specifying an absolute start node and a sequence
180of hooks.
181.Pp
182Messages often represent commands that are followed by a reply message
183in the reverse direction. To facilitate this, the recipient of a
184control message is supplied with a
185.Dq return address
186that is suitable
187for addressing a reply.
188.Pp
189Each control message contains a 32 bit value called a
190.Em typecookie
191indicating the type of the message, i.e., how to interpret it.
192Typically each type defines a unique typecookie for the messages
193that it understands. However, a node may choose to recognize and
194implement more than one type of message.
195.Pp
196If message is delivered to an address that implies that it arrived
197at that node through a particular hook, that hook is identified to the
198receiving node. This allows a message to be rerouted or passed on, should
199a node decide that this is required.
200.Sh Netgraph is Functional
201In order to minimize latency, most
202.Nm
203operations are functional.
204That is, data and control messages are delivered by making function
205calls rather than by using queues and mailboxes. For example, if node
206A wishes to send a data mbuf to neighboring node B, it calls the
207generic
208.Nm
209data delivery function. This function in turn locates
210node B and calls B's
211.Dq receive data
212method.
213.Pp
214It is allowable for nodes to reject a data packet, or to pass it back to the
215caller in a modified or completely replaced form. The caller can notify the
216node being called that it does not wish to receive any such packets
217by using the
218.Fn NG_SEND_DATA
219macro, in which case, the second node should just discard rejected packets.
220If the sender knows how to handle returned packets, it must use the
221.Fn NG_SEND_DATA_RET
222macro, which will adjust the parameters to point to the returned data
223or NULL if no data was returned to the caller. No packet return is possible
224across a queuing link (though an explicitly sent return is of course possible,
225it doesn't mean quite the same thing).
226.Pp
227While this mode of operation
228results in good performance, it has a few implications for node
229developers:
230.Pp
231.Bl -bullet -compact -offset 2n
232.It
233Whenever a node delivers a data or control message, the node
234may need to allow for the possibility of receiving a returning
235message before the original delivery function call returns.
236.It
237Netgraph nodes and support routines generally run at
238.Fn splnet .
239However, some nodes may want to send data and control messages
240from a different priority level. Netgraph supplies queueing routines which
241utilize the NETISR system to move message delivery to
242.Fn splnet .
243Nodes that run at other priorities (e.g. interfaces) can be directly
244linked to other nodes so that the combination runs at the other priority,
245however any interaction with nodes running at splnet MUST be achievd via the
246queueing functions, (which use the
247.Fn netisr
248feature of the kernel).
249Note that messages are always received at
250.Fn splnet .
251.It
252It's possible for an infinite loop to occur if the graph contains cycles.
253.El
254.Pp
255So far, these issues have not proven problematical in practice.
256.Sh Interaction With Other Parts of the Kernel
257A node may have a hidden interaction with other components of the
258kernel outside of the
259.Nm
260subsystem, such as device hardware,
261kernel protocol stacks, etc. In fact, one of the benefits of
262.Nm
263is the ability to join disparate kernel networking entities together in a
264consistent communication framework.
265.Pp
266An example is the node type
267.Em socket
268which is both a netgraph node and a
269.Xr socket 2
270BSD socket in the protocol family
271.Dv PF_NETGRAPH .
272Socket nodes allow user processes to participate in
273.Nm .
274Other nodes communicate with socket nodes using the usual methods, and the
275node hides the fact that it is also passing information to and from a
276cooperating user process.
277.Pp
278Another example is a device driver that presents
279a node interface to the hardware.
280.Sh Node Methods
281Nodes are notified of the following actions via function calls
282to the following node methods (all at
283.Fn splnet )
284and may accept or reject that action (by returning the appropriate
285error code):
286.Bl -tag -width xxx
287.It Creation of a new node
288The constructor for the type is called. If creation of a new node is
289allowed, the constructor must call the generic node creation
290function (in object-oriented terms, the superclass constructor)
291and then allocate any special resources it needs. For nodes that
292correspond to hardware, this is typically done during the device
293attach routine. Often a global
294.Tn ASCII
295name corresponding to the
296device name is assigned here as well.
297.It Creation of a new hook
298The hook is created and tentatively
299linked to the node, and the node is told about the name that will be
300used to describe this hook. The node sets up any special data structures
301it needs, or may reject the connection, based on the name of the hook.
302.It Successful connection of two hooks
303After both ends have accepted their
304hooks, and the links have been made, the nodes get a chance to
305find out who their peer is across the link and can then decide to reject
306the connection. Tear-down is automatic.
307.It Destruction of a hook
308The node is notified of a broken connection. The node may consider some hooks
309to be critical to operation and others to be expendable: the disconnection
310of one hook may be an acceptable event while for another it
311may effect a total shutdown for the node.
312.It Shutdown of a node
313This method allows a node to clean up
314and to ensure that any actions that need to be performed
315at this time are taken. The method must call the generic (i.e., superclass)
316node destructor to get rid of the generic components of the node.
317Some nodes (usually associated with a piece of hardware) may be
318.Em persistent
319in that a shutdown breaks all edges and resets the node,
320but doesn't remove it, in which case the generic destructor is not called.
321.El
322.Sh Sending and Receiving Data
323Three other methods are also supported by all nodes:
324.Bl -tag -width xxx
325.It Receive data message
326An mbuf chain is passed to the node.
327The node is notified on which hook the data arrived,
328and can use this information in its processing decision.
329The receiving node must always
330.Fn m_freem
331the mbuf chain on completion or error, pass it back (reject it), or pass
332it on to another node
333(or kernel module) which will then be responsible for freeing it.
334If a node passes a packet back to the caller, it does not have to be the
335same mbuf, in which case the original must be freed. Passing a packet
336back allows a module to modify the original data (e.g. encrypt it),
337or in some other way filter it (e.g. packet filtering).
338.Pp
339In addition to the mbuf chain itself there is also a pointer to a
340structure describing meta-data about the message
341(e.g. priority information). This pointer may be
342.Dv NULL
343if there is no additional information. The format for this information is
344described in
345.Pa netgraph.h .
346The memory for meta-data must allocated via
347.Fn malloc
348with type
349.Dv M_NETGRAPH .
350As with the data itself, it is the receiver's responsibility to
351.Fn free
352the meta-data. If the mbuf chain is freed the meta-data must
353be freed at the same time. If the meta-data is freed but the
354real data on is passed on, then a
355.Dv NULL
356pointer must be substituted.
357Meta-data may be passed back in the same way that mbuf data may be passed back.
358As with mbuf data, the rejected or returned meta-data pointer may point to
359the same or different meta-data as that passed in,
360and if it is different, the original must be freed.
361.Pp
362The receiving node may decide to defer the data by queueing it in the
363.Nm
364NETISR system (see below).
365.Pp
366The structure and use of meta-data is still experimental, but is presently used in
367frame-relay to indicate that management packets should be queued for transmission
368at a higher priority than data packets. This is required for
369conformance with Frame Relay standards.
370.Pp
371.It Receive queued data message
372Usually this will be the same function as
373.Em Receive data message.
374This is the entry point called when a data message is being handed to
375the node after having been queued in the NETISR system.
376This allows a node to decide in the
377.Em Receive data message
378method that a message should be deferred and queued,
379and be sure that when it is processed from the queue,
380it will not be queued again.
381.It Receive control message
382This method is called when a control message is addressed to the node.
383A return address is always supplied, giving the address of the node
384that originated the message so a reply message can be sent anytime later.
385.Pp
386It is possible for a synchronous reply to be made, and in fact this
387is more common in practice.
388This is done by setting a pointer (supplied as an extra function parameter)
389to point to the reply.
390Then when the control message delivery function returns,
391the caller can check if this pointer has been made non-NULL,
392and if so then it points to the reply message allocated via
393.Fn malloc
394and containing the synchronous response. In both directions,
395(request and response) it is up to the
396receiver of that message to
397.Fn free
398the control message buffer. All control messages and replies are
399allocated with
400.Fn malloc
401type
402.Dv M_NETGRAPH .
403.Pp
404If the message was delivered via a specific hook, that hook will
405also be made known, which allows the use of such things as flow-control
406messages, and status change messages, where the node may want to forward
407the message out another hook to that on which it arrived.
408.El
409.Pp
410Much use has been made of reference counts, so that nodes being
411free'd of all references are automatically freed, and this behaviour
412has been tested and debugged to present a consistent and trustworthy
413framework for the
414.Dq type module
415writer to use.
416.Sh Addressing
417The
418.Nm
419framework provides an unambiguous and simple to use method of specifically
420addressing any single node in the graph. The naming of a node is
421independent of its type, in that another node, or external component
422need not know anything about the node's type in order to address it so as
423to send it a generic message type. Node and hook names should be
424chosen so as to make addresses meaningful.
425.Pp
426Addresses are either absolute or relative. An absolute address begins
427with a node name, (or ID), followed by a colon, followed by a sequence of hook
428names separated by periods. This addresses the node reached by starting
429at the named node and following the specified sequence of hooks.
430A relative address includes only the sequence of hook names, implicitly
431starting hook traversal at the local node.
432.Pp
433There are a couple of special possibilities for the node name.
434The name
435.Dq \&.
436(referred to as
437.Dq \&.: )
438always refers to the local node.
439Also, nodes that have no global name may be addressed by their ID numbers,
440by enclosing the hex representation of the ID number within square brackets.
441Here are some examples of valid netgraph addresses:
442.Bd -literal -offset 4n -compact
443
444 .:
445 foo:
446 .:hook1
447 foo:hook1.hook2
448 [f057cd80]:hook1
449.Ed
450.Pp
451Consider the following set of nodes might be created for a site with
452a single physical frame relay line having two active logical DLCI channels,
453with RFC-1490 frames on DLCI 16 and PPP frames over DLCI 20:
454.Pp
455.Bd -literal
456[type SYNC ] [type FRAME] [type RFC1490]
457[ "Frame1" ](uplink)<-->(data)[<un-named>](dlci16)<-->(mux)[<un-named> ]
458[ A ] [ B ](dlci20)<---+ [ C ]
459 |
460 | [ type PPP ]
461 +>(mux)[<un-named>]
462 [ D ]
463.Ed
464.Pp
465One could always send a control message to node C from anywhere
466by using the name
467.Em "Frame1:uplink.dlci16" .
468In this case, node C would also be notified that the message
469reached it via its hook
470.Dq mux .
471Similarly,
472.Em "Frame1:uplink.dlci20"
473could reliably be used to reach node D, and node A could refer
474to node B as
475.Em ".:uplink" ,
476or simply
477.Em "uplink" .
478Conversely, B can refer to A as
479.Em "data" .
480The address
481.Em "mux.data"
482could be used by both nodes C and D to address a message to node A.
483.Pp
484Note that this is only for
485.Em control messages .
486In each of these cases, where a relative addressing mode is
487used, the recipient is notified of the hook on which the
488message arrived, as well as
489the originating node.
490This allows the option of hop-by-hop distibution of messages and
491state information.
492Data messages are
493.Em only
494routed one hop at a time, by specifying the departing
495hook, with each node making
496the next routing decision. So when B receives a frame on hook
497.Dq data
498it decodes the frame relay header to determine the DLCI,
499and then forwards the unwrapped frame to either C or D.
500.Pp
501A similar graph might be used to represent multi-link PPP running
502over an ISDN line:
503.Pp
504.Bd -literal
505[ type BRI ](B1)<--->(link1)[ type MPP ]
506[ "ISDN1" ](B2)<--->(link2)[ (no name) ]
507[ ](D) <-+
508 |
509 +----------------+
510 |
511 +->(switch)[ type Q.921 ](term1)<---->(datalink)[ type Q.931 ]
512 [ (no name) ] [ (no name) ]
513.Ed
514.Sh Netgraph Structures
515Interesting members of the node and hook structures are shown below:
516.Bd -literal
517struct ng_node {
518 char *name; /* Optional globally unique name */
519 void *private; /* Node implementation private info */
520 struct ng_type *type; /* The type of this node */
521 int refs; /* Number of references to this struct */
522 int numhooks; /* Number of connected hooks */
523 hook_p hooks; /* Linked list of (connected) hooks */
524};
525typedef struct ng_node *node_p;
526
527struct ng_hook {
528 char *name; /* This node's name for this hook */
529 void *private; /* Node implementation private info */
530 int refs; /* Number of references to this struct */
531 struct ng_node *node; /* The node this hook is attached to */
532 struct ng_hook *peer; /* The other hook in this connected pair */
533 struct ng_hook *next; /* Next in list of hooks for this node */
534};
535typedef struct ng_hook *hook_p;
536.Ed
537.Pp
538The maintenance of the name pointers, reference counts, and linked list
539of hooks for each node is handled automatically by the
540.Nm
541subsystem.
542Typically a node's private info contains a back-pointer to the node or hook
543structure, which counts as a new reference that must be registered by
544incrementing
545.Dv "node->refs" .
546.Pp
547From a hook you can obtain the corresponding node, and from
548a node the list of all active hooks.
549.Pp
550Node types are described by these structures:
551.Bd -literal
552/** How to convert a control message from binary <-> ASCII */
553struct ng_cmdlist {
554 u_int32_t cookie; /* typecookie */
555 int cmd; /* command number */
556 const char *name; /* command name */
557 const struct ng_parse_type *mesgType; /* args if !NGF_RESP */
558 const struct ng_parse_type *respType; /* args if NGF_RESP */
559};
560
561struct ng_type {
562 u_int32_t version; /* Must equal NG_VERSION */
563 const char *name; /* Unique type name */
564
565 /* Module event handler */
566 modeventhand_t mod_event; /* Handle load/unload (optional) */
567
568 /* Constructor */
569 int (*constructor)(node_p *node); /* Create a new node */
570
571 /** Methods using the node **/
572 int (*rcvmsg)(node_p node, /* Receive control message */
573 struct ng_mesg *msg, /* The message */
574 const char *retaddr, /* Return address */
575 struct ng_mesg **resp /* Synchronous response */
576 hook_p lasthook); /* last hook traversed */
577 int (*shutdown)(node_p node); /* Shutdown this node */
578 int (*newhook)(node_p node, /* create a new hook */
579 hook_p hook, /* Pre-allocated struct */
580 const char *name); /* Name for new hook */
581
582 /** Methods using the hook **/
583 int (*connect)(hook_p hook); /* Confirm new hook attachment */
584 int (*rcvdata)(hook_p hook, /* Receive data on a hook */
585 struct mbuf *m, /* The data in an mbuf */
586 meta_p meta, /* Meta-data, if any */
587 struct mbuf **ret_m, /* return data here */
588 meta_p *ret_meta); /* return Meta-data here */
589 int (*disconnect)(hook_p hook); /* Notify disconnection of hook */
590
591 /** How to convert control messages binary <-> ASCII */
592 const struct ng_cmdlist *cmdlist; /* Optional; may be NULL */
593};
594.Ed
595.Pp
596Control messages have the following structure:
597.Bd -literal
598#define NG_CMDSTRLEN 15 /* Max command string (16 with null) */
599
600struct ng_mesg {
601 struct ng_msghdr {
602 u_char version; /* Must equal NG_VERSION */
603 u_char spare; /* Pad to 2 bytes */
604 u_short arglen; /* Length of cmd/resp data */
605 u_long flags; /* Message status flags */
606 u_long token; /* Reply should have the same token */
607 u_long typecookie; /* Node type understanding this message */
608 u_long cmd; /* Command identifier */
609 u_char cmdstr[NG_CMDSTRLEN+1]; /* Cmd string (for debug) */
610 } header;
611 char data[0]; /* Start of cmd/resp data */
612};
613
614#define NG_VERSION 1 /* Netgraph version */
615#define NGF_ORIG 0x0000 /* Command */
616#define NGF_RESP 0x0001 /* Response */
617.Ed
618.Pp
619Control messages have the fixed header shown above, followed by a
620variable length data section which depends on the type cookie
621and the command. Each field is explained below:
622.Bl -tag -width xxx
623.It Dv version
624Indicates the version of netgraph itself. The current version is
625.Dv NG_VERSION .
626.It Dv arglen
627This is the length of any extra arguments, which begin at
628.Dv data .
629.It Dv flags
630Indicates whether this is a command or a response control message.
631.It Dv token
632The
633.Dv token
634is a means by which a sender can match a reply message to the
635corresponding command message; the reply always has the same token.
636.Pp
637.It Dv typecookie
638The corresponding node type's unique 32-bit value.
639If a node doesn't recognize the type cookie it must reject the message
640by returning
641.Er EINVAL .
642.Pp
643Each type should have an include file that defines the commands,
644argument format, and cookie for its own messages.
645The typecookie
646insures that the same header file was included by both sender and
647receiver; when an incompatible change in the header file is made,
648the typecookie
649.Em must
650be changed.
651The de facto method for generating unique type cookies is to take the
652seconds from the epoch at the time the header file is written
653(i.e., the output of
654.Dv "date -u +'%s'" ) .
655.Pp
656There is a predefined typecookie
657.Dv NGM_GENERIC_COOKIE
658for the
659.Dq generic
660node type, and
661a corresponding set of generic messages which all nodes understand.
662The handling of these messages is automatic.
663.It Dv command
664The identifier for the message command. This is type specific,
665and is defined in the same header file as the typecookie.
666.It Dv cmdstr
667Room for a short human readable version of
668.Dq command
669(for debugging purposes only).
670.El
671.Pp
672Some modules may choose to implement messages from more than one
673of the header files and thus recognize more than one type cookie.
674.Sh Control Message ASCII Form
675Control messages are in binary format for efficiency. However, for
676debugging and human interface purposes, and if the node type supports
677it, control messages may be converted to and from an equivalent
678.Tn ASCII
679form. The
680.Tn ASCII
681form is similar to the binary form, with two exceptions:
682.Pp
683.Bl -tag -compact -width xxx
684.It o
685The
686.Dv cmdstr
687header field must contain the
688.Tn ASCII
689name of the command, corresponding to the
690.Dv cmd
691header field.
692.It o
693The
694.Dv args
695field contains a NUL-terminated
696.Tn ASCII
697string version of the message arguments.
698.El
699.Pp
700In general, the arguments field of a control messgage can be any
701arbitrary C data type. Netgraph includes parsing routines to support
702some pre-defined datatypes in
703.Tn ASCII
704with this simple syntax:
705.Pp
706.Bl -tag -compact -width xxx
707.It o
708Integer types are represented by base 8, 10, or 16 numbers.
709.It o
710Strings are enclosed in double quotes and respect the normal
711C language backslash escapes.
712.It o
713IP addresses have the obvious form.
714.It o
715Arrays are enclosed in square brackets, with the elements listed
716consecutively starting at index zero. An element may have an optional
717index and equals sign preceeding it. Whenever an element
718does not have an explicit index, the index is implicitly the previous
719element's index plus one.
720.It o
721Structures are enclosed in curly braces, and each field is specified
722in the form
723.Dq fieldname=value .
724.It o
725Any array element or structure field whose value is equal to its
726.Dq default value
727may be omitted. For integer types, the default value
728is usually zero; for string types, the empty string.
729.It o
730Array elements and structure fields may be specified in any order.
731.El
732.Pp
733Each node type may define its own arbitrary types by providing
734the necessary routines to parse and unparse.
735.Tn ASCII
736forms defined
737for a specific node type are documented in the documentation for
738that node type.
739.Sh Generic Control Messages
740There are a number of standard predefined messages that will work
741for any node, as they are supported directly by the framework itself.
742These are defined in
743.Pa ng_message.h
744along with the basic layout of messages and other similar information.
745.Bl -tag -width xxx
746.It Dv NGM_CONNECT
747Connect to another node, using the supplied hook names on either end.
748.It Dv NGM_MKPEER
749Construct a node of the given type and then connect to it using the
750supplied hook names.
751.It Dv NGM_SHUTDOWN
752The target node should disconnect from all its neighbours and shut down.
753Persistent nodes such as those representing physical hardware
754might not disappear from the node namespace, but only reset themselves.
755The node must disconnect all of its hooks.
756This may result in neighbors shutting themselves down, and possibly a
757cascading shutdown of the entire connected graph.
758.It Dv NGM_NAME
759Assign a name to a node. Nodes can exist without having a name, and this
760is the default for nodes created using the
761.Dv NGM_MKPEER
762method. Such nodes can only be addressed relatively or by their ID number.
763.It Dv NGM_RMHOOK
764Ask the node to break a hook connection to one of its neighbours.
765Both nodes will have their
766.Dq disconnect
767method invoked.
768Either node may elect to totally shut down as a result.
769.It Dv NGM_NODEINFO
770Asks the target node to describe itself. The four returned fields
771are the node name (if named), the node type, the node ID and the
772number of hooks attached. The ID is an internal number unique to that node.
773.It Dv NGM_LISTHOOKS
774This returns the information given by
775.Dv NGM_NODEINFO ,
776but in addition
777includes an array of fields describing each link, and the description for
778the node at the far end of that link.
779.It Dv NGM_LISTNAMES
780This returns an array of node descriptions (as for
781.Dv NGM_NODEINFO ")"
782where each entry of the array describes a named node.
783All named nodes will be described.
784.It Dv NGM_LISTNODES
785This is the same as
786.Dv NGM_LISTNAMES
787except that all nodes are listed regardless of whether they have a name or not.
788.It Dv NGM_LISTTYPES
789This returns a list of all currently installed netgraph types.
790.It Dv NGM_TEXT_STATUS
791The node may return a text formatted status message.
792The status information is determined entirely by the node type.
793It is the only "generic" message
794that requires any support within the node itself and as such the node may
795elect to not support this message. The text response must be less than
796.Dv NG_TEXTRESPONSE
797bytes in length (presently 1024). This can be used to return general
798status information in human readable form.
799.It Dv NGM_BINARY2ASCII
800This message converts a binary control message to its
801.Tn ASCII
802form.
803The entire control message to be converted is contained within the
804arguments field of the
805.Dv Dv NGM_BINARY2ASCII
806message itself. If successful, the reply will contain the same control
807message in
808.Tn ASCII
809form.
810A node will typically only know how to translate messages that it
811itself understands, so the target node of the
812.Dv NGM_BINARY2ASCII
813is often the same node that would actually receive that message.
814.It Dv NGM_ASCII2BINARY
815The opposite of
816.Dv NGM_BINARY2ASCII .
817The entire control message to be converted, in
818.Tn ASCII
819form, is contained
820in the arguments section of the
821.Dv NGM_ASCII2BINARY
822and need only have the
823.Dv flags ,
824.Dv cmdstr ,
825and
826.Dv arglen
827header fields filled in, plus the NUL-terminated string version of
828the arguments in the arguments field. If successful, the reply
829contains the binary version of the control message.
830.El
831.Sh Metadata
832Data moving through the
833.Nm
834system can be accompanied by meta-data that describes some
835aspect of that data. The form of the meta-data is a fixed header,
836which contains enough information for most uses, and can optionally
837be supplemented by trailing
838.Em option
839structures, which contain a
840.Em cookie
841(see the section on control messages), an identifier, a length and optional
842data. If a node does not recognize the cookie associated with an option,
843it should ignore that option.
844.Pp
845Meta data might include such things as priority, discard eligibility,
846or special processing requirements. It might also mark a packet for
847debug status, etc. The use of meta-data is still experimental.
848.Sh INITIALIZATION
849The base
850.Nm
851code may either be statically compiled
852into the kernel or else loaded dynamically as a KLD via
853.Xr kldload 8 .
854In the former case, include
855.Bd -literal -offset 4n -compact
856
857 options NETGRAPH
858
859.Ed
860in your kernel configuration file. You may also include selected
861node types in the kernel compilation, for example:
862.Bd -literal -offset 4n -compact
863
864 options NETGRAPH
865 options NETGRAPH_SOCKET
866 options NETGRAPH_ECHO
867
868.Ed
869.Pp
870Once the
871.Nm
872subsystem is loaded, individual node types may be loaded at any time
873as KLD modules via
874.Xr kldload 8 .
875Moreover,
876.Nm
877knows how to automatically do this; when a request to create a new
878node of unknown type
879.Em type
880is made,
881.Nm
882will attempt to load the KLD module
883.Pa ng_type.ko .
884.Pp
885Types can also be installed at boot time, as certain device drivers
886may want to export each instance of the device as a netgraph node.
887.Pp
888In general, new types can be installed at any time from within the
889kernel by calling
890.Fn ng_newtype ,
891supplying a pointer to the type's
892.Dv struct ng_type
893structure.
894.Pp
895The
896.Fn NETGRAPH_INIT
897macro automates this process by using a linker set.
898.Sh EXISTING NODE TYPES
899Several node types currently exist. Each is fully documented
900in its own man page:
901.Bl -tag -width xxx
902.It SOCKET
903The socket type implements two new sockets in the new protocol domain
904.Dv PF_NETGRAPH .
905The new sockets protocols are
906.Dv NG_DATA
907and
908.Dv NG_CONTROL ,
909both of type
910.Dv SOCK_DGRAM .
911Typically one of each is associated with a socket node.
912When both sockets have closed, the node will shut down. The
913.Dv NG_DATA
914socket is used for sending and receiving data, while the
915.Dv NG_CONTROL
916socket is used for sending and receiving control messages.
917Data and control messages are passed using the
918.Xr sendto 2
919and
920.Xr recvfrom 2
921calls, using a
922.Dv struct sockaddr_ng
923socket address.
924.Pp
925.It HOLE
926Responds only to generic messages and is a
927.Dq black hole
928for data, Useful for testing. Always accepts new hooks.
929.Pp
930.It ECHO
931Responds only to generic messages and always echoes data back through the
932hook from which it arrived. Returns any non generic messages as their
933own response. Useful for testing. Always accepts new hooks.
934.Pp
935.It TEE
936This node is useful for
937.Dq snooping .
938It has 4 hooks:
939.Dv left ,
940.Dv right ,
941.Dv left2right ,
942and
943.Dv right2left .
944Data entering from the right is passed to the left and duplicated on
945.Dv right2left,
946and data entering from the left is passed to the right and
947duplicated on
948.Dv left2right .
949Data entering from
950.Dv left2right
951is sent to the right and data from
952.Dv right2left
953to left.
954.Pp
955.It RFC1490 MUX
956Encapsulates/de-encapsulates frames encoded according to RFC 1490.
957Has a hook for the encapsulated packets
958.Pq Dq downstream
959and one hook
960for each protocol (i.e., IP, PPP, etc.).
961.Pp
962.It FRAME RELAY MUX
963Encapsulates/de-encapsulates Frame Relay frames.
964Has a hook for the encapsulated packets
965.Pq Dq downstream
966and one hook
967for each DLCI.
968.Pp
969.It FRAME RELAY LMI
970Automatically handles frame relay
971.Dq LMI
972(link management interface) operations and packets.
973Automatically probes and detects which of several LMI standards
974is in use at the exchange.
975.Pp
976.It TTY
977This node is also a line discipline. It simply converts between mbuf
978frames and sequential serial data, allowing a tty to appear as a netgraph
979node. It has a programmable
980.Dq hotkey
981character.
982.Pp
983.It ASYNC
984This node encapsulates and de-encapsulates asynchronous frames
985according to RFC 1662. This is used in conjunction with the TTY node
986type for supporting PPP links over asynchronous serial lines.
987.Pp
988.It INTERFACE
989This node is also a system networking interface. It has hooks representing
990each protocol family (IP, AppleTalk, IPX, etc.) and appears in the output of
991.Xr ifconfig 8 .
992The interfaces are named
993.Em ng0 ,
994.Em ng1 ,
995etc.
996.El
997.Sh NOTES
998Whether a named node exists can be checked by trying to send a control message
999to it (e.g.,
1000.Dv NGM_NODEINFO
1001).
1002If it does not exist,
1003.Er ENOENT
1004will be returned.
1005.Pp
1006All data messages are mbuf chains with the M_PKTHDR flag set.
1007.Pp
1008Nodes are responsible for freeing what they allocate.
1009There are three exceptions:
1010.Bl -tag -width xxxx
1011.It 1
1012Mbufs sent across a data link are never to be freed by the sender,
1013unless it is returned from the recipient.
1014.It 2
1015Any meta-data information traveling with the data has the same restriction.
1016It might be freed by any node the data passes through, and a
1017.Dv NULL
1018passed onwards, but the caller will never free it.
1019Two macros
1020.Fn NG_FREE_META "meta"
1021and
1022.Fn NG_FREE_DATA "m" "meta"
1023should be used if possible to free data and meta data (see
1024.Pa netgraph.h ) .
1025.It 3
1026Messages sent using
1027.Fn ng_send_message
1028are freed by the recipient. As in the case above, the addresses
1029associated with the message are freed by whatever allocated them so the
1030recipient should copy them if it wants to keep that information.
1031.El
1032.Sh FILES
1033.Bl -tag -width xxxxx -compact
1034.It Pa /sys/netgraph/netgraph.h
1035Definitions for use solely within the kernel by
1036.Nm
1037nodes.
1038.It Pa /sys/netgraph/ng_message.h
1039Definitions needed by any file that needs to deal with
1040.Nm
1041messages.
1042.It Pa /sys/netgraph/ng_socket.h
1043Definitions needed to use
1044.Nm
1045socket type nodes.
1046.It Pa /sys/netgraph/ng_{type}.h
1047Definitions needed to use
1048.Nm
1049{type}
1050nodes, including the type cookie definition.
1051.It Pa /modules/netgraph.ko
1052Netgraph subsystem loadable KLD module.
1053.It Pa /modules/ng_{type}.ko
1054Loadable KLD module for node type {type}.
1055.El
1056.Sh USER MODE SUPPORT
1057There is a library for supporting user-mode programs that wish
1058to interact with the netgraph system. See
1059.Xr netgraph 3
1060for details.
1061.Pp
1062Two user-mode support programs,
1063.Xr ngctl 8
1064and
1065.Xr nghook 8 ,
1066are available to assist manual configuration and debugging.
1067.Pp
1068There are a few useful techniques for debugging new node types.
1069First, implementing new node types in user-mode first
1070makes debugging easier.
1071The
1072.Em tee
1073node type is also useful for debugging, especially in conjunction with
1074.Xr ngctl 8
1075and
1076.Xr nghook 8 .
1077.Sh SEE ALSO
1078.Xr socket 2 ,
1079.Xr netgraph 3 ,
1080.Xr ng_async 4 ,
1081.Xr ng_bpf 4 ,
1082.Xr ng_cisco 4 ,
1083.Xr ng_ether 4 ,
1084.Xr ng_echo 4 ,
1085.Xr ng_frame_relay 4 ,
1086.Xr ng_hole 4 ,
1087.Xr ng_iface 4 ,
1088.Xr ng_ksocket 4 ,
1089.Xr ng_lmi 4 ,
1090.Xr ng_mppc 4 ,
1091.Xr ng_ppp 4 ,
1092.Xr ng_pppoe 4 ,
1093.Xr ng_rfc1490 4 ,
1094.Xr ng_socket 4 ,
1095.Xr ng_tee 4 ,
1096.Xr ng_tty 4 ,
1097.Xr ng_UI 4 ,
1098.Xr ng_vjc 4 ,
1099.Xr ng_{type} 4 ,
1100.Xr ngctl 8 ,
1101.Xr nghook 8
1102.Sh HISTORY
1103The
1104.Nm
1105system was designed and first implemented at Whistle Communications, Inc.
1106in a version of
1107.Fx 2.2
1108customized for the Whistle InterJet.
1109It first made its debut in the main tree in
1110.Fx 3.4 .
1111.Sh AUTHORS
1112.An -nosplit
1113.An Julian Elischer Aq julian@FreeBSD.org ,
1114with contributions by
1115.An Archie Cobbs Aq archie@FreeBSD.org .
2.\" All rights reserved.
3.\"
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.
14.\"
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
31.\" OF SUCH DAMAGE.
32.\"
33.\" Authors: Julian Elischer <julian@FreeBSD.org>
34.\" Archie Cobbs <archie@FreeBSD.org>
35.\"
36.\" $FreeBSD: head/share/man/man4/netgraph.4 69027 2000-11-22 09:35:58Z ru $
37.\" $Whistle: netgraph.4,v 1.7 1999/01/28 23:54:52 julian Exp $
38.\"
39.Dd January 19, 1999
40.Dt NETGRAPH 4
41.Os FreeBSD
42.Sh NAME
43.Nm netgraph
44.Nd graph based kernel networking subsystem
45.Sh DESCRIPTION
46The
47.Nm
48system provides a uniform and modular system for the implementation
49of kernel objects which perform various networking functions. The objects,
50known as
51.Em nodes ,
52can be arranged into arbitrarily complicated graphs. Nodes have
53.Em hooks
54which are used to connect two nodes together, forming the edges in the graph.
55Nodes communicate along the edges to process data, implement protocols, etc.
56.Pp
57The aim of
58.Nm
59is to supplement rather than replace the existing kernel networking
60infrastructure. It provides:
61.Pp
62.Bl -bullet -compact -offset 2n
63.It
64A flexible way of combining protocol and link level drivers
65.It
66A modular way to implement new protocols
67.It
68A common framework for kernel entities to inter-communicate
69.It
70A reasonably fast, kernel-based implementation
71.El
72.Sh Nodes and Types
73The most fundamental concept in
74.Nm
75is that of a
76.Em node .
77All nodes implement a number of predefined methods which allow them
78to interact with other nodes in a well defined manner.
79.Pp
80Each node has a
81.Em type ,
82which is a static property of the node determined at node creation time.
83A node's type is described by a unique
84.Tn ASCII
85type name.
86The type implies what the node does and how it may be connected
87to other nodes.
88.Pp
89In object-oriented language, types are classes and nodes are instances
90of their respective class. All node types are subclasses of the generic node
91type, and hence inherit certain common functionality and capabilities
92(e.g., the ability to have an
93.Tn ASCII
94name).
95.Pp
96Nodes may be assigned a globally unique
97.Tn ASCII
98name which can be
99used to refer to the node.
100The name must not contain the characters
101.Dq \&.
102or
103.Dq \&:
104and is limited to
105.Dv "NG_NODELEN + 1"
106characters (including NUL byte).
107.Pp
108Each node instance has a unique
109.Em ID number
110which is expressed as a 32-bit hex value. This value may be used to
111refer to a node when there is no
112.Tn ASCII
113name assigned to it.
114.Sh Hooks
115Nodes are connected to other nodes by connecting a pair of
116.Em hooks ,
117one from each node. Data flows bidirectionally between nodes along
118connected pairs of hooks. A node may have as many hooks as it
119needs, and may assign whatever meaning it wants to a hook.
120.Pp
121Hooks have these properties:
122.Pp
123.Bl -bullet -compact -offset 2n
124.It
125A hook has an
126.Tn ASCII
127name which is unique among all hooks
128on that node (other hooks on other nodes may have the same name).
129The name must not contain a
130.Dq \&.
131or a
132.Dq \&:
133and is
134limited to
135.Dv "NG_HOOKLEN + 1"
136characters (including NUL byte).
137.It
138A hook is always connected to another hook. That is, hooks are
139created at the time they are connected, and breaking an edge by
140removing either hook destroys both hooks.
141.El
142.Pp
143A node may decide to assign special meaning to some hooks.
144For example, connecting to the hook named
145.Dq debug
146might trigger
147the node to start sending debugging information to that hook.
148.Sh Data Flow
149Two types of information flow between nodes: data messages and
150control messages. Data messages are passed in mbuf chains along the edges
151in the graph, one edge at a time. The first mbuf in a chain must have the
152.Dv M_PKTHDR
153flag set. Each node decides how to handle data coming in on its hooks.
154.Pp
155Control messages are type-specific C structures sent from one node
156directly to some arbitrary other node. Control messages have a common
157header format, followed by type-specific data, and are binary structures
158for efficiency. However, node types also may support conversion of the
159type specific data between binary and
160.Tn ASCII
161for debugging and human interface purposes (see the
162.Dv NGM_ASCII2BINARY
163and
164.Dv NGM_BINARY2ASCII
165generic control messages below). Nodes are not required to support
166these conversions.
167.Pp
168There are two ways to address a control message. If
169there is a sequence of edges connecting the two nodes, the message
170may be
171.Dq source routed
172by specifying the corresponding sequence
173of hooks as the destination address for the message (relative
174addressing). Otherwise, the recipient node global
175.Tn ASCII
176name
177(or equivalent ID based name) is used as the destination address
178for the message (absolute addressing). The two types of addressing
179may be combined, by specifying an absolute start node and a sequence
180of hooks.
181.Pp
182Messages often represent commands that are followed by a reply message
183in the reverse direction. To facilitate this, the recipient of a
184control message is supplied with a
185.Dq return address
186that is suitable
187for addressing a reply.
188.Pp
189Each control message contains a 32 bit value called a
190.Em typecookie
191indicating the type of the message, i.e., how to interpret it.
192Typically each type defines a unique typecookie for the messages
193that it understands. However, a node may choose to recognize and
194implement more than one type of message.
195.Pp
196If message is delivered to an address that implies that it arrived
197at that node through a particular hook, that hook is identified to the
198receiving node. This allows a message to be rerouted or passed on, should
199a node decide that this is required.
200.Sh Netgraph is Functional
201In order to minimize latency, most
202.Nm
203operations are functional.
204That is, data and control messages are delivered by making function
205calls rather than by using queues and mailboxes. For example, if node
206A wishes to send a data mbuf to neighboring node B, it calls the
207generic
208.Nm
209data delivery function. This function in turn locates
210node B and calls B's
211.Dq receive data
212method.
213.Pp
214It is allowable for nodes to reject a data packet, or to pass it back to the
215caller in a modified or completely replaced form. The caller can notify the
216node being called that it does not wish to receive any such packets
217by using the
218.Fn NG_SEND_DATA
219macro, in which case, the second node should just discard rejected packets.
220If the sender knows how to handle returned packets, it must use the
221.Fn NG_SEND_DATA_RET
222macro, which will adjust the parameters to point to the returned data
223or NULL if no data was returned to the caller. No packet return is possible
224across a queuing link (though an explicitly sent return is of course possible,
225it doesn't mean quite the same thing).
226.Pp
227While this mode of operation
228results in good performance, it has a few implications for node
229developers:
230.Pp
231.Bl -bullet -compact -offset 2n
232.It
233Whenever a node delivers a data or control message, the node
234may need to allow for the possibility of receiving a returning
235message before the original delivery function call returns.
236.It
237Netgraph nodes and support routines generally run at
238.Fn splnet .
239However, some nodes may want to send data and control messages
240from a different priority level. Netgraph supplies queueing routines which
241utilize the NETISR system to move message delivery to
242.Fn splnet .
243Nodes that run at other priorities (e.g. interfaces) can be directly
244linked to other nodes so that the combination runs at the other priority,
245however any interaction with nodes running at splnet MUST be achievd via the
246queueing functions, (which use the
247.Fn netisr
248feature of the kernel).
249Note that messages are always received at
250.Fn splnet .
251.It
252It's possible for an infinite loop to occur if the graph contains cycles.
253.El
254.Pp
255So far, these issues have not proven problematical in practice.
256.Sh Interaction With Other Parts of the Kernel
257A node may have a hidden interaction with other components of the
258kernel outside of the
259.Nm
260subsystem, such as device hardware,
261kernel protocol stacks, etc. In fact, one of the benefits of
262.Nm
263is the ability to join disparate kernel networking entities together in a
264consistent communication framework.
265.Pp
266An example is the node type
267.Em socket
268which is both a netgraph node and a
269.Xr socket 2
270BSD socket in the protocol family
271.Dv PF_NETGRAPH .
272Socket nodes allow user processes to participate in
273.Nm .
274Other nodes communicate with socket nodes using the usual methods, and the
275node hides the fact that it is also passing information to and from a
276cooperating user process.
277.Pp
278Another example is a device driver that presents
279a node interface to the hardware.
280.Sh Node Methods
281Nodes are notified of the following actions via function calls
282to the following node methods (all at
283.Fn splnet )
284and may accept or reject that action (by returning the appropriate
285error code):
286.Bl -tag -width xxx
287.It Creation of a new node
288The constructor for the type is called. If creation of a new node is
289allowed, the constructor must call the generic node creation
290function (in object-oriented terms, the superclass constructor)
291and then allocate any special resources it needs. For nodes that
292correspond to hardware, this is typically done during the device
293attach routine. Often a global
294.Tn ASCII
295name corresponding to the
296device name is assigned here as well.
297.It Creation of a new hook
298The hook is created and tentatively
299linked to the node, and the node is told about the name that will be
300used to describe this hook. The node sets up any special data structures
301it needs, or may reject the connection, based on the name of the hook.
302.It Successful connection of two hooks
303After both ends have accepted their
304hooks, and the links have been made, the nodes get a chance to
305find out who their peer is across the link and can then decide to reject
306the connection. Tear-down is automatic.
307.It Destruction of a hook
308The node is notified of a broken connection. The node may consider some hooks
309to be critical to operation and others to be expendable: the disconnection
310of one hook may be an acceptable event while for another it
311may effect a total shutdown for the node.
312.It Shutdown of a node
313This method allows a node to clean up
314and to ensure that any actions that need to be performed
315at this time are taken. The method must call the generic (i.e., superclass)
316node destructor to get rid of the generic components of the node.
317Some nodes (usually associated with a piece of hardware) may be
318.Em persistent
319in that a shutdown breaks all edges and resets the node,
320but doesn't remove it, in which case the generic destructor is not called.
321.El
322.Sh Sending and Receiving Data
323Three other methods are also supported by all nodes:
324.Bl -tag -width xxx
325.It Receive data message
326An mbuf chain is passed to the node.
327The node is notified on which hook the data arrived,
328and can use this information in its processing decision.
329The receiving node must always
330.Fn m_freem
331the mbuf chain on completion or error, pass it back (reject it), or pass
332it on to another node
333(or kernel module) which will then be responsible for freeing it.
334If a node passes a packet back to the caller, it does not have to be the
335same mbuf, in which case the original must be freed. Passing a packet
336back allows a module to modify the original data (e.g. encrypt it),
337or in some other way filter it (e.g. packet filtering).
338.Pp
339In addition to the mbuf chain itself there is also a pointer to a
340structure describing meta-data about the message
341(e.g. priority information). This pointer may be
342.Dv NULL
343if there is no additional information. The format for this information is
344described in
345.Pa netgraph.h .
346The memory for meta-data must allocated via
347.Fn malloc
348with type
349.Dv M_NETGRAPH .
350As with the data itself, it is the receiver's responsibility to
351.Fn free
352the meta-data. If the mbuf chain is freed the meta-data must
353be freed at the same time. If the meta-data is freed but the
354real data on is passed on, then a
355.Dv NULL
356pointer must be substituted.
357Meta-data may be passed back in the same way that mbuf data may be passed back.
358As with mbuf data, the rejected or returned meta-data pointer may point to
359the same or different meta-data as that passed in,
360and if it is different, the original must be freed.
361.Pp
362The receiving node may decide to defer the data by queueing it in the
363.Nm
364NETISR system (see below).
365.Pp
366The structure and use of meta-data is still experimental, but is presently used in
367frame-relay to indicate that management packets should be queued for transmission
368at a higher priority than data packets. This is required for
369conformance with Frame Relay standards.
370.Pp
371.It Receive queued data message
372Usually this will be the same function as
373.Em Receive data message.
374This is the entry point called when a data message is being handed to
375the node after having been queued in the NETISR system.
376This allows a node to decide in the
377.Em Receive data message
378method that a message should be deferred and queued,
379and be sure that when it is processed from the queue,
380it will not be queued again.
381.It Receive control message
382This method is called when a control message is addressed to the node.
383A return address is always supplied, giving the address of the node
384that originated the message so a reply message can be sent anytime later.
385.Pp
386It is possible for a synchronous reply to be made, and in fact this
387is more common in practice.
388This is done by setting a pointer (supplied as an extra function parameter)
389to point to the reply.
390Then when the control message delivery function returns,
391the caller can check if this pointer has been made non-NULL,
392and if so then it points to the reply message allocated via
393.Fn malloc
394and containing the synchronous response. In both directions,
395(request and response) it is up to the
396receiver of that message to
397.Fn free
398the control message buffer. All control messages and replies are
399allocated with
400.Fn malloc
401type
402.Dv M_NETGRAPH .
403.Pp
404If the message was delivered via a specific hook, that hook will
405also be made known, which allows the use of such things as flow-control
406messages, and status change messages, where the node may want to forward
407the message out another hook to that on which it arrived.
408.El
409.Pp
410Much use has been made of reference counts, so that nodes being
411free'd of all references are automatically freed, and this behaviour
412has been tested and debugged to present a consistent and trustworthy
413framework for the
414.Dq type module
415writer to use.
416.Sh Addressing
417The
418.Nm
419framework provides an unambiguous and simple to use method of specifically
420addressing any single node in the graph. The naming of a node is
421independent of its type, in that another node, or external component
422need not know anything about the node's type in order to address it so as
423to send it a generic message type. Node and hook names should be
424chosen so as to make addresses meaningful.
425.Pp
426Addresses are either absolute or relative. An absolute address begins
427with a node name, (or ID), followed by a colon, followed by a sequence of hook
428names separated by periods. This addresses the node reached by starting
429at the named node and following the specified sequence of hooks.
430A relative address includes only the sequence of hook names, implicitly
431starting hook traversal at the local node.
432.Pp
433There are a couple of special possibilities for the node name.
434The name
435.Dq \&.
436(referred to as
437.Dq \&.: )
438always refers to the local node.
439Also, nodes that have no global name may be addressed by their ID numbers,
440by enclosing the hex representation of the ID number within square brackets.
441Here are some examples of valid netgraph addresses:
442.Bd -literal -offset 4n -compact
443
444 .:
445 foo:
446 .:hook1
447 foo:hook1.hook2
448 [f057cd80]:hook1
449.Ed
450.Pp
451Consider the following set of nodes might be created for a site with
452a single physical frame relay line having two active logical DLCI channels,
453with RFC-1490 frames on DLCI 16 and PPP frames over DLCI 20:
454.Pp
455.Bd -literal
456[type SYNC ] [type FRAME] [type RFC1490]
457[ "Frame1" ](uplink)<-->(data)[<un-named>](dlci16)<-->(mux)[<un-named> ]
458[ A ] [ B ](dlci20)<---+ [ C ]
459 |
460 | [ type PPP ]
461 +>(mux)[<un-named>]
462 [ D ]
463.Ed
464.Pp
465One could always send a control message to node C from anywhere
466by using the name
467.Em "Frame1:uplink.dlci16" .
468In this case, node C would also be notified that the message
469reached it via its hook
470.Dq mux .
471Similarly,
472.Em "Frame1:uplink.dlci20"
473could reliably be used to reach node D, and node A could refer
474to node B as
475.Em ".:uplink" ,
476or simply
477.Em "uplink" .
478Conversely, B can refer to A as
479.Em "data" .
480The address
481.Em "mux.data"
482could be used by both nodes C and D to address a message to node A.
483.Pp
484Note that this is only for
485.Em control messages .
486In each of these cases, where a relative addressing mode is
487used, the recipient is notified of the hook on which the
488message arrived, as well as
489the originating node.
490This allows the option of hop-by-hop distibution of messages and
491state information.
492Data messages are
493.Em only
494routed one hop at a time, by specifying the departing
495hook, with each node making
496the next routing decision. So when B receives a frame on hook
497.Dq data
498it decodes the frame relay header to determine the DLCI,
499and then forwards the unwrapped frame to either C or D.
500.Pp
501A similar graph might be used to represent multi-link PPP running
502over an ISDN line:
503.Pp
504.Bd -literal
505[ type BRI ](B1)<--->(link1)[ type MPP ]
506[ "ISDN1" ](B2)<--->(link2)[ (no name) ]
507[ ](D) <-+
508 |
509 +----------------+
510 |
511 +->(switch)[ type Q.921 ](term1)<---->(datalink)[ type Q.931 ]
512 [ (no name) ] [ (no name) ]
513.Ed
514.Sh Netgraph Structures
515Interesting members of the node and hook structures are shown below:
516.Bd -literal
517struct ng_node {
518 char *name; /* Optional globally unique name */
519 void *private; /* Node implementation private info */
520 struct ng_type *type; /* The type of this node */
521 int refs; /* Number of references to this struct */
522 int numhooks; /* Number of connected hooks */
523 hook_p hooks; /* Linked list of (connected) hooks */
524};
525typedef struct ng_node *node_p;
526
527struct ng_hook {
528 char *name; /* This node's name for this hook */
529 void *private; /* Node implementation private info */
530 int refs; /* Number of references to this struct */
531 struct ng_node *node; /* The node this hook is attached to */
532 struct ng_hook *peer; /* The other hook in this connected pair */
533 struct ng_hook *next; /* Next in list of hooks for this node */
534};
535typedef struct ng_hook *hook_p;
536.Ed
537.Pp
538The maintenance of the name pointers, reference counts, and linked list
539of hooks for each node is handled automatically by the
540.Nm
541subsystem.
542Typically a node's private info contains a back-pointer to the node or hook
543structure, which counts as a new reference that must be registered by
544incrementing
545.Dv "node->refs" .
546.Pp
547From a hook you can obtain the corresponding node, and from
548a node the list of all active hooks.
549.Pp
550Node types are described by these structures:
551.Bd -literal
552/** How to convert a control message from binary <-> ASCII */
553struct ng_cmdlist {
554 u_int32_t cookie; /* typecookie */
555 int cmd; /* command number */
556 const char *name; /* command name */
557 const struct ng_parse_type *mesgType; /* args if !NGF_RESP */
558 const struct ng_parse_type *respType; /* args if NGF_RESP */
559};
560
561struct ng_type {
562 u_int32_t version; /* Must equal NG_VERSION */
563 const char *name; /* Unique type name */
564
565 /* Module event handler */
566 modeventhand_t mod_event; /* Handle load/unload (optional) */
567
568 /* Constructor */
569 int (*constructor)(node_p *node); /* Create a new node */
570
571 /** Methods using the node **/
572 int (*rcvmsg)(node_p node, /* Receive control message */
573 struct ng_mesg *msg, /* The message */
574 const char *retaddr, /* Return address */
575 struct ng_mesg **resp /* Synchronous response */
576 hook_p lasthook); /* last hook traversed */
577 int (*shutdown)(node_p node); /* Shutdown this node */
578 int (*newhook)(node_p node, /* create a new hook */
579 hook_p hook, /* Pre-allocated struct */
580 const char *name); /* Name for new hook */
581
582 /** Methods using the hook **/
583 int (*connect)(hook_p hook); /* Confirm new hook attachment */
584 int (*rcvdata)(hook_p hook, /* Receive data on a hook */
585 struct mbuf *m, /* The data in an mbuf */
586 meta_p meta, /* Meta-data, if any */
587 struct mbuf **ret_m, /* return data here */
588 meta_p *ret_meta); /* return Meta-data here */
589 int (*disconnect)(hook_p hook); /* Notify disconnection of hook */
590
591 /** How to convert control messages binary <-> ASCII */
592 const struct ng_cmdlist *cmdlist; /* Optional; may be NULL */
593};
594.Ed
595.Pp
596Control messages have the following structure:
597.Bd -literal
598#define NG_CMDSTRLEN 15 /* Max command string (16 with null) */
599
600struct ng_mesg {
601 struct ng_msghdr {
602 u_char version; /* Must equal NG_VERSION */
603 u_char spare; /* Pad to 2 bytes */
604 u_short arglen; /* Length of cmd/resp data */
605 u_long flags; /* Message status flags */
606 u_long token; /* Reply should have the same token */
607 u_long typecookie; /* Node type understanding this message */
608 u_long cmd; /* Command identifier */
609 u_char cmdstr[NG_CMDSTRLEN+1]; /* Cmd string (for debug) */
610 } header;
611 char data[0]; /* Start of cmd/resp data */
612};
613
614#define NG_VERSION 1 /* Netgraph version */
615#define NGF_ORIG 0x0000 /* Command */
616#define NGF_RESP 0x0001 /* Response */
617.Ed
618.Pp
619Control messages have the fixed header shown above, followed by a
620variable length data section which depends on the type cookie
621and the command. Each field is explained below:
622.Bl -tag -width xxx
623.It Dv version
624Indicates the version of netgraph itself. The current version is
625.Dv NG_VERSION .
626.It Dv arglen
627This is the length of any extra arguments, which begin at
628.Dv data .
629.It Dv flags
630Indicates whether this is a command or a response control message.
631.It Dv token
632The
633.Dv token
634is a means by which a sender can match a reply message to the
635corresponding command message; the reply always has the same token.
636.Pp
637.It Dv typecookie
638The corresponding node type's unique 32-bit value.
639If a node doesn't recognize the type cookie it must reject the message
640by returning
641.Er EINVAL .
642.Pp
643Each type should have an include file that defines the commands,
644argument format, and cookie for its own messages.
645The typecookie
646insures that the same header file was included by both sender and
647receiver; when an incompatible change in the header file is made,
648the typecookie
649.Em must
650be changed.
651The de facto method for generating unique type cookies is to take the
652seconds from the epoch at the time the header file is written
653(i.e., the output of
654.Dv "date -u +'%s'" ) .
655.Pp
656There is a predefined typecookie
657.Dv NGM_GENERIC_COOKIE
658for the
659.Dq generic
660node type, and
661a corresponding set of generic messages which all nodes understand.
662The handling of these messages is automatic.
663.It Dv command
664The identifier for the message command. This is type specific,
665and is defined in the same header file as the typecookie.
666.It Dv cmdstr
667Room for a short human readable version of
668.Dq command
669(for debugging purposes only).
670.El
671.Pp
672Some modules may choose to implement messages from more than one
673of the header files and thus recognize more than one type cookie.
674.Sh Control Message ASCII Form
675Control messages are in binary format for efficiency. However, for
676debugging and human interface purposes, and if the node type supports
677it, control messages may be converted to and from an equivalent
678.Tn ASCII
679form. The
680.Tn ASCII
681form is similar to the binary form, with two exceptions:
682.Pp
683.Bl -tag -compact -width xxx
684.It o
685The
686.Dv cmdstr
687header field must contain the
688.Tn ASCII
689name of the command, corresponding to the
690.Dv cmd
691header field.
692.It o
693The
694.Dv args
695field contains a NUL-terminated
696.Tn ASCII
697string version of the message arguments.
698.El
699.Pp
700In general, the arguments field of a control messgage can be any
701arbitrary C data type. Netgraph includes parsing routines to support
702some pre-defined datatypes in
703.Tn ASCII
704with this simple syntax:
705.Pp
706.Bl -tag -compact -width xxx
707.It o
708Integer types are represented by base 8, 10, or 16 numbers.
709.It o
710Strings are enclosed in double quotes and respect the normal
711C language backslash escapes.
712.It o
713IP addresses have the obvious form.
714.It o
715Arrays are enclosed in square brackets, with the elements listed
716consecutively starting at index zero. An element may have an optional
717index and equals sign preceeding it. Whenever an element
718does not have an explicit index, the index is implicitly the previous
719element's index plus one.
720.It o
721Structures are enclosed in curly braces, and each field is specified
722in the form
723.Dq fieldname=value .
724.It o
725Any array element or structure field whose value is equal to its
726.Dq default value
727may be omitted. For integer types, the default value
728is usually zero; for string types, the empty string.
729.It o
730Array elements and structure fields may be specified in any order.
731.El
732.Pp
733Each node type may define its own arbitrary types by providing
734the necessary routines to parse and unparse.
735.Tn ASCII
736forms defined
737for a specific node type are documented in the documentation for
738that node type.
739.Sh Generic Control Messages
740There are a number of standard predefined messages that will work
741for any node, as they are supported directly by the framework itself.
742These are defined in
743.Pa ng_message.h
744along with the basic layout of messages and other similar information.
745.Bl -tag -width xxx
746.It Dv NGM_CONNECT
747Connect to another node, using the supplied hook names on either end.
748.It Dv NGM_MKPEER
749Construct a node of the given type and then connect to it using the
750supplied hook names.
751.It Dv NGM_SHUTDOWN
752The target node should disconnect from all its neighbours and shut down.
753Persistent nodes such as those representing physical hardware
754might not disappear from the node namespace, but only reset themselves.
755The node must disconnect all of its hooks.
756This may result in neighbors shutting themselves down, and possibly a
757cascading shutdown of the entire connected graph.
758.It Dv NGM_NAME
759Assign a name to a node. Nodes can exist without having a name, and this
760is the default for nodes created using the
761.Dv NGM_MKPEER
762method. Such nodes can only be addressed relatively or by their ID number.
763.It Dv NGM_RMHOOK
764Ask the node to break a hook connection to one of its neighbours.
765Both nodes will have their
766.Dq disconnect
767method invoked.
768Either node may elect to totally shut down as a result.
769.It Dv NGM_NODEINFO
770Asks the target node to describe itself. The four returned fields
771are the node name (if named), the node type, the node ID and the
772number of hooks attached. The ID is an internal number unique to that node.
773.It Dv NGM_LISTHOOKS
774This returns the information given by
775.Dv NGM_NODEINFO ,
776but in addition
777includes an array of fields describing each link, and the description for
778the node at the far end of that link.
779.It Dv NGM_LISTNAMES
780This returns an array of node descriptions (as for
781.Dv NGM_NODEINFO ")"
782where each entry of the array describes a named node.
783All named nodes will be described.
784.It Dv NGM_LISTNODES
785This is the same as
786.Dv NGM_LISTNAMES
787except that all nodes are listed regardless of whether they have a name or not.
788.It Dv NGM_LISTTYPES
789This returns a list of all currently installed netgraph types.
790.It Dv NGM_TEXT_STATUS
791The node may return a text formatted status message.
792The status information is determined entirely by the node type.
793It is the only "generic" message
794that requires any support within the node itself and as such the node may
795elect to not support this message. The text response must be less than
796.Dv NG_TEXTRESPONSE
797bytes in length (presently 1024). This can be used to return general
798status information in human readable form.
799.It Dv NGM_BINARY2ASCII
800This message converts a binary control message to its
801.Tn ASCII
802form.
803The entire control message to be converted is contained within the
804arguments field of the
805.Dv Dv NGM_BINARY2ASCII
806message itself. If successful, the reply will contain the same control
807message in
808.Tn ASCII
809form.
810A node will typically only know how to translate messages that it
811itself understands, so the target node of the
812.Dv NGM_BINARY2ASCII
813is often the same node that would actually receive that message.
814.It Dv NGM_ASCII2BINARY
815The opposite of
816.Dv NGM_BINARY2ASCII .
817The entire control message to be converted, in
818.Tn ASCII
819form, is contained
820in the arguments section of the
821.Dv NGM_ASCII2BINARY
822and need only have the
823.Dv flags ,
824.Dv cmdstr ,
825and
826.Dv arglen
827header fields filled in, plus the NUL-terminated string version of
828the arguments in the arguments field. If successful, the reply
829contains the binary version of the control message.
830.El
831.Sh Metadata
832Data moving through the
833.Nm
834system can be accompanied by meta-data that describes some
835aspect of that data. The form of the meta-data is a fixed header,
836which contains enough information for most uses, and can optionally
837be supplemented by trailing
838.Em option
839structures, which contain a
840.Em cookie
841(see the section on control messages), an identifier, a length and optional
842data. If a node does not recognize the cookie associated with an option,
843it should ignore that option.
844.Pp
845Meta data might include such things as priority, discard eligibility,
846or special processing requirements. It might also mark a packet for
847debug status, etc. The use of meta-data is still experimental.
848.Sh INITIALIZATION
849The base
850.Nm
851code may either be statically compiled
852into the kernel or else loaded dynamically as a KLD via
853.Xr kldload 8 .
854In the former case, include
855.Bd -literal -offset 4n -compact
856
857 options NETGRAPH
858
859.Ed
860in your kernel configuration file. You may also include selected
861node types in the kernel compilation, for example:
862.Bd -literal -offset 4n -compact
863
864 options NETGRAPH
865 options NETGRAPH_SOCKET
866 options NETGRAPH_ECHO
867
868.Ed
869.Pp
870Once the
871.Nm
872subsystem is loaded, individual node types may be loaded at any time
873as KLD modules via
874.Xr kldload 8 .
875Moreover,
876.Nm
877knows how to automatically do this; when a request to create a new
878node of unknown type
879.Em type
880is made,
881.Nm
882will attempt to load the KLD module
883.Pa ng_type.ko .
884.Pp
885Types can also be installed at boot time, as certain device drivers
886may want to export each instance of the device as a netgraph node.
887.Pp
888In general, new types can be installed at any time from within the
889kernel by calling
890.Fn ng_newtype ,
891supplying a pointer to the type's
892.Dv struct ng_type
893structure.
894.Pp
895The
896.Fn NETGRAPH_INIT
897macro automates this process by using a linker set.
898.Sh EXISTING NODE TYPES
899Several node types currently exist. Each is fully documented
900in its own man page:
901.Bl -tag -width xxx
902.It SOCKET
903The socket type implements two new sockets in the new protocol domain
904.Dv PF_NETGRAPH .
905The new sockets protocols are
906.Dv NG_DATA
907and
908.Dv NG_CONTROL ,
909both of type
910.Dv SOCK_DGRAM .
911Typically one of each is associated with a socket node.
912When both sockets have closed, the node will shut down. The
913.Dv NG_DATA
914socket is used for sending and receiving data, while the
915.Dv NG_CONTROL
916socket is used for sending and receiving control messages.
917Data and control messages are passed using the
918.Xr sendto 2
919and
920.Xr recvfrom 2
921calls, using a
922.Dv struct sockaddr_ng
923socket address.
924.Pp
925.It HOLE
926Responds only to generic messages and is a
927.Dq black hole
928for data, Useful for testing. Always accepts new hooks.
929.Pp
930.It ECHO
931Responds only to generic messages and always echoes data back through the
932hook from which it arrived. Returns any non generic messages as their
933own response. Useful for testing. Always accepts new hooks.
934.Pp
935.It TEE
936This node is useful for
937.Dq snooping .
938It has 4 hooks:
939.Dv left ,
940.Dv right ,
941.Dv left2right ,
942and
943.Dv right2left .
944Data entering from the right is passed to the left and duplicated on
945.Dv right2left,
946and data entering from the left is passed to the right and
947duplicated on
948.Dv left2right .
949Data entering from
950.Dv left2right
951is sent to the right and data from
952.Dv right2left
953to left.
954.Pp
955.It RFC1490 MUX
956Encapsulates/de-encapsulates frames encoded according to RFC 1490.
957Has a hook for the encapsulated packets
958.Pq Dq downstream
959and one hook
960for each protocol (i.e., IP, PPP, etc.).
961.Pp
962.It FRAME RELAY MUX
963Encapsulates/de-encapsulates Frame Relay frames.
964Has a hook for the encapsulated packets
965.Pq Dq downstream
966and one hook
967for each DLCI.
968.Pp
969.It FRAME RELAY LMI
970Automatically handles frame relay
971.Dq LMI
972(link management interface) operations and packets.
973Automatically probes and detects which of several LMI standards
974is in use at the exchange.
975.Pp
976.It TTY
977This node is also a line discipline. It simply converts between mbuf
978frames and sequential serial data, allowing a tty to appear as a netgraph
979node. It has a programmable
980.Dq hotkey
981character.
982.Pp
983.It ASYNC
984This node encapsulates and de-encapsulates asynchronous frames
985according to RFC 1662. This is used in conjunction with the TTY node
986type for supporting PPP links over asynchronous serial lines.
987.Pp
988.It INTERFACE
989This node is also a system networking interface. It has hooks representing
990each protocol family (IP, AppleTalk, IPX, etc.) and appears in the output of
991.Xr ifconfig 8 .
992The interfaces are named
993.Em ng0 ,
994.Em ng1 ,
995etc.
996.El
997.Sh NOTES
998Whether a named node exists can be checked by trying to send a control message
999to it (e.g.,
1000.Dv NGM_NODEINFO
1001).
1002If it does not exist,
1003.Er ENOENT
1004will be returned.
1005.Pp
1006All data messages are mbuf chains with the M_PKTHDR flag set.
1007.Pp
1008Nodes are responsible for freeing what they allocate.
1009There are three exceptions:
1010.Bl -tag -width xxxx
1011.It 1
1012Mbufs sent across a data link are never to be freed by the sender,
1013unless it is returned from the recipient.
1014.It 2
1015Any meta-data information traveling with the data has the same restriction.
1016It might be freed by any node the data passes through, and a
1017.Dv NULL
1018passed onwards, but the caller will never free it.
1019Two macros
1020.Fn NG_FREE_META "meta"
1021and
1022.Fn NG_FREE_DATA "m" "meta"
1023should be used if possible to free data and meta data (see
1024.Pa netgraph.h ) .
1025.It 3
1026Messages sent using
1027.Fn ng_send_message
1028are freed by the recipient. As in the case above, the addresses
1029associated with the message are freed by whatever allocated them so the
1030recipient should copy them if it wants to keep that information.
1031.El
1032.Sh FILES
1033.Bl -tag -width xxxxx -compact
1034.It Pa /sys/netgraph/netgraph.h
1035Definitions for use solely within the kernel by
1036.Nm
1037nodes.
1038.It Pa /sys/netgraph/ng_message.h
1039Definitions needed by any file that needs to deal with
1040.Nm
1041messages.
1042.It Pa /sys/netgraph/ng_socket.h
1043Definitions needed to use
1044.Nm
1045socket type nodes.
1046.It Pa /sys/netgraph/ng_{type}.h
1047Definitions needed to use
1048.Nm
1049{type}
1050nodes, including the type cookie definition.
1051.It Pa /modules/netgraph.ko
1052Netgraph subsystem loadable KLD module.
1053.It Pa /modules/ng_{type}.ko
1054Loadable KLD module for node type {type}.
1055.El
1056.Sh USER MODE SUPPORT
1057There is a library for supporting user-mode programs that wish
1058to interact with the netgraph system. See
1059.Xr netgraph 3
1060for details.
1061.Pp
1062Two user-mode support programs,
1063.Xr ngctl 8
1064and
1065.Xr nghook 8 ,
1066are available to assist manual configuration and debugging.
1067.Pp
1068There are a few useful techniques for debugging new node types.
1069First, implementing new node types in user-mode first
1070makes debugging easier.
1071The
1072.Em tee
1073node type is also useful for debugging, especially in conjunction with
1074.Xr ngctl 8
1075and
1076.Xr nghook 8 .
1077.Sh SEE ALSO
1078.Xr socket 2 ,
1079.Xr netgraph 3 ,
1080.Xr ng_async 4 ,
1081.Xr ng_bpf 4 ,
1082.Xr ng_cisco 4 ,
1083.Xr ng_ether 4 ,
1084.Xr ng_echo 4 ,
1085.Xr ng_frame_relay 4 ,
1086.Xr ng_hole 4 ,
1087.Xr ng_iface 4 ,
1088.Xr ng_ksocket 4 ,
1089.Xr ng_lmi 4 ,
1090.Xr ng_mppc 4 ,
1091.Xr ng_ppp 4 ,
1092.Xr ng_pppoe 4 ,
1093.Xr ng_rfc1490 4 ,
1094.Xr ng_socket 4 ,
1095.Xr ng_tee 4 ,
1096.Xr ng_tty 4 ,
1097.Xr ng_UI 4 ,
1098.Xr ng_vjc 4 ,
1099.Xr ng_{type} 4 ,
1100.Xr ngctl 8 ,
1101.Xr nghook 8
1102.Sh HISTORY
1103The
1104.Nm
1105system was designed and first implemented at Whistle Communications, Inc.
1106in a version of
1107.Fx 2.2
1108customized for the Whistle InterJet.
1109It first made its debut in the main tree in
1110.Fx 3.4 .
1111.Sh AUTHORS
1112.An -nosplit
1113.An Julian Elischer Aq julian@FreeBSD.org ,
1114with contributions by
1115.An Archie Cobbs Aq archie@FreeBSD.org .