mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-16 10:20:30 +00:00
mdoc(7) police: markup overhaul.
This commit is contained in:
parent
e3e797439e
commit
f393f49865
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=107823
@ -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
|
||||
module is a placeholder for global Bluetooth variables. All Bluetooth
|
||||
variables can be examined and changed via
|
||||
.Nm
|
||||
module is a placeholder for global Bluetooth variables.
|
||||
All Bluetooth variables can be examined and changed via
|
||||
.Xr sysctl 8 .
|
||||
.Sh BLUETOOTH VARIABLES
|
||||
Below is the description of default variables. Each Bluetooth module
|
||||
might add its own variables to the tree.
|
||||
.Bl -tag -width foobar
|
||||
.It net.bluetooth.version
|
||||
A read only integer variable that shows the current version of the
|
||||
.Ss Bluetooth Variables
|
||||
Below is the description of default variables.
|
||||
Each Bluetooth module might add its own variables to the tree.
|
||||
.Bl -tag -width indent
|
||||
.It Va net.bluetooth.version
|
||||
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
|
||||
A read-write integer variable that controls the HCI connection timeout, i.e.
|
||||
how long the HCI layer will wait for the
|
||||
.It Va net.bluetooth.hci.connection_timeout
|
||||
A read-write integer variable that controls the HCI connection timeout, i.e.\&
|
||||
how long the HCI layer will wait for the
|
||||
.Dv Connection_Complete
|
||||
event. Normaly this should not be required as Bluetooth devices have
|
||||
connection timeout of their own and will send event back. 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.
|
||||
event.
|
||||
Normaly this should not be required as Bluetooth devices have
|
||||
connection timeout of their own and will send event back.
|
||||
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 .
|
||||
.It net.bluetooth.hci.max_neighbor_age
|
||||
.Bf -emphasis
|
||||
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
|
||||
an
|
||||
entries in the HCI neighbor cache.
|
||||
Every time a Bluetooth device performs an
|
||||
.Dv Inquiry
|
||||
operation, the results will be put in cache. Later when a Bluetooth device
|
||||
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
|
||||
operation, the results will be put in cache.
|
||||
Later when a Bluetooth device
|
||||
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
|
||||
A read-write integer variable that controls the Link Layer Control and
|
||||
Adaptation Protocol (L2CAP) Retransmission Timeout (RTX) (in seconds).
|
||||
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 HCI connection timeout. Be careful when changing this variable. Make
|
||||
sure you understand what you are doing.
|
||||
.It net.bluetooth.l2cap.ertx_timeout
|
||||
A read-write integer variable that controls the L2CAP Extended Retransmission
|
||||
Timeout (ERTX) (in seconds). In some cases remote peer may respond with
|
||||
.It Va net.bluetooth.l2cap.rtx_timeout
|
||||
A read-write integer variable that controls the Link Layer Control and
|
||||
Adaptation Protocol (L2CAP) Retransmission Timeout (RTX) (in seconds).
|
||||
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 HCI connection timeout.
|
||||
Be careful when changing this variable.
|
||||
Make sure you understand what you are doing.
|
||||
.It Va net.bluetooth.l2cap.ertx_timeout
|
||||
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
|
||||
is reset to the ERTX timeout value. The value of the ERTX timeout should be
|
||||
greater or equal to the value of the RTX timeout. Be careful when changing
|
||||
this variable. Make sure you understand what you are doing.
|
||||
status to the L2CAP control command.
|
||||
In this case the L2CAP command timeout is reset to the ERTX timeout value.
|
||||
The value of the ERTX timeout should be
|
||||
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
|
||||
|
@ -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
|
||||
provide firmware with the driver. The firmware can be obtained
|
||||
from the Windows driver package that can be downloaded from the 3COM web
|
||||
site at no charge. The firmware name is BT3CPCC.BIN. To load firmware
|
||||
info the card use
|
||||
download firmware first.
|
||||
Due to copyright issues I will no longer provide firmware with the driver.
|
||||
The firmware can be obtained
|
||||
from the Windows driver package that can be downloaded from the 3COM web
|
||||
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.
|
||||
.Bd -literal -offset indent
|
||||
MD5 (BT3CPCC.BIN) = 36170fda56ea9fdbf1702c966f8a97f1
|
||||
.Ed
|
||||
I am using original firmware that came with the card on CD-ROM.
|
||||
.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
|
||||
frames received on
|
||||
(according to the length).
|
||||
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
|
||||
either direction.
|
||||
are transmitted out.
|
||||
No modification to the data is performed in either direction.
|
||||
.Sh HOOKS
|
||||
This node type supports the following hooks:
|
||||
.Pp
|
||||
.Bl -tag -width foobar
|
||||
.Bl -tag -width indent
|
||||
.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
|
||||
maximum length of the queue and sets maximum length of the queue for
|
||||
This command takes two parameters that specify queue number and and
|
||||
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
|
||||
bytes (frames) sent, number of bytes (frames) received and number of
|
||||
Returns various statistic information for the node, such as: 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
|
||||
<jop@di.uminho.pt> and disassembled W2K driver.
|
||||
The driver is based on information obtained from
|
||||
.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
|
||||
|
@ -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
|
||||
one protocol within
|
||||
module implements three Netgraph node types.
|
||||
Each type in its turn implements one protocol within
|
||||
.Dv PF_BLUETOOTH
|
||||
domain.
|
||||
.Pp
|
||||
.Sh BLUETOOTH_PROTO_HCI protocol
|
||||
.Ss SOCK_RAW HCI sockets
|
||||
.Sh Dv BLUETOOTH_PROTO_HCI Sh protocol
|
||||
.Ss Dv SOCK_RAW Ss HCI sockets
|
||||
Implemented by
|
||||
.Cm btsock_hci_raw
|
||||
Netgraph type. Raw HCI sockets allow sending of raw HCI command datagrams
|
||||
.Nm btsock_hci_raw
|
||||
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
|
||||
received with
|
||||
calls.
|
||||
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
|
||||
sockets can be used to control HCI nodes.
|
||||
which returns the next datagram with its return address.
|
||||
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
|
||||
.Xr ioctl 2
|
||||
Raw HCI sockets support number of
|
||||
.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
|
||||
HCI datagram types. For HCI event datagrams the application can set
|
||||
additional filter. The raw HCI socket filter defined as follows:
|
||||
Raw HCI sockets support filters.
|
||||
The application can filter certain HCI datagram types.
|
||||
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
|
||||
.Xr setsockopt 2
|
||||
or change via
|
||||
.Xr setsockopt 2
|
||||
raw HCI socket's filter.
|
||||
.Pp
|
||||
.Sh BLUETOOTH_PROTO_L2CAP protocol
|
||||
.Sh Dv BLUETOOTH_PROTO_L2CAP Sh 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 SOCK_RAW L2CAP sockets
|
||||
.Ss Dv SOCK_RAW Ss 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
|
||||
sockets used to control L2CAP nodes and to issue special L2CAP requests
|
||||
such as ECHO_REQUEST and GET_INFO request.
|
||||
Raw L2CAP sockets do not provide access to raw L2CAP datagrams.
|
||||
These
|
||||
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
|
||||
.Xr ioctl 2
|
||||
Raw L2CAP sockets support number of
|
||||
.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 SOCK_SEQPACKET L2CAP sockets
|
||||
.Ss Dv SOCK_SEQPACKET Ss 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
|
||||
sockets are created active; to create a passive socket the
|
||||
Active sockets initiate connections to passive sockets.
|
||||
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
|
||||
.Xr accept 2
|
||||
call to accept incoming connections. Only active sockets may use the
|
||||
.Xr connect 2
|
||||
call to initiate connections.
|
||||
system call.
|
||||
Only passive sockets may use the
|
||||
.Xr accept 2
|
||||
call to accept incoming connections.
|
||||
Only active sockets may use the
|
||||
.Xr connect 2
|
||||
call to initiate connections.
|
||||
.Pp
|
||||
L2CAP sockets supports
|
||||
.Dq wildcard addressing .
|
||||
In this case socket must be bound to
|
||||
.Dv NG_HCI_BDADDR_ANY
|
||||
address. Note that PSM (Protocol/Service Multiplexor) filed is always
|
||||
required. 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
|
||||
L2CAP sockets support
|
||||
.Dq "wildcard addressing" .
|
||||
In this case, socket must be bound to
|
||||
.Dv NG_HCI_BDADDR_ANY
|
||||
address.
|
||||
Note that PSM (Protocol/Service Multiplexor) filed is always
|
||||
required.
|
||||
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
|
||||
level which can be set with
|
||||
.Xr setsockopt 2
|
||||
and tested with
|
||||
.Dv SOL_L2CAP
|
||||
level which can be set with
|
||||
.Xr setsockopt 2
|
||||
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.
|
||||
.Em Not implemented .
|
||||
Get incoming flow specification for the socket.
|
||||
.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
|
||||
node type was implemented in
|
||||
.Nm btsock_hci_raw , btsock_l2c_raw ,
|
||||
and
|
||||
.Nm btsock_l2c
|
||||
node types were implemented in
|
||||
.Fx 5.0 .
|
||||
.Sh AUTHORS
|
||||
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com
|
||||
|
@ -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
|
||||
.Nd Netgraph node type that is also a H4 line discipline
|
||||
.Nm ng_h4
|
||||
.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
|
||||
node type is both a persistent Netgraph node type and a H4 line
|
||||
discipline. 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 corresponding line discipline,
|
||||
.Nm h4
|
||||
node type is both a persistent Netgraph node type and a H4 line
|
||||
discipline.
|
||||
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 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
|
||||
HCI frames (according to the length). Full HCI frames are sent out on
|
||||
the hook. HCI frames received on
|
||||
Incoming bytes received on the tty device are re-assembled into
|
||||
HCI frames (according to the length).
|
||||
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 foobar
|
||||
.Bl -tag -width indent
|
||||
.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
|
||||
bytes (frames) sent, number of bytes (frames) received and number of
|
||||
Returns various statistic information for the node, such as: 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
|
||||
|
@ -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
|
||||
.Nd Netgraph node type that is also a Bluetooth Host Controller Interface
|
||||
.Nm ng_hci
|
||||
.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)
|
||||
connecting portable and/or fixed electronic devices. Bluetooth operates
|
||||
in the unlicensed ISM band at 2.4 GHz. The Bluetooth protocol uses a
|
||||
combination of circuit and packet switching. Bluetooth can support an
|
||||
Bluetooth is a short-range radio link intended to replace the cable(s)
|
||||
connecting portable and/or fixed electronic devices.
|
||||
Bluetooth operates in the unlicensed ISM band at 2.4 GHz.
|
||||
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
|
||||
and synchronous voice. Each voice channel supports a 64 kb/s synchronous
|
||||
(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
|
||||
channels, or a channel which simultaneously supports asynchronous data
|
||||
and synchronous voice.
|
||||
Each voice channel supports a 64 kb/s synchronous
|
||||
(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
|
||||
Bluetooth units involved), or a point-to-multipoint connection. In the
|
||||
point-to-multipoint connection, the channel is shared among several
|
||||
Bluetooth units. Two or more units sharing the same channel form a
|
||||
.Em 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.
|
||||
The Bluetooth system provides a point-to-point connection (only two
|
||||
Bluetooth units involved), or a point-to-multipoint connection.
|
||||
In the point-to-multipoint connection,
|
||||
the channel is shared among several Bluetooth units.
|
||||
Two or more units sharing the same channel form a
|
||||
.Dq 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
|
||||
synchronized to the master. Both for active and parked slaves, the channel
|
||||
parked state.
|
||||
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
|
||||
Multiple piconets with overlapping coverage areas form a
|
||||
.Em scatternet .
|
||||
Each piconet can only have a single master. However, slaves can participate
|
||||
in different piconets on a time-division multiplex basis. In addition, a
|
||||
master in one piconet can be a slave in another piconet. The piconets shall
|
||||
not be frequency-synchronized. Each piconet has its own hopping channel.
|
||||
.Ss Time slots
|
||||
The channel is divided into time slots, each 625 usec in length. The time
|
||||
slots are numbered according to the Bluetooth clock of the piconet master.
|
||||
The slot numbering ranges from 0 to 2^27 -1 and is cyclic with a cycle length
|
||||
of 2^27. In the time slots, master and slave can transmit packets.
|
||||
.Ss SCO link
|
||||
The SCO link is a symmetric, point-to-point link between the master and a
|
||||
specific slave. The SCO link reserves slots and can therefore be considered
|
||||
as a circuit-switched connection between the master and the slave. The SCO
|
||||
link typically supports time-bounded information like voice. The master can
|
||||
support up to three SCO links to the same slave or to different slaves. A
|
||||
slave can support up to three SCO links from the same master, or two SCO
|
||||
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,
|
||||
.Pp
|
||||
Multiple piconets with overlapping coverage areas form a
|
||||
.Dq scatternet .
|
||||
Each piconet can only have a single master.
|
||||
However, slaves can participate
|
||||
in different piconets on a time-division multiplex basis.
|
||||
In addition, a master in one piconet can be a slave in another piconet.
|
||||
The piconets shall not be frequency-synchronized.
|
||||
Each piconet has its own hopping channel.
|
||||
.Ss Time Slots
|
||||
The channel is divided into time slots, each 625 usec in length.
|
||||
The time
|
||||
slots are numbered according to the Bluetooth clock of the piconet master.
|
||||
The slot numbering ranges from 0 to 2^27 -1 and is cyclic with a cycle length
|
||||
of 2^27.
|
||||
In the time slots, master and slave can transmit packets.
|
||||
.Ss SCO Link
|
||||
The SCO link is a symmetric, point-to-point link between the master and a
|
||||
specific slave.
|
||||
The SCO link reserves slots and can therefore be considered
|
||||
as a circuit-switched connection between the master and the slave.
|
||||
The SCO link typically supports time-bounded information like voice.
|
||||
The master can
|
||||
support up to three SCO links to the same slave or to different slaves.
|
||||
A
|
||||
slave can support up to three SCO links from the same master, or two SCO
|
||||
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
|
||||
manager, and access to hardware status and control registers. This interface
|
||||
The HCI provides a command interface to the baseband controller and link
|
||||
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
|
||||
of which Host Controller Transport Layer is used. HCI events are used for
|
||||
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
|
||||
The Host will receive asynchronous notifications of HCI events independent
|
||||
of which Host Controller Transport Layer is used.
|
||||
HCI events are used for
|
||||
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,
|
||||
a Command Complete event is sent to the Host. Some commands do not receive
|
||||
a Command Complete event when they have been completed. Instead, when the
|
||||
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
|
||||
from the Host.
|
||||
When the Host Controller completes most of the commands,
|
||||
a Command Complete event is sent to the Host.
|
||||
Some commands do not receive
|
||||
a Command Complete event when they have been completed.
|
||||
Instead, when the
|
||||
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
|
||||
header) that can be sent from the Host to the Host Controller. There are also
|
||||
two additional return parameters that specify the total number of HCI ACL and
|
||||
SCO data packets that the Host Controller can have waiting for transmission in
|
||||
its buffers.
|
||||
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
|
||||
two additional return parameters that specify the total number of HCI ACL and
|
||||
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
|
||||
will receive a
|
||||
bit for the node.
|
||||
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
|
||||
.Em connection handle
|
||||
and queue of outgoing data packets. Upper layers protocols are allowed to
|
||||
send up to (
|
||||
.Dv num_pkts -
|
||||
SCO link).
|
||||
Each baseband connection has
|
||||
.Dq "connection handle"
|
||||
and queue of outgoing data packets.
|
||||
Upper layers protocols are allowed to
|
||||
send up to
|
||||
.Dv ( num_pkts
|
||||
\-
|
||||
.Dv pending )
|
||||
packets at one time. HCI layer will send
|
||||
.Dv NGM_HCI_SYNC_CON_QUEUE
|
||||
Netgraph messages to inform upper layers about current queue state for each
|
||||
connection handle. The
|
||||
.Dv NGM_HCI_SYNC_CON_QUEUE
|
||||
packets at one time.
|
||||
HCI layer will send
|
||||
.Dv NGM_HCI_SYNC_CON_QUEUE
|
||||
Netgraph messages to inform upper layers about current queue state for each
|
||||
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 foobar
|
||||
.Bl -tag -width indent
|
||||
.It Dv drv
|
||||
Bluetooth Host Controller Transport Layer hook. Single HCI packet contained in
|
||||
single
|
||||
.Dv mbuf
|
||||
Bluetooth Host Controller Transport Layer hook.
|
||||
Single HCI packet contained in single
|
||||
.Vt mbuf
|
||||
structure.
|
||||
.It Dv acl
|
||||
Upper layer protocol/node is connected to the hook. Single HCI ACL
|
||||
data packet contained in single
|
||||
.Dv mbuf
|
||||
Upper layer protocol/node is connected to the hook.
|
||||
Single HCI ACL data packet contained in single
|
||||
.Vt mbuf
|
||||
structure.
|
||||
.It Dv sco
|
||||
Upper layer protocol/node is connected to the hook. Single HCI SCO
|
||||
data packet contained in single
|
||||
.Dv mbuf
|
||||
Upper layer protocol/node is connected to the hook.
|
||||
Single HCI SCO data packet contained in single
|
||||
.Vt mbuf
|
||||
structure.
|
||||
.It Dv raw
|
||||
Raw hook. Every HCI frame (including HCI command frame) that goes in
|
||||
or out will be delivired to the hook. Usually Bluetooth raw HCI sockets
|
||||
layer is connected to the hook. Single HCI frame contained in single
|
||||
. Dv mbuf
|
||||
Raw hook.
|
||||
Every HCI frame (including HCI command frame) that goes in
|
||||
or out will be delivired to the hook.
|
||||
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
|
||||
NGM_HCI_LP_CON_REQ request to establish a lower layer (baseband) connection.
|
||||
This includes passing the authentication challenge if authentication is
|
||||
.Dv NGM_HCI_LP_CON_REQ
|
||||
request to establish a lower layer (baseband) connection.
|
||||
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
|
||||
incoming connection.
|
||||
Indicates the lower protocol (baseband) has successfully established
|
||||
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
|
||||
could be a response to
|
||||
Indicates the lower protocol (baseband) has terminated connection.
|
||||
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
|
||||
created the HCI node will try set link policy for the ACL connection. By
|
||||
default every supported Link Manager (LM) mode will be enabled. User can
|
||||
override this by setting link policy settings mask which specifies LM
|
||||
Sets current link policy settings mask.
|
||||
After the new ACL connection is
|
||||
created the HCI node will try set link policy for the ACL connection.
|
||||
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
|
||||
|
@ -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
|
||||
node type is a Netgraph node type that implements Bluetooth Logical Link
|
||||
.Nm l2cap
|
||||
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
|
||||
.Bl -enum -offset indent
|
||||
.Ss L2CAP Assumptions
|
||||
.Bl -enum -offset indent
|
||||
.It
|
||||
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 1 ACL link exists between any two devices.
|
||||
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 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 .
|
||||
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
|
||||
.Dq channels .
|
||||
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.
|
||||
.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
|
||||
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.
|
||||
.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
|
||||
.Bl -tag -width foobar
|
||||
.Ss Channel Operational States
|
||||
.Bl -tag -width indent
|
||||
.It Dv NG_L2CAP_CLOSED
|
||||
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 NG_L2CAP_CLOSED state.
|
||||
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
|
||||
.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
|
||||
Request message has been sent referencing this endpoint and it is now waiting
|
||||
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.
|
||||
.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
|
||||
response may require a security check to be performed.
|
||||
received L2CAP Connect Request waits for the corresponding response.
|
||||
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
|
||||
entered when the channel parameters are being renegotiated. Prior to entering
|
||||
the NG_L2CAP_CONFIG state, all outgoing data traffic is suspended since
|
||||
the traffic parameters of the data traffic are to be renegotiated. Incoming
|
||||
negotiating the channel parameters.
|
||||
The Configuration state may also be
|
||||
entered when the channel parameters are being renegotiated.
|
||||
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
|
||||
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,
|
||||
the
|
||||
.Dv NG_L2CAP_CONFIG
|
||||
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
|
||||
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
|
||||
incrementally.
|
||||
Moving from the
|
||||
.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
|
||||
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
|
||||
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.
|
||||
.El
|
||||
.Ss Protocol Multiplexing
|
||||
L2CAP supports protocol multiplexing because the Baseband Protocol does not
|
||||
support any
|
||||
.Dq type
|
||||
field identifying the higher layer protocol being multiplexed above it.
|
||||
L2CAP is able to distinguish between upper layer protocols such as the Service
|
||||
L2CAP supports protocol multiplexing because the Baseband Protocol does not
|
||||
support any
|
||||
.Dq type
|
||||
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.
|
||||
.Ss Segmentation and Reassembly
|
||||
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.
|
||||
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.
|
||||
.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
|
||||
synchronously hopping together using the same clock. The L2CAP group
|
||||
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.
|
||||
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
|
||||
to the hook.
|
||||
Control 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
|
||||
is ready. L2CAP node uses
|
||||
.Dq token
|
||||
field from Netgraph message header to match L2CA request and response. The
|
||||
upper layer protocol must populate
|
||||
.Dq token .
|
||||
L2CAP node will queue request and start processing. Later, when response is
|
||||
ready or timeout has occur L2CAP node will create new Netgraph message, set
|
||||
.Dq token
|
||||
and
|
||||
.Dv NFG_RESP
|
||||
flag and send message to the upper layer. Note that L2CA indication messages
|
||||
will not populate
|
||||
.Dq token
|
||||
and will not set
|
||||
.Dv NGF_RESP
|
||||
flag. There is no reason for this, because they are just notifications and do
|
||||
Bluetooth specification says that L2CA request must block until response
|
||||
is ready.
|
||||
L2CAP node uses
|
||||
.Va token
|
||||
field from Netgraph message header to match L2CA request and response.
|
||||
The upper layer protocol must populate
|
||||
.Va token .
|
||||
L2CAP node will queue request and start processing.
|
||||
Later, when response is
|
||||
ready or timeout has occured, L2CAP node will create new Netgraph message, set
|
||||
.Va token
|
||||
and
|
||||
.Dv NFG_RESP
|
||||
flag and send message to the upper layer.
|
||||
Note that L2CA indication messages
|
||||
will not populate
|
||||
.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 foo
|
||||
.Bl -tag -width indent
|
||||
.It Dv NGM_L2CAP_L2CA_CON
|
||||
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
|
||||
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.
|
||||
.It Dv NGM_L2CAP_L2CA_CON_IND
|
||||
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
|
||||
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.
|
||||
.It Dv NGM_L2CAP_L2CA_CON_RSP
|
||||
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.
|
||||
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.
|
||||
.It Dv NGM_L2CAP_L2CA_CFG
|
||||
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
|
||||
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.
|
||||
.It Dv NGM_L2CAP_L2CA_CFG_IND
|
||||
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.
|
||||
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.
|
||||
.It Dv NGM_L2CAP_L2CA_CFG_RSP
|
||||
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.
|
||||
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.
|
||||
.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
|
||||
representing the local channel endpoint. Output parameter is Result. Result
|
||||
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.
|
||||
Requests the disconnection of the channel.
|
||||
Input parameter is the CID representing the local channel endpoint.
|
||||
Output parameter is Result.
|
||||
Result
|
||||
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
|
||||
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
|
||||
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.
|
||||
.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
|
||||
CID representing the group and the BD_ADDR of the group member to be added.
|
||||
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.
|
||||
.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
|
||||
the CID representing the group and BD_ADDR of the group member to be removed.
|
||||
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.
|
||||
.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
|
||||
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
|
||||
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.
|
||||
.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
|
||||
BD_ADDR, Echo Data and Length of the echo data. The output parameters are
|
||||
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.
|
||||
.It Dv NGM_L2CAP_L2CA_GET_INFO
|
||||
Initiates a 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
|
||||
Initiates a 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.
|
||||
.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
|
||||
|
@ -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
|
||||
as per chapter H2 of the Bluetooth Specification Book v1.1. A new
|
||||
node is created when supported USB device is plugged.
|
||||
Bluetooth USB devices.
|
||||
It implements a Bluetooth USB transport layer
|
||||
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
|
||||
will add HCI frame indicator if device did not send it. HCI frames received
|
||||
on
|
||||
(according to the length).
|
||||
Full HCI frames are sent out on the hook.
|
||||
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
|
||||
requires it to be present.
|
||||
are transmitted out.
|
||||
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 foobar
|
||||
.Bl -tag -width indent
|
||||
.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
|
||||
bytes (frames) sent, number of bytes (frames) received and number of
|
||||
Returns various statistic information for the node, such as: 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
|
||||
probably will not be able to transfer SCO data (voice). Driver does not
|
||||
support firmware upgrade procedure. USB interrupt transfers are
|
||||
implemented as bulk-in transfers (not really a bug).
|
||||
Isochronous USB transfers are probably broken.
|
||||
It means that USB device probably will not be able to transfer SCO data (voice).
|
||||
Driver does not support firmware upgrade procedure.
|
||||
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
|
||||
|
Loading…
Reference in New Issue
Block a user