path: root/static/freebsd/man4/ng_l2cap.4 3.html

<table class="head">
  <tr>
    <td class="head-ltitle">NG_L2CAP(4)</td>
    <td class="head-vol">Device Drivers Manual</td>
    <td class="head-rtitle">NG_L2CAP(4)</td>
  </tr>
</table>
<div class="manual-text">
<section class="Sh">
<h1 class="Sh" id="NAME"><a class="permalink" href="#NAME">NAME</a></h1>
<p class="Pp"><code class="Nm">ng_l2cap</code> &#x2014;
    <span class="Nd">Netgraph node type that implements Bluetooth Logical Link
    Control and Adaptation Protocol (L2CAP)</span></p>
</section>
<section class="Sh">
<h1 class="Sh" id="SYNOPSIS"><a class="permalink" href="#SYNOPSIS">SYNOPSIS</a></h1>
<p class="Pp"><code class="In">#include
    &lt;<a class="In">sys/types.h</a>&gt;</code>
  <br/>
  <code class="In">#include
    &lt;<a class="In">netgraph/bluetooth/include/ng_hci.h</a>&gt;</code>
  <br/>
  <code class="In">#include
    &lt;<a class="In">netgraph/bluetooth/include/ng_l2cap.h</a>&gt;</code></p>
</section>
<section class="Sh">
<h1 class="Sh" id="DESCRIPTION"><a class="permalink" href="#DESCRIPTION">DESCRIPTION</a></h1>
<p class="Pp">The <code class="Nm">l2cap</code> node type is a Netgraph node
    type that implements Bluetooth Logical Link Control and Adaptation Protocol
    as per chapter D of the Bluetooth Specification Book v1.1.</p>
<p class="Pp">L2CAP provides connection-oriented and connectionless data
    services to upper layer protocols with protocol multiplexing capability,
    segmentation and reassembly operation, and group abstractions. L2CAP permits
    higher level protocols and applications to transmit and receive L2CAP data
    packets up to 64 kilobytes in length.</p>
<section class="Ss">
<h2 class="Ss" id="L2CAP_Assumptions"><a class="permalink" href="#L2CAP_Assumptions">L2CAP
  Assumptions</a></h2>
<ol class="Bl-enum Bd-indent">
  <li>The ACL link between two units is set up. The Baseband provides orderly
      delivery of data packets, although there might be individual packet
      corruption and duplicates. No more than one ACL link exists between any
      two devices.</li>
  <li>The Baseband always provides the impression of full-duplex communication
      channels. This does not imply that all L2CAP communications are
      bi-directional. Multicasts and unidirectional traffic (e.g., video) do not
      require duplex channels.</li>
  <li>L2CAP provides a reliable channel using the mechanisms available at the
      Baseband layer. The Baseband always performs data integrity checks when
      requested and resends data until it has been successfully acknowledged or
      a timeout occurs. As acknowledgements may be lost, timeouts may occur even
      after the data has been successfully sent.</li>
</ol>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="L2CAP_GENERAL_OPERATION"><a class="permalink" href="#L2CAP_GENERAL_OPERATION">L2CAP
  GENERAL OPERATION</a></h1>
<p class="Pp">The Logical Link Control and Adaptation Protocol (L2CAP) is based
    around the concept of &#x201C;channels&#x201D;. Each channel is bound to a
    single protocol in a many-to-one fashion. Multiple channels can be bound to
    the same protocol, but a channel cannot be bound to multiple protocols. Each
    L2CAP packet received on a channel is directed to the appropriate higher
    level protocol.</p>
<p class="Pp">Each one of the end-points of an L2CAP channel is referred to by a
    channel identifier. Channel identifiers (CIDs) are local names representing
    a logical channel end-point on the device. Identifiers from 0x0001 to 0x003F
    are reserved for specific L2CAP functions. The null identifier (0x0000) is
    defined as an illegal identifier and must never be used as a destination
    end-point. All L2CAP signalling commands are sent to CID 0x0001. CID 0x0002
    is reserved for group-oriented channel. The same CID must not be reused as a
    local L2CAP channel endpoint for multiple simultaneous L2CAP channels
    between a local device and some remote device.</p>
