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