mdoc(7) police: markup overhaul.

svn path=/head/; revision=107823
2024-09-20 08:44:33 +00:00 · 2002-12-13 10:38:42 +00:00 · 2002-12-13 10:38:42 +00:00 · f393f49865 · 2020-12-20 02:59:44 +00:00
parent e3e797439e
commit f393f49865
7 changed files with 663 additions and 509 deletions
--- a/share/man/man4/ng_bluetooth.4
+++ b/share/man/man4/ng_bluetooth.4
@ -1,8 +1,6 @@
 .\" ng_bluetooth.4
 .\" 
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
-.\" 
+.\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
@ -11,7 +9,7 @@
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
-.\" 
+.\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@ -23,86 +21,97 @@
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
-.\" 
+.\"
 .\" $Id: ng_bluetooth.4,v 1.2 2002/11/12 22:14:10 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd November 9, 2002
 .Dt NG_BLUETOOTH 4
 .Os
 .Sh NAME
-.Nm bluetooth
+.Nm ng_bluetooth
 .Nd placeholder for global Bluetooth variables
 .Sh SYNOPSIS
 .In sys/types.h
 .In ng_bluetooth.h
 .Sh DESCRIPTION
 The
-.Nm 
+.Nm
-module is a placeholder for global Bluetooth variables. All Bluetooth
+module is a placeholder for global Bluetooth variables.
-variables can be examined and changed via
+All Bluetooth variables can be examined and changed via
 .Xr sysctl 8 .
-.Sh BLUETOOTH VARIABLES
+.Ss Bluetooth Variables
-Below is the description of default variables. Each Bluetooth module
+Below is the description of default variables.
-might add its own variables to the tree.
+Each Bluetooth module might add its own variables to the tree.
-.Bl -tag -width foobar
+.Bl -tag -width indent
-.It net.bluetooth.version
+.It Va net.bluetooth.version
-A read only integer variable that shows the current version of the 
+A read-only integer variable that shows the current version of the
 Bluetooth stack.
-.It net.bluetooth.hci.command_timeout
+.It Va net.bluetooth.hci.command_timeout
 A read-write interger variable that controls the Host Controller Interface
-(HCI) command timeout (in seconds), i.e. how long the HCI layer will wait 
+(HCI) command timeout (in seconds), i.e. how long the HCI layer will wait
 for the
 .Dv Command_Complete
 or
 .Dv Command_Status
 event from a Bluetooth device.
-.It net.bluetooth.hci.connection_timeout
+.It Va net.bluetooth.hci.connection_timeout
-A read-write integer variable that controls the HCI connection timeout, i.e.
+A read-write integer variable that controls the HCI connection timeout, i.e.\&
-how long the HCI layer will wait for the 
+how long the HCI layer will wait for the
 .Dv Connection_Complete
-event. Normaly this should not be required as Bluetooth devices have
+event.
-connection timeout of their own and will send event back. This timeout 
+Normaly this should not be required as Bluetooth devices have
-is required to ensure that no connection will stall in case when the HCI 
+connection timeout of their own and will send event back.
-transport layer is broken. Be careful when changing this variable. 
+This timeout
 is required to ensure that no connection will stall in case when the HCI
 transport layer is broken.
 Be careful when changing this variable.
 Make sure you understand what you are doing.
-.It net.bluetooth.hci.watchdog_timeout
+.It Va net.bluetooth.hci.watchdog_timeout
 A read-write integer variable that controls the HCI connection watchdog
-timeout in seconds), i.e. how long the HCI layer should wait before 
+timeout in seconds), i.e. how long the HCI layer should wait before
 disconnecting an inactive baseband connection.
-.Em This has not been implemented yet .
+.Bf -emphasis
-.It net.bluetooth.hci.max_neighbor_age
+This has not been implemented yet.
 .Ef
 .It Va net.bluetooth.hci.max_neighbor_age
 A read-write integer variable that controls time-to-live (in seconds) for
-entries in the HCI neighbor cache. Every time a Bluetooth device performs
+entries in the HCI neighbor cache.
-an
+Every time a Bluetooth device performs an
 .Dv Inquiry
-operation, the results will be put in cache. Later when a Bluetooth device 
+operation, the results will be put in cache.
-establishes a baseband connection, it will try to find the matching entry in 
+Later when a Bluetooth device
-the cache and use it. This might speed up establishment of the baseband 
+establishes a baseband connection, it will try to find the matching entry in
 the cache and use it.
 This might speed up establishment of the baseband
 connection.
-.It net.bluetooth.l2cap.rtx_timeout
+.It Va net.bluetooth.l2cap.rtx_timeout
-A read-write integer variable that controls the Link Layer Control and 
+A read-write integer variable that controls the Link Layer Control and
-Adaptation Protocol (L2CAP) Retransmission Timeout (RTX) (in seconds). 
+Adaptation Protocol (L2CAP) Retransmission Timeout (RTX) (in seconds).
-Every time the L2CAP layer submits a control command, the RTX timeout is set. 
+Every time the L2CAP layer submits a control command, the RTX timeout is set.
-The value of the RTX timeout should be greater or equal to the value of 
+The value of the RTX timeout should be greater or equal to the value of
-the HCI connection timeout. Be careful when changing this variable. Make
+the HCI connection timeout.
-sure you understand what you are doing.
+Be careful when changing this variable.
-.It net.bluetooth.l2cap.ertx_timeout
+Make sure you understand what you are doing.
-A read-write integer variable that controls the L2CAP Extended Retransmission 
+.It Va net.bluetooth.l2cap.ertx_timeout
-Timeout (ERTX) (in seconds). In some cases remote peer may respond with
+A read-write integer variable that controls the L2CAP Extended Retransmission
 Timeout (ERTX) (in seconds).
 In some cases remote peer may respond with
 .Dv PENDING
-status to the L2CAP control command. In this case the L2CAP command timeout 
+status to the L2CAP control command.
-is reset to the ERTX timeout value. The value of the ERTX timeout should be 
+In this case the L2CAP command timeout is reset to the ERTX timeout value.
-greater or equal to the value of the RTX timeout. Be careful when changing 
+The value of the ERTX timeout should be
-this variable. Make sure you understand what you are doing.
+greater or equal to the value of the RTX timeout.
 Be careful when changing this variable.
 Make sure you understand what you are doing.
 .El
 .Sh SEE ALSO
-.Xr sysctl 8 ,
+.Xr ng_btsocket 4 ,
 .Xr ng_hci 4 ,
 .Xr ng_l2cap 4 ,
-.Xr ng_btsocket 4
+.Xr sysctl 8
 .Sh HISTORY
 The
-.Nm 
+.Nm
 module was implemented in
 .Fx 5.0 .
 .Sh AUTHORS
--- a/share/man/man4/ng_bt3c.4
+++ b/share/man/man4/ng_bt3c.4
@ -1,8 +1,6 @@
 .\" ng_bt3c.4
 .\" 
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
-.\" 
+.\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
@ -11,7 +9,7 @@
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
-.\" 
+.\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@ -23,40 +21,46 @@
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
-.\" 
+.\"
 .\" $Id: ng_bt3c.4,v 1.3 2002/11/12 17:03:58 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd June 14, 2002
 .Dt NG_BT3C 4
 .Os
 .Sh NAME
-.Nm BTCCC
+.Nm ng_bt3c
 .Nd Netgraph node type that is also a 3Com Bluetooth PC card driver
 .Sh SYNOPSIS
 .In sys/types.h
 .In ng_bt3c.h
 .Sh DESCRIPTION
 The
-.Nm BTCCC
+.Nm btccc
 node type is both a persistent Netgraph node type and a driver for
-3Com Bluetooth PC card (3CRWB6096-HP). It implements a Bluetooth HCI
+3Com Bluetooth PC card (3CRWB6096-HP).
 It implements a Bluetooth HCI
 UART transport layer as per chapter H4 of the Bluetooth Specification
-Book v1.1. A new node is created when the card is plugged.
+Book v1.1.
 A new node is created when the card is plugged.
 .Pp
 In order to use the card one
 .Em MUST
-download firmware first. Due to copyright issues I will no longer
+download firmware first.
-provide firmware with the driver. The firmware can be obtained
+Due to copyright issues I will no longer provide firmware with the driver.
-from the Windows driver package that can be downloaded from the 3COM web 
+The firmware can be obtained
-site at no charge. The firmware name is BT3CPCC.BIN. To load firmware 
+from the Windows driver package that can be downloaded from the 3COM web
-info the card use
+site at no charge.
 The firmware name is
 .Pa BT3CPCC.BIN .
 To load firmware into the card, use
 .Xr bt3cfw 8 .