<p class="Pp">CID assignment is relative to a particular device and a device can
    assign CIDs independently from other devices. Thus, even if the same CID
    value has been assigned to (remote) channel endpoints by several remote
    devices connected to a single local device, the local device can still
    uniquely associate each remote CID with a different device.</p>
<section class="Ss">
<h2 class="Ss" id="Channel_Operational_States"><a class="permalink" href="#Channel_Operational_States">Channel
  Operational States</a></h2>
<dl class="Bl-tag">
  <dt id="NG_L2CAP_CLOSED"><a class="permalink" href="#NG_L2CAP_CLOSED"><code class="Dv">NG_L2CAP_CLOSED</code></a></dt>
  <dd>In this state, there is no channel associated with this CID. This is the
      only state when a link level connection (Baseband) may not exist. Link
      disconnection forces all other states into the
      <code class="Dv">NG_L2CAP_CLOSED</code> state.</dd>
  <dt id="NG_L2CAP_W4_L2CAP_CON_RSP"><a class="permalink" href="#NG_L2CAP_W4_L2CAP_CON_RSP"><code class="Dv">NG_L2CAP_W4_L2CAP_CON_RSP</code></a></dt>
  <dd>In this state, the CID represents a local end-point and an L2CAP Connect
      Request message has been sent referencing this endpoint and it is now
      waiting for the corresponding L2CAP Connect Response message.</dd>
  <dt id="NG_L2CAP_W4_L2CA_CON_RSP"><a class="permalink" href="#NG_L2CAP_W4_L2CA_CON_RSP"><code class="Dv">NG_L2CAP_W4_L2CA_CON_RSP</code></a></dt>
  <dd>In this state, the remote end-point exists and an L2CAP Connect Request
      has been received by the local L2CAP entity. An L2CA Connect Indication
      has been sent to the upper layer and the part of the local L2CAP entity
      processing the received L2CAP Connect Request waits for the corresponding
      response. The response may require a security check to be performed.</dd>
  <dt id="NG_L2CAP_CONFIG"><a class="permalink" href="#NG_L2CAP_CONFIG"><code class="Dv">NG_L2CAP_CONFIG</code></a></dt>
  <dd>In this state, the connection has been established but both sides are
      still negotiating the channel parameters. The Configuration state may also
      be entered when the channel parameters are being renegotiated. Prior to
      entering the <code class="Dv">NG_L2CAP_CONFIG</code> state, all outgoing
      data traffic is suspended since the traffic parameters of the data traffic
      are to be renegotiated. Incoming data traffic is accepted until the remote
      channel endpoint has entered the <code class="Dv">NG_L2CAP_CONFIG</code>
      state. In the <code class="Dv">NG_L2CAP_CONFIG</code> state, both sides
      will issue L2CAP Configuration Request messages if only defaults are being
      used, a null message will be sent. If a large amount of parameters need to
      be negotiated, multiple messages will be sent to avoid any MTU limitations
      and negotiate incrementally. Moving from the
      <code class="Dv">NG_L2CAP_CONFIG</code> state to the
      <code class="Dv">NG_L2CAP_OPEN</code> state requires both sides to be
      ready. An L2CAP entity is ready when it has received a positive response
      to its final request and it has positively responded to the final request
      from the remote device.</dd>
  <dt id="NG_L2CAP_OPEN"><a class="permalink" href="#NG_L2CAP_OPEN"><code class="Dv">NG_L2CAP_OPEN</code></a></dt>
  <dd>In this state, the connection has been established and configured, and
      data flow may proceed.</dd>
  <dt id="NG_L2CAP_W4_L2CAP_DISCON_RSP"><a class="permalink" href="#NG_L2CAP_W4_L2CAP_DISCON_RSP"><code class="Dv">NG_L2CAP_W4_L2CAP_DISCON_RSP</code></a></dt>
  <dd>In this state, the connection is shutting down and an L2CAP Disconnect
      Request message has been sent. This state is now waiting for the
      corresponding response.</dd>
  <dt id="NG_L2CAP_W4_L2CA_DISCON_RSP"><a class="permalink" href="#NG_L2CAP_W4_L2CA_DISCON_RSP"><code class="Dv">NG_L2CAP_W4_L2CA_DISCON_RSP</code></a></dt>
  <dd>In this state, the connection on the remote endpoint is shutting down and
      an L2CAP Disconnect Request message has been received. An L2CA Disconnect
      Indication has been sent to the upper layer to notify the owner of the CID
      that the remote endpoint is being closed. This state is now waiting for
      the corresponding response from the upper layer before responding to the
      remote endpoint.</dd>
</dl>
</section>
<section class="Ss">
<h2 class="Ss" id="Protocol_Multiplexing"><a class="permalink" href="#Protocol_Multiplexing">Protocol
  Multiplexing</a></h2>
<p class="Pp">L2CAP supports protocol multiplexing because the Baseband Protocol
    does not support any &#x201C;type&#x201D; field identifying the higher layer
    protocol being multiplexed above it. L2CAP is able to distinguish between
    upper layer protocols such as the Service Discovery Protocol, RFCOMM and
    Telephony Control.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Segmentation_and_Reassembly"><a class="permalink" href="#Segmentation_and_Reassembly">Segmentation
  and Reassembly</a></h2>
<p class="Pp">The data packets defined by the Baseband Protocol are limited in
    size. Large L2CAP packets must be segmented into multiple smaller Baseband
    packets prior to their transmission over the air. Similarly, multiple
    received Baseband packets may be reassembled into a single larger L2CAP
    packet.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Quality_of_Service"><a class="permalink" href="#Quality_of_Service">Quality
  of Service</a></h2>
<p class="Pp">The L2CAP connection establishment process allows the exchange of
    information regarding the quality of service (QoS) expected between two
    Bluetooth units.</p>
</section>
<section class="Ss">
<h2 class="Ss" id="Groups"><a class="permalink" href="#Groups">Groups</a></h2>
<p class="Pp">The Baseband Protocol supports the concept of a piconet, a group
    of devices synchronously hopping together using the same clock. The L2CAP
    group abstraction permits implementations to efficiently map protocol groups
    on to piconets.</p>
<p class="Pp">The following features are outside the scope of L2CAP
    responsibilities:</p>
<ul class="Bl-dash Bd-indent">
  <li>L2CAP does not transport audio designated for SCO links.</li>
  <li>L2CAP does not enforce a reliable channel or ensure data integrity, that
      is, L2CAP performs no retransmissions or checksum calculations.</li>
  <li>L2CAP does not support a reliable multicast channel.</li>
  <li>L2CAP does not support the concept of a global group name.</li>
</ul>
</section>
</section>
<section class="Sh">
<h1 class="Sh" id="HOOKS"><a class="permalink" href="#HOOKS">HOOKS</a></h1>
<p class="Pp">This node type supports the following hooks:</p>
<dl class="Bl-tag">
  <dt id="hci"><var class="Va">hci</var></dt>
  <dd>Bluetooth Host Controller Interface downstream hook.</dd>
  <dt id="l2c"><var class="Va">l2c</var></dt>
  <dd>Upper layer protocol upstream hook. Usually the Bluetooth L2CAP socket
      layer is connected to the hook.</dd>
  <dt id="ctl"><var class="Va">ctl</var></dt>
  <dd>Control hook. Usually the Bluetooth raw L2CAP sockets layer is connected
      to the hook.</dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="INTERFACE_TO_THE_UPPER_LAYER_PROTOCOLS_(L2CA_CONTROL_MESSAGES)"><a class="permalink" href="#INTERFACE_TO_THE_UPPER_LAYER_PROTOCOLS_(L2CA_CONTROL_MESSAGES)">INTERFACE
  TO THE UPPER LAYER PROTOCOLS (L2CA CONTROL MESSAGES)</a></h1>