-I'm using original firmware that came with the card on CD-ROM.
+I am using original firmware that came with the card on CD-ROM.
 .Bd -literal -offset indent
 MD5 (BT3CPCC.BIN) = 36170fda56ea9fdbf1702c966f8a97f1
 .Ed
 .Pp
-For OLDCARD systems the entry in 
+.Dl "MD5 (BT3CPCC.BIN) = 36170fda56ea9fdbf1702c966f8a97f1"
 .Pp
 For
 .Pa OLDCARD
 systems the entry in
 .Xr pccard.conf 5
 might look like this
 .Bd -literal -offset indent
@ -66,29 +70,30 @@ card "3COM" "3CRWB60-A" "Bluetooth PC Card"
 	insert	/usr/sbin/bt3cfw -n $device -f /etc/BT3CPCC.bin
 .Ed
 .Pp
-Do not forget to load module and SIGHUP
+Do not forget to load module and
 .Dv SIGHUP
 .Xr pccardd 8 .
 .Pp
 The node has a single hook called
 .Dv hook .
 Incoming bytes received on the device are re-assembled into HCI frames
-(according to the length). Full HCI frames are sent out on the hook. HCI 
+(according to the length).
-frames received on
+Full HCI frames are sent out on the hook.
 HCI frames received on
 .Dv hook
-are transmitted out. No modification to the data is performed in 
+are transmitted out.
-either direction.
+No modification to the data is performed in either direction.
 .Sh HOOKS
 This node type supports the following hooks:
-.Pp
+.Bl -tag -width indent
 .Bl -tag -width foobar
 .It Dv hook
 single HCI frame contained in single
-.Dv mbuf
+.Vt mbuf
 structure.
 .El
 .Sh CONTROL MESSAGES
 This node type supports the generic control messages, plus the following:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv NGM_BT3C_NODE_GET_STATE
 Returns current receiving state for the node.
 .It Dv NGM_BT3C_NODE_GET_DEBUG
@ -97,15 +102,15 @@ Returns an integer containing the current debug level for the node.
 This command takes an integer argument and sets current debug level
 for the node.
 .It Dv NGM_BT3C_NODE_GET_QLEN
-This command takes a parameter that specifies queue number and returns 
+This command takes a parameter that specifies queue number and returns
 current length of the queue for the node.
 .It Dv NGM_BT3C_NODE_SET_QLEN
-This command takes two parameters that specify queue number and and 
+This command takes two parameters that specify queue number and and
-maximum length of the queue and sets maximum length of the queue for 
+maximum length of the queue and sets maximum length of the queue for
 the node.
 .It Dv NGM_BT3C_NODE_GET_STAT
-Returns various statistic information for the node, such as: number of 
+Returns various statistic information for the node, such as: number of
-bytes (frames) sent, number of bytes (frames) received and number of 
+bytes (frames) sent, number of bytes (frames) received and number of
 input (output) errors.
 .It Dv NGM_BT3C_NODE_RESET_STAT
 Reset all statistic counters to zero.
@ -115,21 +120,22 @@ Download card firmware.
 .Sh SHUTDOWN
 This node shuts down when the corresponding card is un-plugged.
 .Sh BUGS
-The driver is based on information obrained from Jose Orlando Pereira 
+The driver is based on information obtained from
-<jop@di.uminho.pt> and disassembled W2K driver.
+.An Jose Orlando Pereira Aq jop@di.uminho.pt
 and disassembled W2K driver.
 .Sh SEE ALSO
 .Xr cardbus 4 ,
 .Xr netgraph 4 ,
 .Xr pccbb 4 ,
 .Xr pcic 4 ,
 .Xr pccardc 8 ,
 .Xr pccardd 8 ,
 .Xr pccard.conf 5 ,
-.Xr netgraph 4 ,
+.Xr bt3cfw 8 ,
 .Xr ngctl 8 ,
-.Xr bt3cfw 8
+.Xr pccardc 8 ,
 .Xr pccardd 8
 .Sh HISTORY
 The
-.Nm BTCCC
+.Nm btccc
 node type was implemented in
 .Fx 5.0 .
 .Sh AUTHORS
--- a/share/man/man4/ng_btsocket.4
+++ b/share/man/man4/ng_btsocket.4
@ -1,5 +1,3 @@
 .\" ng_btsocket.4
 .\"
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
 .\"
@ -24,13 +22,13 @@
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
 .\"
 .\" $Id: ng_btsocket.4,v 1.4 2002/11/12 22:31:39 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd July 8, 2002
 .Dt NG_BTSOCKET 4
 .Os
 .Sh NAME
-.Nm btsocket
+.Nm ng_btsocket
 .Nd Bluetooth sockets layer
 .Sh SYNOPSIS
 .In sys/types.h
@ -43,23 +41,23 @@
 .Sh DESCRIPTION
 The
 .Nm
-module implements three Netgraph node types. Each type in its turn implements
+module implements three Netgraph node types.
-one protocol within 
+Each type in its turn implements one protocol within
 .Dv PF_BLUETOOTH
 domain.
-.Pp
+.Sh Dv BLUETOOTH_PROTO_HCI Sh protocol
-.Sh BLUETOOTH_PROTO_HCI protocol
+.Ss Dv SOCK_RAW Ss HCI sockets
 .Ss SOCK_RAW HCI sockets
 Implemented by
-.Cm btsock_hci_raw 
+.Nm btsock_hci_raw
-Netgraph type. Raw HCI sockets allow sending of raw HCI command datagrams
+Netgraph type.
 Raw HCI sockets allow sending of raw HCI command datagrams
 only to correspondents named in
 .Xr send 2
-calls. Raw HCI datagrams (HCI commands, events and data) are generally 
+calls.
-received with 
+Raw HCI datagrams (HCI commands, events and data) are generally received with
 .Xr recvfrom 2 ,
-which returns the next datagram with its return address. Also raw HCI
+which returns the next datagram with its return address.
-sockets can be used to control HCI nodes.
+Raw HCI sockets can also be used to control HCI nodes.
 .Pp
 The Bluetooth raw HCI socket address is defined as follows:
 .Bd -literal -offset indent
@ -71,14 +69,14 @@ struct sockaddr_hci {
 };
 .Ed
 .Pp
-Raw HCI sockets support number of 
+Raw HCI sockets support number of
-.Xr ioctl 2 
+.Xr ioctl 2
 requests such as:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv SIOC_HCI_RAW_NODE_GET_STATE
 Returns current state for the HCI node.
 .It Dv SIOC_HCI_RAW_NODE_INIT
-Turn on 
+Turn on
 .Dq inited
 bit for the HCI node.
 .It Dv SIOC_HCI_RAW_NODE_GET_DEBUG
@ -112,9 +110,10 @@ Returns current packet mask for the HCI node.
 Sets current packet mask for the HCI node.
 .El
 .Pp
-Raw HCI sockets support filters. The application can filter certain
+Raw HCI sockets support filters.
-HCI datagram types. For HCI event datagrams the application can set
+The application can filter certain HCI datagram types.
-additional filter. The raw HCI socket filter defined as follows:
+For HCI event datagrams the application can set additional filter.
 The raw HCI socket filter defined as follows:
 .Bd -literal -offset indent
 /*
 * Raw HCI socket filter.
@ -129,17 +128,16 @@ struct ng_btsocket_hci_raw_filter {
 };
 .Ed
 .Pp
-The 
+The
 .Dv SO_HCI_RAW_FILTER
 option defined at
-.Dv SOL_HCI_RAW 
+.Dv SOL_HCI_RAW
 level can be used to obtain via
 .Xr getsockopt 2
-or  change via
+or change via
-.Xr setsockopt 2 
+.Xr setsockopt 2
 raw HCI socket's filter.
-.Pp
+.Sh Dv BLUETOOTH_PROTO_L2CAP Sh protocol
 .Sh BLUETOOTH_PROTO_L2CAP protocol
 The Bluetooth L2CAP socket address is defined as follows:
 .Bd -literal -offset indent
 /* Bluetooth version of struct sockaddr for L2CAP sockets */
@ -150,19 +148,23 @@ struct sockaddr_l2cap {
        bdaddr_t  l2cap_bdaddr; /* address */
 };
 .Ed
-.Pp
+.Ss Dv SOCK_RAW Ss L2CAP sockets
 .Ss SOCK_RAW L2CAP sockets
 Implemented by
-.Cm btsock_l2c_raw 
+.Nm btsock_l2c_raw
 Netgraph type.
-Raw L2CAP sockets do not provide access to raw L2CAP datagrams. These 
+Raw L2CAP sockets do not provide access to raw L2CAP datagrams.
-sockets used to control L2CAP nodes and to issue special L2CAP requests 
+These
-such as ECHO_REQUEST and GET_INFO request.
+sockets used to control L2CAP nodes and to issue special L2CAP requests
 such as
 .Dv ECHO_REQUEST
 and
 .Dv GET_INFO
 request.
 .Pp