<p class="Pp">Bluetooth specification says that L2CA request must block until
    response is ready. L2CAP node uses <var class="Va">token</var> field from
    Netgraph message header to match L2CA request and response. The upper layer
    protocol must populate <var class="Va">token</var>. L2CAP node will queue
    request and start processing. Later, when response is ready or timeout has
    occurred, L2CAP node will create new Netgraph message, set
    <var class="Va">token</var> and <code class="Dv">NFG_RESP</code> flag and
    send message to the upper layer. Note that L2CA indication messages will not
    populate <var class="Va">token</var> and will not set
    <code class="Dv">NGF_RESP</code> flag. There is no reason for this, because
    they are just notifications and do not require acknowledgment.</p>
<dl class="Bl-tag">
  <dt id="NGM_L2CAP_L2CA_CON"><a class="permalink" href="#NGM_L2CAP_L2CA_CON"><code class="Dv">NGM_L2CAP_L2CA_CON</code></a></dt>
  <dd>Requests the creation of a channel representing a logical connection to a
      physical address. Input parameters are the target protocol (PSM) and
      remote device's 48-bit address (BD_ADDR). Output parameters are the local
      CID (LCID) allocated by the local L2CAP entity, and Result of the request.
      If Result indicates a pending notification, the Status value may contain
      more information of what processing is delaying the establishment of the
      connection.</dd>
  <dt id="NGM_L2CAP_L2CA_CON_IND"><a class="permalink" href="#NGM_L2CAP_L2CA_CON_IND"><code class="Dv">NGM_L2CAP_L2CA_CON_IND</code></a></dt>
  <dd>This message includes the parameters for the address of the remote device
      that issued the connection request, the local CID representing the channel
      being requested, the Identifier contained in the request, and the PSM
      value the request is targeting.</dd>
  <dt id="NGM_L2CAP_L2CA_CON_RSP"><a class="permalink" href="#NGM_L2CAP_L2CA_CON_RSP"><code class="Dv">NGM_L2CAP_L2CA_CON_RSP</code></a></dt>
  <dd>Issues a response to a connection request event indication. Input
      parameters are the remote device's 48-bit address, Identifier sent in the
      request, local CID, the Response code, and the Status attached to the
      Response code. The output parameter is the Result of the service request.
      This primitive must be called no more than once after receiving the
      indication.</dd>
  <dt id="NGM_L2CAP_L2CA_CFG"><a class="permalink" href="#NGM_L2CAP_L2CA_CFG"><code class="Dv">NGM_L2CAP_L2CA_CFG</code></a></dt>
  <dd>Requests the initial configuration (or reconfiguration) of a channel to a
      new set of channel parameters. Input parameters are the local CID
      endpoint, new incoming receivable MTU (InMTU), new outgoing flow
      spec-ification, and flush and link timeouts. Output parameters are the
      Result, accepted incoming MTU (InMTU), the remote side's flow requests,
      and flush and link timeouts.</dd>
  <dt id="NGM_L2CAP_L2CA_CFG_IND"><a class="permalink" href="#NGM_L2CAP_L2CA_CFG_IND"><code class="Dv">NGM_L2CAP_L2CA_CFG_IND</code></a></dt>
  <dd>This message includes the parameters indicating the local CID of the
      channel the request has been sent to, the outgoing MTU size (maximum
      packet that can be sent across the channel) and the flowspec describing
      the characteristics of the incoming data. All other channel parameters are
      set to their default values if not provided by the remote device.</dd>
  <dt id="NGM_L2CAP_L2CA_CFG_RSP"><a class="permalink" href="#NGM_L2CAP_L2CA_CFG_RSP"><code class="Dv">NGM_L2CAP_L2CA_CFG_RSP</code></a></dt>
  <dd>Issues a response to a configuration request event indication. Input
      parameters include the local CID of the endpoint being configured,
      outgoing transmit MTU (which may be equal or less to the OutMTU parameter
      in the configuration indication event) and the accepted flowspec for
      incoming traffic. The output parameter is the Result value.</dd>
  <dt id="NGM_L2CAP_L2CA_QOS_IND"><a class="permalink" href="#NGM_L2CAP_L2CA_QOS_IND"><code class="Dv">NGM_L2CAP_L2CA_QOS_IND</code></a></dt>
  <dd>This message includes the parameter indicating the address of the remote
      Bluetooth device where the QoS contract has been violated.</dd>
  <dt id="NGM_L2CAP_L2CA_DISCON"><a class="permalink" href="#NGM_L2CAP_L2CA_DISCON"><code class="Dv">NGM_L2CAP_L2CA_DISCON</code></a></dt>
  <dd>Requests the disconnection of the channel. Input parameter is the CID
      representing the local channel endpoint. Output parameter is Result.
      Result is zero if an L2CAP Disconnect Response is received, otherwise a
      non-zero value is returned. Once disconnection has been requested, no
      process will be able to successfully read or write from the CID.</dd>
  <dt id="NGM_L2CAP_L2CA_DISCON_IND"><a class="permalink" href="#NGM_L2CAP_L2CA_DISCON_IND"><code class="Dv">NGM_L2CAP_L2CA_DISCON_IND</code></a></dt>
  <dd>This message includes the parameter indicating the local CID the request
      has been sent to.</dd>
  <dt id="NGM_L2CAP_L2CA_WRITE"><a class="permalink" href="#NGM_L2CAP_L2CA_WRITE"><code class="Dv">NGM_L2CAP_L2CA_WRITE</code></a></dt>
  <dd>Response to transfer of data request. Actual data must be received from
      appropriate upstream hook and must be prepended with header defined as
      follows.
    <div class="Bd Pp Bd-indent Li">
    <pre>/* L2CA data packet header */
typedef struct {
        uint32_t token;  /* token to use in L2CAP_L2CA_WRITE */
        uint16_t length; /* length of the data */
        uint16_t lcid;   /* local channel ID */
} __attribute__ ((packed)) ng_l2cap_l2ca_hdr_t;</pre>
    </div>
    <p class="Pp">The output parameters are Result and Length of data
      written.</p>
  </dd>
  <dt id="NGM_L2CAP_L2CA_GRP_CREATE"><a class="permalink" href="#NGM_L2CAP_L2CA_GRP_CREATE"><code class="Dv">NGM_L2CAP_L2CA_GRP_CREATE</code></a></dt>
  <dd>Requests the creation of a CID to represent a logical connection to
      multiple devices. Input parameter is the PSM value that the outgoing
      connectionless traffic is labelled with, and the filter used for incoming
      traffic. Output parameter is the CID representing the local endpoint. On
      creation, the group is empty but incoming traffic destined for the PSM
      value is readable.
    <div class="Bf Em">This request has not been implemented.</div>
  </dd>
  <dt id="NGM_L2CAP_L2CA_GRP_CLOSE"><a class="permalink" href="#NGM_L2CAP_L2CA_GRP_CLOSE"><code class="Dv">NGM_L2CAP_L2CA_GRP_CLOSE</code></a></dt>
  <dd>The use of this message closes down a Group.
    <div class="Bf Em">This request has not been implemented.</div>
  </dd>
  <dt id="NGM_L2CAP_L2CA_GRP_ADD_MEMBER"><a class="permalink" href="#NGM_L2CAP_L2CA_GRP_ADD_MEMBER"><code class="Dv">NGM_L2CAP_L2CA_GRP_ADD_MEMBER</code></a></dt>
  <dd>Requests the addition of a member to a group. The input parameter includes
      the CID representing the group and the BD_ADDR of the group member to be
      added. The output parameter Result confirms the success or failure of the
      request.
    <div class="Bf Em">This request has not been implemented.</div>
  </dd>
  <dt id="NGM_L2CAP_L2CA_GRP_REM_MEMBER"><a class="permalink" href="#NGM_L2CAP_L2CA_GRP_REM_MEMBER"><code class="Dv">NGM_L2CAP_L2CA_GRP_REM_MEMBER</code></a></dt>
  <dd>Requests the removal of a member from a group. The input parameters
      include the CID representing the group and BD_ADDR of the group member to
      be removed. The output parameter Result confirms the success or failure of
      the request.
    <div class="Bf Em">This request has not been implemented.</div>
  </dd>
  <dt id="NGM_L2CAP_L2CA_GRP_MEMBERSHIP"><a class="permalink" href="#NGM_L2CAP_L2CA_GRP_MEMBERSHIP"><code class="Dv">NGM_L2CAP_L2CA_GRP_MEMBERSHIP</code></a></dt>
  <dd>Requests a report of the members of a group. The input parameter CID
      represents the group being queried. The output parameter Result confirms
      the success or failure of the operation. If the Result is successful,
      BD_ADDR_Lst is a list of the Bluetooth addresses of the N members of the
      group.
    <div class="Bf Em">This request has not been implemented.</div>
  </dd>
  <dt id="NGM_L2CAP_L2CA_PING"><a class="permalink" href="#NGM_L2CAP_L2CA_PING"><code class="Dv">NGM_L2CAP_L2CA_PING</code></a></dt>
  <dd>Initiates an L2CA Echo Request message and the reception of the
      corresponding L2CAP Echo Response message. The input parameters are remote
      Bluetooth device BD_ADDR, Echo Data and Length of the echo data. The
      output parameters are Result, Echo Data and Length of the echo data.</dd>
  <dt id="NGM_L2CAP_L2CA_GET_INFO"><a class="permalink" href="#NGM_L2CAP_L2CA_GET_INFO"><code class="Dv">NGM_L2CAP_L2CA_GET_INFO</code></a></dt>
  <dd>Initiates an L2CA Information Request message and the reception of the
      corresponding L2CAP Info Response message. The input parameters are remote
      Bluetooth device BD_ADDR and Information Type. The output parameters are
      Result, Information Data and Size of the information data.</dd>
  <dt id="NGM_L2CAP_L2CA_ENABLE_CLT"><a class="permalink" href="#NGM_L2CAP_L2CA_ENABLE_CLT"><code class="Dv">NGM_L2CAP_L2CA_ENABLE_CLT</code></a></dt>
  <dd>Request to disable (enable) the reception of connectionless packets. The
      input parameter is the PSM value indicating service that should be blocked
      (unblocked) and Enable flag.</dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="NETGRAPH_CONTROL_MESSAGES"><a class="permalink" href="#NETGRAPH_CONTROL_MESSAGES">NETGRAPH
  CONTROL MESSAGES</a></h1>