-Raw L2CAP sockets support number of 
+Raw L2CAP sockets support number of
-.Xr ioctl 2 
+.Xr ioctl 2
 requests such as:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv SIOC_L2CAP_NODE_GET_FLAGS
 Returns current state for the L2CAP node.
 .It Dv SIOC_L2CAP_NODE_GET_DEBUG
@ -175,81 +177,97 @@ node.
 .It Dv SIOC_L2CAP_NODE_GET_CHAN_LIST
 Returns list of active channels for the L2CAP node.
 .It Dv SIOC_L2CAP_L2CA_PING
-Issues L2CAP ECHO_REQUEST.
+Issues L2CAP
 .Dv ECHO_REQUEST .
 .It Dv SIOC_L2CAP_L2CA_GET_INFO
-Issues L2CAP GET_INFO request.
+Issues L2CAP
 .Dv GET_INFO
 request.
 .El
-.Pp
+.Ss Dv SOCK_SEQPACKET Ss L2CAP sockets
 .Ss SOCK_SEQPACKET L2CAP sockets
 Implemented by
-.Cm btsock_l2c 
+.Nm btsock_l2c
 Netgraph type.
-L2CAP sockets are either 
+L2CAP sockets are either
 .Dq active
 or
 .Dq passive .
-Active sockets initiate connections to passive sockets. By default L2CAP
+Active sockets initiate connections to passive sockets.
-sockets are created active; to create a passive socket the
+By default L2CAP sockets are created active; to create a passive socket the
 .Xr listen 2
-system call must be used after binding the socket with the 
+system call must be used after binding the socket with the
 .Xr bind 2
-system call. Only passive sockets may use the 
+system call.
-.Xr accept 2 
+Only passive sockets may use the
-call to accept incoming connections. Only active sockets may use the 
+.Xr accept 2
-.Xr connect 2 
+call to accept incoming connections.
-call to initiate connections. 
+Only active sockets may use the
 .Xr connect 2
 call to initiate connections.
 .Pp
-L2CAP sockets supports
+L2CAP sockets support
-.Dq wildcard addressing .
+.Dq "wildcard addressing" .
-In this case socket must be bound to 
+In this case, socket must be bound to
-.Dv NG_HCI_BDADDR_ANY 
+.Dv NG_HCI_BDADDR_ANY
-address.  Note that PSM (Protocol/Service Multiplexor) filed is always
+address.
-required. Once a connection has been established the socket's address is 
+Note that PSM (Protocol/Service Multiplexor) filed is always
-fixed by the peer entity's location. The address assigned the socket is 
+required.
-the address associated with the Bluetooth device through which packets are 
+Once a connection has been established the socket's address is
 fixed by the peer entity's location.
 The address assigned the socket is
 the address associated with the Bluetooth device through which packets are
 being transmitted and received, and PSM (Protocol/Service Multiplexor).
 .Pp
 L2CAP sockets support number of options defined at
-.Dv SOL_L2CAP 
+.Dv SOL_L2CAP
-level which can be set with 
+level which can be set with
-.Xr setsockopt 2 
+.Xr setsockopt 2
-and tested with 
+and tested with
 .Xr getsockopt 2 :
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv SO_L2CAP_IMTU
 Get (set) maximum payload size the local socket is capable of accepting.
 .It Dv SO_L2CAP_OMTU
 Get maximum payload size the remote socket is capable of accepting.
 .It Dv SO_L2CAP_IFLOW
-Get incoming flow specification for the socket. 
+Get incoming flow specification for the socket.
-.Em Not implemented .
+.Bf -emphasis
 Not implemented.
 .Ef
 .It Dv SO_L2CAP_OFLOW
 Get (set) outgoing flow specification for the socket.
-.Em Not implemented .
+.Bf -emphasis
 Not implemented.
 .Ef
 .It Dv SO_L2CAP_FLUSH
 Get (set) value of the flush timeout.
-.Em Not implemeted .
+.Bf -emphasis
 Not implemeted.
 .Ef
 .El
 .Sh HOOKS