<p class="Pp">This node type supports the generic control messages, plus the
    following:</p>
<dl class="Bl-tag">
  <dt id="NGM_L2CAP_NODE_GET_FLAGS"><a class="permalink" href="#NGM_L2CAP_NODE_GET_FLAGS"><code class="Dv">NGM_L2CAP_NODE_GET_FLAGS</code></a></dt>
  <dd>Returns current state for the node.</dd>
  <dt id="NGM_L2CAP_NODE_GET_DEBUG"><a class="permalink" href="#NGM_L2CAP_NODE_GET_DEBUG"><code class="Dv">NGM_L2CAP_NODE_GET_DEBUG</code></a></dt>
  <dd>Returns an integer containing the current debug level for the node.</dd>
  <dt id="NGM_L2CAP_NODE_SET_DEBUG"><a class="permalink" href="#NGM_L2CAP_NODE_SET_DEBUG"><code class="Dv">NGM_L2CAP_NODE_SET_DEBUG</code></a></dt>
  <dd>This command takes an integer argument and sets current debug level for
      the node.</dd>
  <dt id="NGM_L2CAP_NODE_GET_CON_LIST"><a class="permalink" href="#NGM_L2CAP_NODE_GET_CON_LIST"><code class="Dv">NGM_L2CAP_NODE_GET_CON_LIST</code></a></dt>
  <dd>Returns list of active baseband connections (i.e., ACL links).</dd>
  <dt id="NGM_L2CAP_NODE_GET_CHAN_LIST"><a class="permalink" href="#NGM_L2CAP_NODE_GET_CHAN_LIST"><code class="Dv">NGM_L2CAP_NODE_GET_CHAN_LIST</code></a></dt>
  <dd>Returns list of active L2CAP channels.</dd>
  <dt id="NGM_L2CAP_NODE_GET_AUTO_DISCON_TIMO"><a class="permalink" href="#NGM_L2CAP_NODE_GET_AUTO_DISCON_TIMO"><code class="Dv">NGM_L2CAP_NODE_GET_AUTO_DISCON_TIMO</code></a></dt>
  <dd>Returns an integer containing the current value of the auto disconnect
      timeout (in sec).</dd>
  <dt id="NGM_L2CAP_NODE_SET_AUTO_DISCON_TIMO"><a class="permalink" href="#NGM_L2CAP_NODE_SET_AUTO_DISCON_TIMO"><code class="Dv">NGM_L2CAP_NODE_SET_AUTO_DISCON_TIMO</code></a></dt>
  <dd>This command accepts an integer and sets the value of the auto disconnect
      timeout (in sec). The special value of 0 (zero) disables auto disconnect
      timeout.</dd>