-This node type supports hooks with arbitrary names (as long as they are 
+This node type supports hooks with arbitrary names (as long as they are
 unique) and always accepts hook connection requests.
 .Sh NETGRAPH CONTROL MESSAGES
 This node type supports the generic control messages.
 .Sh SHUTDOWN
 These nodes are persistent and cannot be shut down.
 .Sh BUGS
-Most likely. Please report if found.
+Most likely.
 Please report if found.
 .Sh SEE ALSO
 .Xr btsockstat 1 ,
 .Xr socket 2 ,
 .Xr netgraph 4 ,
 .Xr ngctl 8 ,
 .Xr ng_hci 4 ,
 .Xr ng_l2cap 4 ,
-.Xr btsockstat 1
+.Xr ngctl 8
 .Sh HISTORY
 The
-.Nm
+.Nm btsock_hci_raw , btsock_l2c_raw ,
-node type was implemented in
+and
 .Nm btsock_l2c
 node types were implemented in
 .Fx 5.0 .
 .Sh AUTHORS
 .An Maksim Yevmenkin Aq m_evmenkin@yahoo.com
--- a/share/man/man4/ng_h4.4
+++ b/share/man/man4/ng_h4.4
@ -1,8 +1,6 @@
 .\" ng_h4.4
 .\" 
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
-.\" 
+.\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
@ -11,7 +9,7 @@
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
-.\" 
+.\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@ -23,15 +21,15 @@
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
-.\" 
+.\"
 .\" $Id: ng_h4.4,v 1.3 2002/11/12 17:10:13 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd June 14, 2002
 .Dt NG_H4 4
 .Os
 .Sh NAME
-.Nm h4
+.Nm ng_h4
-.Nd Netgraph node type that is also a H4 line discipline
+.Nd Netgraph node type that is also an H4 line discipline
 .Sh SYNOPSIS
 .In sys/types.h
 .In sys/ttycom.h
@ -39,20 +37,22 @@
 .In netgraph/ng_h4.h
 .Sh DESCRIPTION
 The
-.Nm
+.Nm h4
-node type is both a persistent Netgraph node type and a H4 line 
+node type is both a persistent Netgraph node type and a H4 line
-discipline. It implements a Bluetooth HCI UART transport layer as 
+discipline.
-per chapter H4 of the Bluetooth Specification Book v1.1. A new 
+It implements a Bluetooth HCI UART transport layer as
-node is created when the corresponding line discipline,
+per chapter H4 of the Bluetooth Specification Book v1.1.
 A new node is created when the corresponding line discipline,
 .Dv H4DISC ,
 is registered on a tty device (see
 .Xr tty 4 ) .
 .Pp
 The node has a single hook called
 .Dv hook .
-Incoming bytes received on the tty device are re-assembled into 
+Incoming bytes received on the tty device are re-assembled into
-HCI frames (according to the length). Full HCI frames are sent out on 
+HCI frames (according to the length).
-the hook. HCI frames received on
+Full HCI frames are sent out on the hook.
 HCI frames received on
 .Dv hook
 are transmitted out on the tty device.
 No modification to the data is performed in either direction.
@ -65,22 +65,22 @@ Information about the node is available via the netgraph
 command
 .Dv NGIOCGINFO .
 This command returns a
-.Dv "struct nodeinfo"
+.Vt "struct nodeinfo"
 similar to the
 .Dv NGM_NODEINFO
-netgraph control message.
+.Xr netgraph 4
 control message.
 .Sh HOOKS
 This node type supports the following hooks:
-.Pp
+.Bl -tag -width indent
 .Bl -tag -width foobar
 .It Dv hook
 single HCI frame contained in single
-.Dv mbuf
+.Vt mbuf
 structure.
 .El
 .Sh CONTROL MESSAGES
 This node type supports the generic control messages, plus the following:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv NGM_H4_NODE_RESET
 Reset the node.
 .It Dv NGM_H4_NODE_GET_STATE
@ -96,8 +96,8 @@ Returns current length of outgoing queue for the node.
 This command takes an integer argument and sets maximum length of
 outgoing queue for the node.
 .It Dv NGM_H4_NODE_GET_STAT
-Returns various statistic information for the node, such as: number of 
+Returns various statistic information for the node, such as: number of
-bytes (frames) sent, number of bytes (frames) received and number of 
+bytes (frames) sent, number of bytes (frames) received and number of
 input (output) errors.
 .It Dv NGM_H4_NODE_RESET_STAT
 Reset all statistic counters to zero.
@ -106,7 +106,10 @@ Reset all statistic counters to zero.
 This node shuts down when the corresponding device is closed
 (or the line discipline is uninstalled on the device).
 .Sh BUGS
-This node still uses spltty() to lock tty layer. This is wrong.
+This node still uses
 .Xr spltty 9
 to lock tty layer.
 This is wrong.
 .Sh SEE ALSO
 .Xr ioctl 2 ,
 .Xr netgraph 4 ,
@ -114,7 +117,7 @@ This node still uses spltty() to lock tty layer. This is wrong.
 .Xr ngctl 8
 .Sh HISTORY
 The
-.Nm
+.Nm h4
 node type was implemented in
 .Fx 5.0 .
 .Sh AUTHORS
--- a/share/man/man4/ng_hci.4
+++ b/share/man/man4/ng_hci.4
@ -1,8 +1,6 @@
 .\" ng_hci.4
 .\" 
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
-.\" 
+.\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
@ -11,7 +9,7 @@
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
-.\" 
+.\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@ -23,15 +21,15 @@
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
-.\" 
+.\"
 .\" $Id: ng_hci.4,v 1.8 2002/11/12 22:35:39 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd June 25, 2002
 .Dt NG_HCI 4
 .Os
 .Sh NAME
-.Nm hci
+.Nm ng_hci
-.Nd Netgraph node type that is also a Bluetooth Host Controller Interface 
+.Nd Netgraph node type that is also a Bluetooth Host Controller Interface
 (HCI) layer
 .Sh SYNOPSIS
 .In sys/types.h
@ -40,78 +38,100 @@
 .In netgraph/ng_hci.h
 .Sh DESCRIPTION
 The
-.Nm
+.Nm hci
 node type is a Netgraph node type that implements Bluetooth Host Controller
-Interface (HCI) layer as per chapter H1 of the Bluetooth Specification Book 
+Interface (HCI) layer as per chapter H1 of the Bluetooth Specification Book
 v1.1.
 .Sh INTRODUCTION TO BLUETOOTH
-Bluetooth is a short-range radio link intended to replace the cable(s) 
+Bluetooth is a short-range radio link intended to replace the cable(s)
-connecting portable and/or fixed electronic devices. Bluetooth operates
+connecting portable and/or fixed electronic devices.
-in the unlicensed ISM band at 2.4 GHz. The Bluetooth protocol uses a 
+Bluetooth operates in the unlicensed ISM band at 2.4 GHz.
-combination of circuit and packet switching. Bluetooth can support an
+The Bluetooth protocol uses a
 combination of circuit and packet switching.
 Bluetooth can support an
 asynchronous data channel, up to three simultaneous synchronous voice
-channels, or a channel which simultaneously supports asynchronous data 
+channels, or a channel which simultaneously supports asynchronous data
-and synchronous voice. Each voice channel supports a 64 kb/s synchronous
+and synchronous voice.
-(voice) channel in each direction. The asynchronous channel can support 
+Each voice channel supports a 64 kb/s synchronous
-maximal 723.2 kb/s asymmetric (and still up to 57.6 kb/s in the return 
+(voice) channel in each direction.
 The asynchronous channel can support
 maximal 723.2 kb/s asymmetric (and still up to 57.6 kb/s in the return
 direction), or 433.9 kb/s symmetric.
 .Pp
-The Bluetooth system provides a point-to-point connection (only two 
+The Bluetooth system provides a point-to-point connection (only two
-Bluetooth units involved), or a point-to-multipoint connection. In the 
+Bluetooth units involved), or a point-to-multipoint connection.
-point-to-multipoint connection, the channel is shared among several
+In the point-to-multipoint connection,
-Bluetooth units. Two or more units sharing the same channel form a 
+the channel is shared among several Bluetooth units.
-.Em piconet .
+Two or more units sharing the same channel form a
-One Bluetooth unit acts as the master of the piconet, whereas the other 
+.Dq piconet .
-unit(s) acts as slave(s). Up to seven slaves can be active in the piconet. 
+One Bluetooth unit acts as the master of the piconet, whereas the other
 unit(s) acts as slave(s).
 Up to seven slaves can be active in the piconet.
 In addition, many more slaves can remain locked to the master in a so-called
-parked state. These parked slaves cannot be active on the channel, but remain 
+parked state.
-synchronized to the master. Both for active and parked slaves, the channel 
+These parked slaves cannot be active on the channel, but remain
 synchronized to the master.
 Both for active and parked slaves, the channel
 access is controlled by the master.
-.Pp 
+.Pp
-Multiple piconets with overlapping coverage areas form a 
+Multiple piconets with overlapping coverage areas form a
-.Em scatternet .
+.Dq scatternet .
-Each piconet can only have a single master. However, slaves can participate 
+Each piconet can only have a single master.
-in different piconets on a time-division multiplex basis. In addition, a 
+However, slaves can participate
-master in one piconet can be a slave in another piconet. The piconets shall 
+in different piconets on a time-division multiplex basis.
-not be frequency-synchronized. Each piconet has its own hopping channel.
+In addition, a master in one piconet can be a slave in another piconet.
-.Ss Time slots
+The piconets shall not be frequency-synchronized.
-The channel is divided into time slots, each 625 usec in length. The time 
+Each piconet has its own hopping channel.
-slots are numbered according to the Bluetooth clock of the piconet master. 
+.Ss Time Slots
-The slot numbering ranges from 0 to 2^27 -1 and is cyclic with a cycle length 
+The channel is divided into time slots, each 625 usec in length.
-of 2^27. In the time slots, master and slave can transmit packets.
+The time
-.Ss SCO link
+slots are numbered according to the Bluetooth clock of the piconet master.
-The SCO link is a symmetric, point-to-point link between the master and a 
+The slot numbering ranges from 0 to 2^27 -1 and is cyclic with a cycle length
-specific slave. The SCO link reserves slots and can therefore be considered 
+of 2^27.
-as a circuit-switched connection between the master and the slave. The SCO 
+In the time slots, master and slave can transmit packets.
-link typically supports time-bounded information like voice. The master can 
+.Ss SCO Link
-support up to three SCO links to the same slave or to different slaves. A 
+The SCO link is a symmetric, point-to-point link between the master and a
-slave can support up to three SCO links from the same master, or two SCO 
+specific slave.
-links if the links originate from different masters. SCO packets are never 
+The SCO link reserves slots and can therefore be considered
-retransmitted.
+as a circuit-switched connection between the master and the slave.
-.Ss ACL link
+The SCO link typically supports time-bounded information like voice.
-In the slots not reserved for SCO links, the master can exchange packets 
+The master can
-with any slave on a per-slot basis. The ACL link provides a packet-switched 
+support up to three SCO links to the same slave or to different slaves.
-connection between the master and all active slaves participating in the 
+A
-piconet. Both asynchronous and isochronous services are supported. Between 
+slave can support up to three SCO links from the same master, or two SCO
-a master and a slave only a single ACL link can exist. For most ACL packets, 
+links if the links originate from different masters.
 SCO packets are never retransmitted.
 .Ss ACL Link
 In the slots not reserved for SCO links, the master can exchange packets
 with any slave on a per-slot basis.
 The ACL link provides a packet-switched
 connection between the master and all active slaves participating in the
 piconet.
 Both asynchronous and isochronous services are supported.
 Between a master and a slave only a single ACL link can exist.
 For most ACL packets,
 packet retransmission is applied to assure data integrity.
 .Sh HOST CONTROLLER INTERFACE (HCI)
-The HCI provides a command interface to the baseband controller and link 
+The HCI provides a command interface to the baseband controller and link
-manager, and access to hardware status and control registers. This interface 
+manager, and access to hardware status and control registers.
 This interface
 provides a uniform method of accessing the Bluetooth baseband capabilities.
 .Pp
 The HCI layer on the Host exchanges data and commands with the HCI firmware
-on the Bluetooth hardware. The Host Controller Transport Layer (i.e. physical
+on the Bluetooth hardware.
 The Host Controller Transport Layer (i.e. physical
 bus) driver provides both HCI layers with the ability to exchange information
 with each other.
 .Pp
-The Host will receive asynchronous notifications of HCI events independent 
+The Host will receive asynchronous notifications of HCI events independent
-of which Host Controller Transport Layer is used. HCI events are used for 
+of which Host Controller Transport Layer is used.
-notifying the Host when something occurs. When the Host discovers that an 
+HCI events are used for
-event has occurred it will then parse the received event packet to determine 
+notifying the Host when something occurs.
 When the Host discovers that an
 event has occurred it will then parse the received event packet to determine
 which event occurred.
 The next sections specify the HCI packet formats.
-.Ss HCI command packet
+.Ss HCI Command Packet
 .Bd -literal -offset indent
 #define NG_HCI_CMD_PKT 0x01
 typedef struct {
@ -122,15 +142,19 @@ typedef struct {
 .Ed
 .Pp
 The HCI command packet is used to send commands to the Host Controller
-from the Host. When the Host Controller completes most of the commands, 
+from the Host.
-a Command Complete event is sent to the Host. Some commands do not receive 
+When the Host Controller completes most of the commands,
-a Command Complete event when they have been completed. Instead, when the 
+a Command Complete event is sent to the Host.
-Host Controller receives one of these commands the Host Controller sends 
+Some commands do not receive
-a Command Status event back to the Host when it has begun to execute the 
+a Command Complete event when they have been completed.
-command. Later on, when the actions associated with the command have finished, 
+Instead, when the
-an event that is associated with the sent command will be sent by the Host 
+Host Controller receives one of these commands the Host Controller sends
 a Command Status event back to the Host when it has begun to execute the
 command.
 Later on, when the actions associated with the command have finished,
 an event that is associated with the sent command will be sent by the Host
 Controller to the Host.
-.Ss HCI event packet
+.Ss HCI Event Packet
 .Bd -literal -offset indent
 #define NG_HCI_EVENT_PKT 0x04
 typedef struct {
@ -140,9 +164,9 @@ typedef struct {
 } __attribute__ ((packed)) ng_hci_event_pkt_t;
 .Ed
 .Pp
-The HCI event packet is used by the Host Controller to notify the Host 
+The HCI event packet is used by the Host Controller to notify the Host
 when events occur.
-.Ss HCI ACL data packet
+.Ss HCI ACL Data Packet
 .Bd -literal -offset indent
 #define NG_HCI_ACL_DATA_PKT 0x02
 typedef struct {
@ -152,9 +176,9 @@ typedef struct {
 } __attribute__ ((packed)) ng_hci_acldata_pkt_t;
 .Ed
 .Pp
-HCI ACL data packets are used to exchange ACL data between the Host and 
+HCI ACL data packets are used to exchange ACL data between the Host and
 Host Controller.
-.Ss HCI SCO data packet
+.Ss HCI SCO Data Packet
 .Bd -literal -offset indent
 #define NG_HCI_SCO_DATA_PKT 0x03
 typedef struct {
@ -164,29 +188,31 @@ typedef struct {
 } __attribute__ ((packed)) ng_hci_scodata_pkt_t;
 .Ed
 .Pp
-HCI SCO data packets are used to exchange SCO data between the Host and 
+HCI SCO data packets are used to exchange SCO data between the Host and
 Host Controller.
 .Sh HCI INITIALIZATION
 On initialization, HCI control application must issue the following HCI
 commands (in any order).
-.Bl -tag -width foobar
+.Bl -tag -width indent
 .It Dv Read_BD_ADDR
 To obtain BD_ADDR of the Bluetooth unit.
 .It Dv Read_Local_Supported_Features
 To obtain the list of features supported by Bluetooth unit.
 .It Dv Read_Buffer_Size
-To determine the maximum size of HCI ACL and SCO HCI data packets (excluding 
+To determine the maximum size of HCI ACL and SCO HCI data packets (excluding
-header) that can be sent from the Host to the Host Controller. There are also 
+header) that can be sent from the Host to the Host Controller.
-two additional return parameters that specify the total number of HCI ACL and 
+There are also
-SCO data packets that the Host Controller can have waiting for transmission in 
+two additional return parameters that specify the total number of HCI ACL and
-its buffers. 
+SCO data packets that the Host Controller can have waiting for transmission in
 its buffers.
 .El
 .Pp
-As soon as HCI initialization has been successfuly performed, HCI control 
+As soon as HCI initialization has been successfuly performed, HCI control
 application must turn on
 .Dq inited
-bit for the node. Once HCI node has been initialized all upsteam hooks
+bit for the node.
-will receive a 
+Once HCI node has been initialized all upsteam hooks
 will receive a
 .Dv NGM_HCI_NODE_UP
 Netgraph message defined as follows.
 .Bd -literal -offset indent
@ -200,17 +226,22 @@ typedef struct {
 .Ed
 .Sh HCI FLOW CONTROL
 HCI layer performs flow control on baseband connection basis (i.e. ACL and
-SCO link). Each baseband connection has
+SCO link).
-.Em connection handle 
+Each baseband connection has
-and queue of outgoing data packets. Upper layers protocols are allowed to
+.Dq "connection handle"
-send up to (
+and queue of outgoing data packets.
-.Dv num_pkts -
+Upper layers protocols are allowed to
 send up to
 .Dv ( num_pkts
 \-
 .Dv pending )
-packets at one time. HCI layer will send 
+packets at one time.
-.Dv NGM_HCI_SYNC_CON_QUEUE 
+HCI layer will send
-Netgraph messages to inform upper layers about current queue state for each 
+.Dv NGM_HCI_SYNC_CON_QUEUE
-connection handle. The
+Netgraph messages to inform upper layers about current queue state for each
-.Dv NGM_HCI_SYNC_CON_QUEUE 
+connection handle.
 The
 .Dv NGM_HCI_SYNC_CON_QUEUE
 Netgraph message is defined as follows.
 .Bd -literal -offset indent
 #define NGM_HCI_SYNC_CON_QUEUE 113 /* HCI -> Upper */
@ -221,71 +252,73 @@ typedef struct {
 .Ed
 .Sh HOOKS
 This node type supports the following hooks:
-.Pp
+.Bl -tag -width indent
 .Bl -tag -width foobar
 .It Dv drv
-Bluetooth Host Controller Transport Layer hook. Single HCI packet contained in 
+Bluetooth Host Controller Transport Layer hook.
-single
+Single HCI packet contained in single
-.Dv mbuf
+.Vt mbuf
 structure.
 .It Dv acl
-Upper layer protocol/node is connected to the hook. Single HCI ACL
+Upper layer protocol/node is connected to the hook.
-data packet contained in single
+Single HCI ACL data packet contained in single
-.Dv mbuf
+.Vt mbuf
 structure.
 .It Dv sco
-Upper layer protocol/node is connected to the hook. Single HCI SCO
+Upper layer protocol/node is connected to the hook.
-data packet contained in single
+Single HCI SCO data packet contained in single
-.Dv mbuf
+.Vt mbuf
 structure.
 .It Dv raw
-Raw hook. Every HCI frame (including HCI command frame) that goes in 
+Raw hook.
-or out will be delivired to the hook. Usually Bluetooth raw HCI sockets 
+Every HCI frame (including HCI command frame) that goes in
-layer is connected to the hook. Single HCI frame contained in single
+or out will be delivired to the hook.
-. Dv mbuf
+Usually Bluetooth raw HCI sockets layer is connected to the hook.
 Single HCI frame contained in single
 .Vt mbuf
 structure.
 .El
 .Sh BLUETOOTH UPPER LAYER PROTOCOLS INTERFACE (LP CONTROL MESSAGES)
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv NGM_HCI_LP_CON_REQ
-Requests the lower protocol to create a connection. If a physical link
+Requests the lower protocol to create a connection.
 If a physical link
 to the remote device does not exist, this message must be sent to the lower
 protocol (baseband) to establish the physical connection.
 .It Dv NGM_HCI_LP_DISCON_REQ
-Requests the lower protocol (baseband) to terminate a connection. 
+Requests the lower protocol (baseband) to terminate a connection.
 .It Dv NGM_HCI_LP_CON_CFM
 Confirms success or failure of the
-.Dv 
+.Dv NGM_HCI_LP_CON_REQ
-NGM_HCI_LP_CON_REQ request to establish a lower layer (baseband) connection. 
+request to establish a lower layer (baseband) connection.
-This includes passing the authentication challenge if authentication is 
+This includes passing the authentication challenge if authentication is
 required to establish the physical link.
 .It Dv NGM_HCI_LP_CON_IND
-Indicates the lower protocol (baseband) has successfully established 
+Indicates the lower protocol (baseband) has successfully established
-incoming connection. 
+incoming connection.
 .It Dv NGM_HCI_LP_CON_RSP
 A response accepting or rejecting the previous connection indication request.
 .It Dv NGM_HCI_LP_DISCON_IND
-Indicates the lower protocol (baseband) has terminated connection. This
+Indicates the lower protocol (baseband) has terminated connection.
-could be a response to 
+This could be a response to
 .Dv NGM_HCI_LP_DISCON_REQ
 or a timeout event.
 .It Dv NGM_HCI_LP_QOS_REQ
-Requests the lower protocol (baseband) to accommodate a particular QoS 
+Requests the lower protocol (baseband) to accommodate a particular QoS
 parameter set.
 .It Dv NGM_HCI_LP_QOS_CFM
 Confirms success or failure of the request for a given quality of service.
 .It Dv NGM_HCI_LP_QOS_IND
-Indicates the lower protocol (baseband) has detected a violation of the QoS 
+Indicates the lower protocol (baseband) has detected a violation of the QoS
 agreement.
 .El
 .Sh NETGRAPH CONTROL MESSAGES
 This node type supports the generic control messages, plus the following:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv NGM_HCI_NODE_GET_STATE
 Returns current state for the node.
 .It Dv NGM_HCI_NODE_INIT
 Turn on
-.Dq inited 
+.Dq inited
 bit for the node.
 .It Dv NGM_HCI_NODE_GET_DEBUG
 Returns an integer containing the current debug level for the node.
@ -309,15 +342,18 @@ Returns various statistic counters.
 .It Dv NGM_HCI_NODE_RESET_STAT
 Resets all statistic counters to zero.
 .It NGM_HCI_NODE_SET_LINK_POLICY_SETTINGS_MASK
-Sets current link policy settings mask. After the new ACL connection is 
+Sets current link policy settings mask.
-created the HCI node will try set link policy for the ACL connection. By 
+After the new ACL connection is
-default every supported Link Manager (LM) mode will be enabled. User can 
+created the HCI node will try set link policy for the ACL connection.
-override this by setting link policy settings mask which specifies LM 
+By default, every supported Link Manager (LM) mode will be enabled.
 User can
 override this by setting link policy settings mask which specifies LM
 modes to be enabled.
 .It NGM_HCI_NODE_GET_LINK_POLICY_SETTINGS_MASK
 Returns current link policy settings mask.
 .It NGM_HCI_NODE_SET_PACKET_MASK
-Sets current packet mask. When new baseband (ACL or SCO) connection is
+Sets current packet mask.
 When new baseband (ACL or SCO) connection is
 created the HCI node will specify every packet type supported by the device.
 User can override this by setting packet mask which specifies packet types
 to be used for new baseband connections.
@ -325,17 +361,20 @@ to be used for new baseband connections.
 Returns current packet mask.
 .El
 .Sh SHUTDOWN
-This node shuts down upon receipt of a NGM_SHUTDOWN control message, or
+This node shuts down upon receipt of a
 .Dv NGM_SHUTDOWN
 control message, or
 when all hooks have been disconnected.
 .Sh BUGS
-Most likely. Please report if found.
+Most likely.
 Please report if found.
 .Sh SEE ALSO
 .Xr netgraph 4 ,
-.Xr ngctl 8 ,
+.Xr hccontrol 8 ,
-.Xr hccontrol 8
+.Xr ngctl 8
 .Sh HISTORY
 The
-.Nm
+.Nm hci
 node type was implemented in
 .Fx 5.0 .
 .Sh AUTHORS
--- a/share/man/man4/ng_l2cap.4
+++ b/share/man/man4/ng_l2cap.4
@ -1,8 +1,6 @@
 .\" ng_l2cap.4
 .\" 
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
-.\" 
+.\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
@ -11,7 +9,7 @@
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
-.\" 
+.\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@ -23,14 +21,14 @@
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
-.\" 
+.\"
 .\" $Id: ng_l2cap.4,v 1.4 2002/11/12 17:16:19 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd July 4, 2002
 .Dt NG_L2CAP 4
 .Os
 .Sh NAME
-.Nm l2cap
+.Nm ng_l2cap
 .Nd Netgraph node type that implements Bluetooth Logical Link Control and
 Adaptation Protocol (L2CAP)
 .Sh SYNOPSIS
@ -41,123 +39,164 @@ Adaptation Protocol (L2CAP)
 .In netgraph/ng_l2cap.h
 .Sh DESCRIPTION
 The
-.Nm
+.Nm l2cap
-node type is a Netgraph node type that implements Bluetooth Logical Link 
+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.
 .Pp
-L2CAP provides connection-oriented and connectionless data services to upper 
+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
+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.
-.Ss L2CAP assumptions
+.Ss L2CAP Assumptions
-.Bl -enum -offset indent 
+.Bl -enum -offset indent
 .It
-The ACL link between two units is set up. The Baseband provides orderly 
+The ACL link between two units is set up.
-delivery of data packets, although there might be individual packet corruption 
+The Baseband provides orderly
-and duplicates. No more than 1 ACL link exists between any two devices.
+delivery of data packets, although there might be individual packet corruption
 and duplicates.
 No more than 1 ACL link exists between any two devices.
 .It
 The Baseband always provides the impression of full-duplex communication
-channels. This does not imply that all L2CAP communications are bi-directional.
+channels.
 This does not imply that all L2CAP communications are bi-directional.
 Multicasts and unidirectional traffic (e.g., video) do not require duplex
 channels.
 .It
 L2CAP provides a reliable channel using the mechanisms available at the
-Baseband layer. The Baseband always performs data integrity checks when
+Baseband layer.
 The Baseband always performs data integrity checks when
 requested and resends data until it has been successfully acknowledged or
-a timeout occurs. Because acknowledgements may be lost, timeouts may
+a timeout occurs.
 Because acknowledgements may be lost, timeouts may
 occur even after the data has been successfully sent.
 .El
 .Sh L2CAP GENERAL OPERATION
 The Logical Link Control and Adaptation Protocol (L2CAP) is based around the
 concept of
-.Em channels .
+.Dq channels .
-Each channel is bound to a single protocol in a many-to-one fashion. Multiple 
+Each channel is bound to a single protocol in a many-to-one fashion.
-channels can be bound to the same protocol, but a channel cannot be bound to 
+Multiple
-multiple protocols. Each L2CAP packet received on a channel is directed to 
+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.
 .Pp
-Each one of the end-points of an L2CAP channel is referred to by a channel 
+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 
+identifier.
-channel end-point on the device. Identifiers from 0x0001 to 0x003F are reserved
+Channel identifiers (CIDs) are local names representing a logical
-for specific L2CAP functions. The null identifier (0x0000) is defined as an 
+channel end-point on the device.
-illegal identifier and must never be used as a destination end-point. 
+Identifiers from 0x0001 to 0x003F are reserved
-All L2CAP signalling commands are sent to CID 0x0001. CID 0x0002 is reserved
+for specific L2CAP functions.
-for group-oriented channel. The same CID must not be reused as a local L2CAP 
+The null identifier (0x0000) is defined as an
-channel endpoint for multiple simultaneous L2CAP channels between a local 
+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.
 .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
+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.
-.Ss Channel operational states
+.Ss Channel Operational States
-.Bl -tag -width foobar
+.Bl -tag -width indent
 .It Dv NG_L2CAP_CLOSED
-In this state, there is no channel associated with this CID. This is the only
+In this state, there is no channel associated with this CID.
-state when a link level connection (Baseband) may not exist. Link disconnection
+This is the only
-forces all other states into the NG_L2CAP_CLOSED state.
+state when a link level connection (Baseband) may not exist.
 Link disconnection
 forces all other states into the
 .Dv NG_L2CAP_CLOSED
 state.
 .It Dv NG_L2CAP_W4_L2CAP_CON_RSP
-In this state, the CID represents a local end-point and an L2CAP Connect 
+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 
+Request message has been sent referencing this endpoint and it is now waiting
 for the corresponding L2CAP Connect Response message.
 .It Dv NG_L2CAP_W4_L2CA_CON_RSP
 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
+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
+received L2CAP Connect Request waits for the corresponding response.
-response may require a security check to be performed.
+The response may require a security check to be performed.
 .It Dv NG_L2CAP_CONFIG
 In this state, the connection has been established but both sides are still
-negotiating the channel parameters. The Configuration state may also be
+negotiating the channel parameters.
-entered when the channel parameters are being renegotiated. Prior to entering
+The Configuration state may also be
-the NG_L2CAP_CONFIG state, all outgoing data traffic is suspended since
+entered when the channel parameters are being renegotiated.
-the traffic parameters of the data traffic are to be renegotiated. Incoming
+Prior to entering
 the
 .Dv NG_L2CAP_CONFIG
 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 NG_L2CAP_CONFIG state. In the NG_L2CAP_CONFIG state, both sides will issue 
+the
-L2CAP Configuration Request messages if only defaults are being used, a null 
+.Dv NG_L2CAP_CONFIG
-message will be sent. If a large amount of parameters need to be negotiated,
+state.
 In the
 .Dv NG_L2CAP_CONFIG
 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 NG_L2CAP_CONFIG state to the NG_L2CAP_OPEN state
+incrementally.
-requires both sides to be ready. An L2CAP entity is ready when it has received 
+Moving from the
-a positive response to its final request and it has positively responded to 
+.Dv NG_L2CAP_CONFIG
 state to the
 .Dv NG_L2CAP_OPEN
 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.
 .It Dv NG_L2CAP_OPEN
 In this state, the connection has been established and configured, and data
 flow may proceed.
 .It Dv NG_L2CAP_W4_L2CAP_DISCON_RSP
 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.
+message has been sent.
 This state is now waiting for the corresponding response.
 .It Dv NG_L2CAP_W4_L2CA_DISCON_RSP
 In this state, the connection on the remote endpoint is shutting down and an
-L2CAP Disconnect Request message has been received. An L2CA Disconnect
+L2CAP Disconnect Request message has been received.
-Indication has been sent to the upper layer to notify the owner of the CID 
+An L2CA Disconnect
-that the remote endpoint is being closed. This state is now waiting for the 
+Indication has been sent to the upper layer to notify the owner of the CID
-corresponding response from the upper layer before responding to the remote 
+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.
 .El
 .Ss Protocol Multiplexing
-L2CAP supports protocol multiplexing because the Baseband Protocol does not 
+L2CAP supports protocol multiplexing because the Baseband Protocol does not
-support any 
+support any
-.Dq type 
+.Dq type
-field identifying the higher layer protocol being multiplexed above it. 
+field identifying the higher layer protocol being multiplexed above it.
-L2CAP is able to distinguish between upper layer protocols such as the Service 
+L2CAP is able to distinguish between upper layer protocols such as the Service
 Discovery Protocol, RFCOMM and Telephony Control.
 .Ss Segmentation and Reassembly
-The data packets defined by the Baseband Protocol are limited in size. Large 
+The data packets defined by the Baseband Protocol are limited in size.
-L2CAP packets must be segmented into multiple smaller Baseband packets prior 
+Large
-to their transmission over the air. Similarly, multiple received Baseband 
+L2CAP packets must be segmented into multiple smaller Baseband packets prior
-packets may be reassembled into a single larger L2CAP packet. 
+to their transmission over the air.
 Similarly, multiple received Baseband
 packets may be reassembled into a single larger L2CAP packet.
 .Ss Quality of Service
 The L2CAP connection establishment process allows the exchange of information
-regarding the quality of service (QoS) expected between two Bluetooth units. 
+regarding the quality of service (QoS) expected between two Bluetooth units.
 .Ss Groups
-The Baseband Protocol supports the concept of a piconet, a group of devices 
+The Baseband Protocol supports the concept of a piconet, a group of devices
-synchronously hopping together using the same clock. The L2CAP group 
+synchronously hopping together using the same clock.
 The L2CAP group
 abstraction permits implementations to efficiently map protocol groups on to
-piconets. 
+piconets.
 .Pp
 The following features are outside the scope of L2CAP responsibilities:
 .Bl -dash -offset indent
@ -178,84 +217,101 @@ This node type supports the following hooks:
 .It Dv hci
 Bluetooth Host Controller Interface downstream hook.
 .It Dv l2c
-Upper layer protocol upstream hook. Usually Bluetooth L2CAP sockets layer
+Upper layer protocol upstream hook.
 Usually Bluetooth L2CAP sockets layer
 is connected to the hook.
 .It Dv ctl
-Control hook. Usually Bluetooth raw L2CAP sockets layer is connected 
+Control hook.
-to the hook.
+Usually Bluetooth raw L2CAP sockets layer is connected to the hook.
 .El
 .Sh INTERFACE TO THE UPPER LAYER PROTOCOLS (L2CA CONTROL MESSAGES)
-Bluetooth specification says that L2CA request must block until response 
+Bluetooth specification says that L2CA request must block until response
-is ready. L2CAP node uses 
+is ready.
-.Dq token 
+L2CAP node uses
-field from Netgraph message header to match L2CA request and response. The
+.Va token
-upper layer protocol must populate 
+field from Netgraph message header to match L2CA request and response.
-.Dq token . 
+The upper layer protocol must populate
-L2CAP node will queue request and start processing. Later, when response is 
+.Va token .
-ready or timeout has occur L2CAP node will create new Netgraph message, set 
+L2CAP node will queue request and start processing.
-.Dq token 
+Later, when response is
-and 
+ready or timeout has occured, L2CAP node will create new Netgraph message, set
-.Dv NFG_RESP 
+.Va token
-flag and send message to the upper layer. Note that L2CA indication messages 
+and
-will not populate 
+.Dv NFG_RESP
-.Dq token 
+flag and send message to the upper layer.
-and will not set 
+Note that L2CA indication messages
-.Dv NGF_RESP 
+will not populate
-flag. There is no reason for this, because they are just notifications and do 
+.Va token
 and will not set
 .Dv NGF_RESP
 flag.
 There is no reason for this, because they are just notifications and do
 not require acknowledgment.
-.Pp
+.Bl -tag -width indent
 .Bl -tag -width foo
 .It Dv NGM_L2CAP_L2CA_CON
-Requests the creation of a channel representing a logical connection to a 
+Requests the creation of a channel representing a logical connection to a
-physical address. Input parameters are the target protocol (PSM) and remote 
+physical address.
-device's 48-bit address (BD_ADDR). Output parameters are the local CID (LCID) 
+Input parameters are the target protocol (PSM) and remote
-allocated by the local L2CAP entity, and Result of the request. If Result 
+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.
 .It Dv NGM_L2CAP_L2CA_CON_IND
-This message includes the parameters for the address of the remote device that 
+This message includes the parameters for the address of the remote device that
-issued the connection request, the local CID representing the channel being 
+issued the connection request, the local CID representing the channel being
-requested, the Identifier contained in the request, and the PSM value the 
+requested, the Identifier contained in the request, and the PSM value the
 request is targeting.
 .It Dv NGM_L2CAP_L2CA_CON_RSP
-Issues a response to a connection request event indication. Input parameters 
+Issues a response to a connection request event indication.
-are the remote device's 48-bit address, Identifier sent in the request, local 
+Input parameters
-CID, the Response code, and the Status attached to the Response code. The 
+are the remote device's 48-bit address, Identifier sent in the request, local
-output parameter is the Result of the service request. This primitive must be 
+CID, the Response code, and the Status attached to the Response code.
-called no more than once after receiving the indication. 
+The output parameter is the Result of the service request.
 This primitive must be
 called no more than once after receiving the indication.
 .It Dv NGM_L2CAP_L2CA_CFG
-Requests the initial configuration (or reconfiguration) of a channel to a new 
+Requests the initial configuration (or reconfiguration) of a channel to a new
-set of channel parameters. Input parameters are the local CID endpoint, new 
+set of channel parameters.
-incoming receivable MTU (InMTU), new outgoing flow spec-ification, and flush 
+Input parameters are the local CID endpoint, new
-and link timeouts. Output parameters are the Result, accepted incoming MTU
+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.
 .It Dv NGM_L2CAP_L2CA_CFG_IND
-This message includes the parameters indicating the local CID of the channel 
+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 
+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 
+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.
+the incoming data.
 All other channel parameters are set to their default values
 if not provided by the remote device.
 .It Dv NGM_L2CAP_L2CA_CFG_RSP
-Issues a response to a configuration request event indication. Input parameters
+Issues a response to a configuration request event indication.
-include the local CID of the endpoint being configured, outgoing transmit MTU 
+Input parameters
-(which may be equal or less to the OutMTU parameter in the configuration 
+include the local CID of the endpoint being configured, outgoing transmit MTU
-indication event) and the accepted flowspec for incoming traffic. The output 
+(which may be equal or less to the OutMTU parameter in the configuration
-parameter is the Result value.
+indication event) and the accepted flowspec for incoming traffic.
 The output parameter is the Result value.
 .It Dv NGM_L2CAP_L2CA_QOS_IND
-This message includes the parameter indicating the address of the remote 
+This message includes the parameter indicating the address of the remote
 Bluetooth device where the QoS contract has been violated.
 .It Dv NGM_L2CAP_L2CA_DISCON
-Requests the disconnection of the channel. Input parameter is the CID 
+Requests the disconnection of the channel.
-representing the local channel endpoint. Output parameter is Result. Result 
+Input parameter is the CID representing the local channel endpoint.
-is zero if a L2CAP Disconnect Response is received, otherwise a non-zero value 
+Output parameter is Result.
-is returned. Once disconnection has been requested, no process will be able to 
+Result
-successfully read or write from the CID. 
+is zero if a 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.
 .It Dv NGM_L2CAP_L2CA_DISCON_IND
-This message includes the parameter indicating the local CID the request has 
+This message includes the parameter indicating the local CID the request has
 been sent to.
 .It Dv NGM_L2CAP_L2CA_WRITE
-Response to transfer of data request. Actual data must be received from 
+Response to transfer of data request.
 Actual data must be received from
 appropriate upstream hook and must be prepended with header defined as follows.
 .Pp
 .Bd -literal -offset indent
 /* L2CA data packet header */
 typedef struct {
@ -267,49 +323,69 @@ typedef struct {
 .Pp
 The output parameters are Result and Length of data written.
 .It Dv NGM_L2CAP_L2CA_GRP_CREATE
-Requests the creation of a CID to represent a logical connection to multiple 
+Requests the creation of a CID to represent a logical connection to multiple
-devices. Input parameter is the PSM value that the outgoing connectionless 
+devices.
-traffic is labelled with, and the filter used for incoming traffic. Output 
+Input parameter is the PSM value that the outgoing connectionless
-parameter is the CID representing the local endpoint. On creation, the group 
+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.
-.Em This request has not been implemented .
+.Bf -emphasis
 This request has not been implemented.
 .Ef
 .It Dv NGM_L2CAP_L2CA_GRP_CLOSE
 The use of this message closes down a Group.
-.Em This request has not been implemented .
+.Bf -emphasis
 This request has not been implemented.
 .Ef
 .It Dv NGM_L2CAP_L2CA_GRP_ADD_MEMBER
-Requests the addition of a member to a group. The input parameter includes the 
+Requests the addition of a member to a group.
-CID representing the group and the BD_ADDR of the group member to be added. 
+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.
-.Em This request has not been implemented .
+.Bf -emphasis
 This request has not been implemented.
 .Ef
 .It Dv NGM_L2CAP_L2CA_GRP_REM_MEMBER
-Requests the removal of a member from a group. The input parameters include 
+Requests the removal of a member from a group.
-the CID representing the group and BD_ADDR of the group member to be removed. 
+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.
-.Em This request has not been implemented .
+.Bf -emphasis
 This request has not been implemented.
 .Ef
 .It Dv NGM_L2CAP_L2CA_GRP_MEMBERSHIP
-Requests a report of the members of a group. The input parameter CID represents
+Requests a report of the members of a group.
-the group being queried. The output parameter Result confirms the success or 
+The input parameter CID represents the group being queried.
-failure of the operation. If the Result is successful, BD_ADDR_Lst is a list 
+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.
-.Em This request has not been implemented .
+.Bf -emphasis
 This request has not been implemented.
 .Ef
 .It Dv NGM_L2CAP_L2CA_PING
 Initiates a L2CA Echo Request message and the reception of the corresponding
-L2CAP Echo Response message. The input parameters are remote Bluetooth device
+L2CAP Echo Response message.
-BD_ADDR, Echo Data and Length of the echo data. The output parameters are
+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.
 .It Dv NGM_L2CAP_L2CA_GET_INFO
-Initiates a L2CA Information Request message and the reception of the 
+Initiates a L2CA Information Request message and the reception of the
-corresponding L2CAP Info Response message. The input parameters are remote 
+corresponding L2CAP Info Response message.
-Bluetooth device BD_ADDR and Information Type. The output parameters are
+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.
 .It Dv NGM_L2CAP_L2CA_ENABLE_CLT
-Request to disable (enable) the reception of connectionless packets. The input
+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. 
+(unblocked) and Enable flag.
 .El
 .Sh NETGRAPH CONTROL MESSAGES
 This node type supports the generic control messages, plus the following:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv NGM_L2CAP_NODE_GET_FLAGS
 Returns current state for the node.
 .It Dv NGM_L2CAP_NODE_GET_DEBUG
@ -323,18 +399,21 @@ Returns list of active baseband connections (i.e. ACL links).
 Returns list of active L2CAP channels.
 .El
 .Sh SHUTDOWN
-This node shuts down upon receipt of a NGM_SHUTDOWN control message, or
+This node shuts down upon receipt of an
 .Dv NGM_SHUTDOWN
 control message, or
 when all hooks have been disconnected.
 .Sh BUGS
-Most likely. Please report if found.
+Most likely.
 Please report if found.
 .Sh SEE ALSO
 .Xr netgraph 4 ,
 .Xr ngctl 8 ,
 .Xr l2control 8 ,
-.Xr l2ping 8
+.Xr l2ping 8 ,
 .Xr ngctl 8
 .Sh HISTORY
 The
-.Nm
+.Nm l2cap
 node type was implemented in
 .Fx 5.0 .
 .Sh AUTHORS
--- a/share/man/man4/ng_ubt.4
+++ b/share/man/man4/ng_ubt.4
@ -1,8 +1,6 @@
 .\" ng_ubt.4
 .\" 
 .\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
 .\" All rights reserved.
-.\" 
+.\"
 .\" Redistribution and use in source and binary forms, with or without
 .\" modification, are permitted provided that the following conditions
 .\" are met:
@ -11,7 +9,7 @@
 .\" 2. Redistributions in binary form must reproduce the above copyright
 .\"    notice, this list of conditions and the following disclaimer in the
 .\"    documentation and/or other materials provided with the distribution.
-.\" 
+.\"
 .\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@ -23,47 +21,49 @@
 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 .\" SUCH DAMAGE.
-.\" 
+.\"
 .\" $Id: ng_ubt.4,v 1.2 2002/11/12 17:20:16 max Exp $
 .\" $FreeBSD$
 .\"
 .Dd June 14, 2002
 .Dt NG_UBT 4
 .Os
 .Sh NAME
-.Nm ubt
+.Nm ng_ubt
 .Nd Netgraph node type that is also a driver for Bluetooth USB devices
 .Sh SYNOPSIS
 .In sys/types.h
 .In ng_ubt.h
 .Sh DESCRIPTION
 The
-.Nm
+.Nm ubt
 node type is both a persistent Netgraph node type and a driver for
-Bluetooth USB devices. It implements a Bluetooth USB transport layer 
+Bluetooth USB devices.
-as per chapter H2 of the Bluetooth Specification Book v1.1. A new 
+It implements a Bluetooth USB transport layer
-node is created when supported USB device is plugged.
+as per chapter H2 of the Bluetooth Specification Book v1.1.
 A new node is created when supported USB device is plugged.
 .Pp
 The node has a single hook called
 .Dv hook .
 Incoming bytes received on the device are re-assembled into HCI frames
-(according to the length). Full HCI frames are sent out on the hook. The node 
+(according to the length).
-will add HCI frame indicator if device did not send it. HCI frames received
+Full HCI frames are sent out on the hook.
-on
+The node will add HCI frame indicator if device did not send it.
 HCI frames received on
 .Dv hook
-are transmitted out. The node will drop HCI frame indicator unless device
+are transmitted out.
-requires it to be present. 
+The node will drop HCI frame indicator unless device
 requires it to be present.
 .Sh HOOKS
 This node type supports the following hooks:
-.Pp
+.Bl -tag -width indent
 .Bl -tag -width foobar
 .It Dv hook
 single HCI frame contained in single
-.Dv mbuf
+.Vt mbuf
 structure.
 .El
 .Sh CONTROL MESSAGES
 This node type supports the generic control messages, plus the following:
-.Bl -tag -width foo
+.Bl -tag -width indent
 .It Dv NGM_UBT_NODE_GET_DEBUG
 Returns an integer containing the current debug level for the node.
 .It Dv NGM_UBT_NODE_SET_DEBUG
@ -73,11 +73,11 @@ for the node.
 This command takes a parameter that specifies queue number and returns
 current maximal length of the queue for the node.
 .It Dv NGM_UBT_NODE_SET_QLEN
-This command takes two parameters that specify queue number and maximum 
+This command takes two parameters that specify queue number and maximum
 length of the queue and sets maximal length of the queue for the node.
 .It Dv NGM_UBT_NODE_GET_STAT
-Returns various statistic information for the node, such as: number of 
+Returns various statistic information for the node, such as: number of
-bytes (frames) sent, number of bytes (frames) received and number of 
+bytes (frames) sent, number of bytes (frames) received and number of
 input (output) errors.
 .It Dv NGM_UBT_NODE_RESET_STAT
 Reset all statistic counters to zero.
@ -85,17 +85,17 @@ Reset all statistic counters to zero.
 .Sh SHUTDOWN
 This node shuts down when the corresponding USB device is un-plugged.
 .Sh BUGS
-Isochronous USB transfers are probably broken. It means that USB device 
+Isochronous USB transfers are probably broken.
-probably will not be able to transfer SCO data (voice). Driver does not 
+It means that USB device probably will not be able to transfer SCO data (voice).
-support firmware upgrade procedure. USB interrupt transfers are
+Driver does not support firmware upgrade procedure.
-implemented as bulk-in transfers (not really a bug).
+USB interrupt transfers are implemented as bulk-in transfers (not really a bug).
 .Sh SEE ALSO
 .Xr usb 4 ,
 .Xr netgraph 4 ,
 .Xr usb 4 ,
 .Xr ngctl 8
 .Sh HISTORY
 The
-.Nm
+.Nm ubt
 node type was implemented in
 .Fx 5.0 .
 .Sh AUTHORS