</dl>
</section>
<section class="Sh">
<h1 class="Sh" id="SHUTDOWN"><a class="permalink" href="#SHUTDOWN">SHUTDOWN</a></h1>
<p class="Pp">This node shuts down upon receipt of an
    <code class="Dv">NGM_SHUTDOWN</code> control message, or when all hooks have
    been disconnected.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="SEE_ALSO"><a class="permalink" href="#SEE_ALSO">SEE
  ALSO</a></h1>
<p class="Pp"><a class="Xr">netgraph(4)</a>, <a class="Xr">l2control(8)</a>,
    <a class="Xr">l2ping(8)</a>, <a class="Xr">ngctl(8)</a></p>
</section>
<section class="Sh">
<h1 class="Sh" id="HISTORY"><a class="permalink" href="#HISTORY">HISTORY</a></h1>
<p class="Pp">The <code class="Nm">l2cap</code> node type was implemented in
    <span class="Ux">FreeBSD 5.0</span>.</p>
</section>
<section class="Sh">
<h1 class="Sh" id="AUTHORS"><a class="permalink" href="#AUTHORS">AUTHORS</a></h1>
<p class="Pp"><span class="An">Maksim Yevmenkin</span>
    &lt;<a class="Mt" href="mailto:m_evmenkin@yahoo.com">m_evmenkin@yahoo.com</a>&gt;</p>
</section>
<section class="Sh">
<h1 class="Sh" id="BUGS"><a class="permalink" href="#BUGS">BUGS</a></h1>
<p class="Pp">Most likely. Please report if found.</p>
</section>
</div>
<table class="foot">
  <tr>
    <td class="foot-date">July 4, 2002</td>
    <td class="foot-os">FreeBSD 15.0</td>
  </tr>
</table>