d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Reapply mdoc(7) fixes that got accidentally lost in the last

Browse Source 
Bluetooth update, and fix a few more issues.

Submitted by:	Maksim Yevmenkin <m_evmenkin@yahoo.com>, ru
Approved by:	re (blanket)
This commit is contained in:
Ruslan Ermilov 2003-05-20 21:01:21 +00:00
parent 7f4725bd09
commit 72f00208e5
Notes: svn2git 2020-12-20 02:59:44 +00:00 
svn path=/head/; revision=115185
18 changed files with 1233 additions and 1024 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
share/man/man4/ng_bluetooth.4
View File

@ -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,81 +21,91 @@
.\" 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 2003/04/26 22:38:25 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.
Normally 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.max_neighbor_age
.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

87
share/man/man4/ng_bt3c.4
View File

@ -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,47 @@
.\" 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.1 2002/11/24 19:37:54 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 +71,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 +103,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 +121,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

234
share/man/man4/ng_btsocket.4
View File

@ -1,5 +1,3 @@
.\" ng_btsocket.4
.\"
.\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
.\" All rights reserved.
.\"
@ -26,6 +24,7 @@
.\"
.\" $Id: ng_btsocket.4,v 1.6 2003/03/18 00:09:34 max Exp $
.\" $FreeBSD$
.\"
.Dd July 8, 2002
.Dt NG_BTSOCKET 4
.Os
@ -36,30 +35,29 @@
.In sys/types.h
.In sys/socket.h
.In bitstring.h
.In netgraph.h
.In ng_hci.h
.In ng_l2cap.h
.In ng_btsocket.h
.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
@ -117,14 +115,15 @@ Sets new value of the role switch parameter for the HCI node.
.El
.Pp
The
.Dv net.bluetooth.hci.sockets.raw.ioctl_timeout
variable, that can be examined and set via
.Va net.bluetooth.hci.sockets.raw.ioctl_timeout
variable, that can be examined and set via
.Xr sysctl 8 ,
controls the control request timeout (in seconds) for raw HCI sockets.
.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.
@ -139,17 +138,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 */
@ -160,19 +158,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
@ -185,69 +187,80 @@ 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
The
.Dv net.bluetooth.l2cap.sockets.raw.ioctl_timeout
variable, that can be examined and set via
.Va net.bluetooth.l2cap.sockets.raw.ioctl_timeout
variable, that can be examined and set via
.Xr sysctl 8 ,
controls the control request timeout (in seconds) for raw L2CAP sockets.
.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 support
.Dq wildcard addressing .
In this case socket must be bound to
.Dv NG_HCI_BDADDR_ANY
address. Note that PSM (Protocol/Service Multiplexor) field 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
.Dq "wildcard addressing" .
In this case, socket must be bound to
.Dv NG_HCI_BDADDR_ANY
address.
Note that PSM (Protocol/Service Multiplexor) field is always required.
Once a connection has been established, the socket's address is
fixed by the peer entity's location.
The address assigned to 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 at the L2CAP layer .
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 at the L2CAP layer .
.Bf -emphasis
Not implemented.
.Ef
.It Dv SO_L2CAP_FLUSH
Get (set) value of the flush timeout.
.Em Not implemeted at the L2CAP layer .
.Bf -emphasis
Not implemented.
.Ef
.El
.Pp
.Sh BLUETOOTH_PROTO_RFCOMM protocol
.Sh Dv BLUETOOTH_PROTO_RFCOMM Sh protocol
The Bluetooth RFCOMM socket address is defined as follows:
.Bd -literal -offset indent
/* Bluetooth version of struct sockaddr for RFCOMM sockets */
@ -258,73 +271,76 @@ struct sockaddr_rfcomm {
u_int8_t rfcomm_channel; /* channel */
};
.Ed
.Pp
.Ss SOCK_STREAM RFCOMM sockets
Note that RFCOMM sockets do not have associated Netgraph node type. RFCOMM
sockets are implemented as additional layer on top of L2CAP sockets. RFCOMM
sockets are either
.Ss Dv SOCK_STREAM Ss RFCOMM sockets
Note that RFCOMM sockets do not have associated Netgraph node type.
RFCOMM sockets are implemented as additional layer on top of L2CAP sockets.
RFCOMM sockets are either
.Dq active
or
.Dq passive .
Active sockets initiate connections to passive sockets. By default RFCOMM
sockets are created active; to create a passive socket the
Active sockets initiate connections to passive sockets.
By default, RFCOMM 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
RFCOMM sockets support
.Dq wildcard addressing .
In this case socket must be bound to
.Dv NG_HCI_BDADDR_ANY
address. Note that RFCOMM channel field 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,
.Dq "wildcard addressing" .
In this case, socket must be bound to
.Dv NG_HCI_BDADDR_ANY
address.
Note that RFCOMM channel field is always required.
Once a connection has been established, the socket's address is fixed by the
peer entity's location.
The address assigned to the socket is the address associated with the
Bluetooth device through which packets are being transmitted and received,
and RFCOMM channel.
.Pp
The following options, which can be tested with
The following options, which can be tested with
.Xr getsockopt 2
call, are defined at
.Dv SOL_RFCOMM
call, are defined at
.Dv SOL_RFCOMM
level for RFCOMM sockets:
.Bl -tag -width foo
.It SO_RFCOMM_MTU
Returns the maximum transfer unit size (in bytes) for the underlying RFCOMM
channel. Note that application still can write/read bigger chunks to/from the
socket.
.It SO_RFCOMM_FC_INFO
.Bl -tag -width indent
.It Dv SO_RFCOMM_MTU
Returns the maximum transfer unit size (in bytes) for the underlying RFCOMM
channel.
Note that application still can write/read bigger chunks to/from the socket.
.It Dv SO_RFCOMM_FC_INFO
Return the flow control information for the underlying RFCOMM channel.
.El
.Pp
The
.Dv net.bluetooth.rfcomm.sockets.stream.timeout
variable, that can be examined and set via
.Va net.bluetooth.rfcomm.sockets.stream.timeout
variable, that can be examined and set via
.Xr sysctl 8 ,
controls the connection timeout (in seconds) for RFCOMM sockets.
.Pp
.Sh HOOKS
These node types support hooks with arbitrary names (as long as they are
These node types support hooks with arbitrary names (as long as they are
unique) and always accept hook connection requests.
.Sh NETGRAPH CONTROL MESSAGES
These node types support 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 sysctl 8 ,
.Xr ng_bluetooth 4 ,
.Xr ng_hci 4 ,
.Xr ng_l2cap 4 ,
.Xr btsockstat 1
.Xr ngctl 8 ,
.Xr sysctl 8
.Sh HISTORY
The
.Nm

54
share/man/man4/ng_h4.4
View File

@ -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,16 @@
.\" 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.1 2002/11/24 19:37:54 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 +38,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 +66,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 +97,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 +107,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 +118,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

312
share/man/man4/ng_hci.4
View File

@ -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,16 @@
.\" 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.2 2003/03/18 00:09:34 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 +39,99 @@
.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 successfully 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 delivered to the hook.
Usually the Bluetooth raw HCI socket 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,40 +342,47 @@ 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.
.It NGM_HCI_NODE_GET_PACKET_MASK
Returns current packet mask.
.It NGM_HCI_NODE_SET_ROLE_SWITCH
Sets the value of the role switch. Role switch is enabled when this value is
not zero. This is the default state. Note that actual role switch at Bluetooth
link level will only be perfomed if hardware supports role switch and it was
enabled.
Sets the value of the role switch.
Role switch is enabled when this value is not zero.
This is the default state.
Note that actual role switch at Bluetooth link level will only be perfomed if
hardware supports role switch and it was enabled.
.It NGM_HCI_NODE_GET_ROLE_SWITCH
Returns the value of the role switch for the node.
.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

395
share/man/man4/ng_l2cap.4
View File

@ -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,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_l2cap.4,v 1.2 2003/04/28 20:16:29 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 +40,162 @@ 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
@ -174,88 +212,104 @@ L2CAP does not support the concept of a global group name.
.Sh HOOKS
This node type supports the following hooks:
.Pp
.Bl -tag -width foobar
.Bl -tag -width indent
.It Dv hci
Bluetooth Host Controller Interface downstream hook.
.It Dv l2c
Upper layer protocol upstream hook. Usually Bluetooth L2CAP sockets layer
is connected to the hook.
Upper layer protocol upstream hook.
Usually the Bluetooth L2CAP socket 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 an L2CAP Disconnect Response is received, otherwise a non-zero value
is returned.
Once disconnection has been requested, no process will be able to
successfully read or write from the CID.
.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 +321,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
Initiates an L2CA Echo Request message and the reception of the corresponding
L2CAP Echo Response message.
The input parameters are remote Bluetooth device
BD_ADDR, Echo Data and Length of the echo data.
The output parameters are
Result, Echo Data and Length of the echo data.
.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 an L2CA Information Request message and the reception of the
corresponding L2CAP Info Response message.
The input parameters are remote Bluetooth device BD_ADDR and Information Type.
The output parameters are
Result, Information Data and Size of the information data.
.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
@ -326,22 +400,25 @@ Returns an integer containing the current value of the auto disconnect
timeout (in sec).
.It Dv NGM_L2CAP_NODE_SET_AUTO_DISCON_TIMO
This command accepts an integer and sets the value of the auto disconnect
timeout (in sec). The special value of 0 (zero) disables auto disconnect
timeout.
timeout (in sec).
The special value of 0 (zero) disables auto disconnect timeout.
.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

106
share/man/man4/ng_ubt.4
View File

@ -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,50 @@
.\" 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 2003/03/22 23:44:32 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,53 +74,56 @@ 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.
.It Dv NGM_UBT_NODE_DEV_NODES
This command takes single integer parameter. If the parameter's value
is not zero then the driver will create device nodes for the control,
interrupt, bulk-in and bulk-out endpoints. If the parameter's value is
zero then the driver will destroy device nodes for the endpoints. The
device nodes interface is mutually exclusive with Netgraph interface.
This command takes single integer parameter.
If the parameter's value is not zero, then the driver will create device nodes
for the control, interrupt, bulk-in and bulk-out endpoints.
If the parameter's value is zero, then the driver will destroy device nodes
for the endpoints.
The device nodes interface is mutually exclusive with Netgraph interface.
.El
.Sh DEVICE NODES INTERFACE
The
.Nm
driver can create or destroy endpoint device nodes on request. This
feature can be used to implement external firmware download utility.
.Nm ubt
driver can create or destroy endpoint device nodes on request.
This feature can be used to implement external firmware download utility.
.Pp
The control transfers can only happen on the control endpoint which
is always endpoint 0. Control request are issued by
is always endpoint 0.
Control requests are issued by
.Xr ioctl 2
calls.
.Pp
Only incoming transfers are supported on an interrupt endpoint. To perform I/O
on an interrupt endpoint
Only incoming transfers are supported on an interrupt endpoint.
To perform I/O on an interrupt endpoint,
.Xr read 2
should be used. All I/O operations on a interrupt endpoint are unbuffered.
should be used.
All I/O operations on an interrupt endpoint are unbuffered.
.Pp
The bulk transfers can be in or out depending on the endpoint. To perform
I/O on a bulk endpoint
The bulk transfers can be in or out depending on the endpoint.
To perform I/O on a bulk endpoint,
.Xr read 2
and
and
.Xr write 2
should be used. All I/O operations on a bulk endpoint are unbuffered.
should be used.
All I/O operations on a bulk endpoint are unbuffered.
.Pp
The control endpoint (endpoint 0) handles the following
.Xr ioctl 2
calls:
.Bl -tag -width foo
.Bl -tag -width indent
.It Dv USB_GET_DEVICE_DESC Pq Vt usb_device_descriptor_t
Return the device descriptor.
.It Dv USB_GET_STRING_DESC Pq Vt "struct usb_string_desc"
Get a string descriptor for the given language ID and
string index.
Get a string descriptor for the given language ID and string index.
.Bd -literal
struct usb_string_desc {
int string_index;
@ -153,18 +157,18 @@ struct usb_ctl_request {
};
.Ed
This is a dangerous operation in that it can perform arbitrary operations
on the device. Some of the most dangerous (e.g., changing the device
address) are not allowed.
on the device.
Some of the most dangerous (e.g., changing the device address) are not allowed.
.It Dv USB_GET_DEVICEINFO Pq Vt "struct usb_device_info"
Get an information summary for the device. This call will not issue any USB
transactions.
Get an information summary for the device.
This call will not issue any USB transactions.
.El
.Sh SHUTDOWN
This node shuts down when the corresponding USB device is un-plugged.
.Sh BUGS
Isochronous USB transfers are broken. It means that USB device will not be able
to transfer SCO data (voice). USB interrupt transfers are implemented as bulk-in
transfers (not really a bug).
Isochronous USB transfers are broken.
It means that USB device will not be able to transfer SCO data (voice).
USB interrupt transfers are implemented as bulk-in transfers (not really a bug).
.Sh FILES
.Bl -tag -width ".Pa /dev/ubt Ns Ar N Ns Pa \&. Ns Ar EE" -compact
.It Pa /dev/ubt Ns Ar N Ns Pa \&. Ns Ar EE
@ -174,13 +178,13 @@ of device
.Ar N .
.El
.Sh SEE ALSO
.Xr usb 4 ,
.Xr ugen 4 ,
.Xr netgraph 4 ,
.Xr ugen 4 ,
.Xr usb 4 ,
.Xr ngctl 8
.Sh HISTORY
The
.Nm
.Nm ubt
node type was implemented in
.Fx 5.0 .
.Sh AUTHORS

40
share/man/man4/ubtbcmfw.4
View File

@ -1,8 +1,6 @@
.\" ubtbcmfw.4
.\"
.\" Copyright (c) 2003 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,9 +21,10 @@
.\" 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: ubtbcmfw.4,v 1.1 2003/04/28 17:09:46 max Exp $
.\" $FreeBSD$
.\"
.Dd April 28, 2003
.Dt UBTBCMFW 4
.Os
@ -39,37 +38,40 @@ is a firmware driver for Broadcom BCM2033 chip based Bluetooth USB devices.
It provides minimal access to the parts of the device required to download
firmware.
.Pp
The
.Nm
driver creates three fixed endpoint device nodes.
.Pp
The control transfers can only happen on the control endpoint which
is always endpoint 0. Control request are issued by
is always endpoint 0.
Control request are issued by
.Xr ioctl 2
calls.
.Pp
Only incoming transfers are supported on an interrupt endpoint. To perform I/O
on an interrupt endpoint
Only incoming transfers are supported on an interrupt endpoint.
To perform I/O on an interrupt endpoint,
.Xr read 2
should be used. All I/O operations on a interrupt endpoint are unbuffered.
should be used.
All I/O operations on a interrupt endpoint are unbuffered.
Interrupt endpoint is always endpoint 1.
.Pp
Only outgoing bulk transfers are supported on a bulk endpoint. To perform
I/O on a bulk endpoint
Only outgoing bulk transfers are supported on a bulk endpoint.
To perform I/O on a bulk endpoint,
.Xr write 2
should be used. All I/O operations on a bulk endpoint are unbuffered. Outgoing
bulk endpoint is always enpoint 2.
should be used.
All I/O operations on a bulk endpoint are unbuffered.
Outgoing bulk endpoint is always enpoint 2.
.Pp
The control endpoint (endpoint 0) handles the following
.Xr ioctl 2
calls:
.Bl -tag -width foo
.Bl -tag -width indent
.It Dv USB_GET_DEVICE_DESC Pq Vt usb_device_descriptor_t
Return the device descriptor.
.El
.Sh BUGS
This code
.Em was not
tested on a real BCM2033 based hardware.
Most likely.
Please report if found.
.Sh FILES
.Bl -tag -width ".Pa /dev/ubtbcmfw Ns Ar N Ns Pa \&. Ns Ar EE" -compact
.It Pa /dev/ubtbcmfw Ns Ar N Ns Pa \&. Ns Ar EE
@ -79,9 +81,9 @@ of device
.Ar N .
.El
.Sh SEE ALSO
.Xr usb 4 ,
.Xr ugen 4 ,
.Xr ng_ubt 4 ,
.Xr ugen 4 ,
.Xr usb 4 ,
.Xr bcmfw 8
.Sh HISTORY
The

42
usr.bin/bluetooth/btsockstat/btsockstat.1
View File

@ -1,5 +1,3 @@
.\" btsockstat.1
.\"
.\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
.\" All rights reserved.
.\"
@ -26,6 +24,7 @@
.\"
.\" $Id: btsockstat.1,v 1.4 2003/04/27 19:25:15 max Exp $
.\" $FreeBSD$
.\"
.Dd August 31, 2002
.Dt BTSOCKSTAT 1
.Os
@ -34,43 +33,46 @@
.Nd show Bluetooth sockets information
.Sh SYNOPSIS
.Nm
.Op Fl p Ar protocol
.Op Fl r
.Op Fl rh
.Op Fl M Ar core
.Op Fl h
.Op Fl p Ar protocol
.Sh DESCRIPTION
The
.Nm
command symbolically displays the contents of various Bluetooth sockets
related data structures. There are few output formats, depending on the
options for the information presented.
.Nm
will print results to the standard output and error messages to the
utility symbolically displays the contents of various Bluetooth sockets
related data structures.
There are few output formats, depending on the
options for the information presented.
The
.Nm
utility
will print results to the standard output and error messages to the
standard error.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl h
Display usage message and exit.
.It Fl M Ar core
Extract values associated with the name list from the specified core
instead of the default
.Pa /dev/kmem .
.It Fl p Ar protocol
Display a list of active sockets (protocol control blocks) for each
specified protocol. Supported protocols are:
Display a list of active sockets (protocol control blocks) for each
specified protocol.
Supported protocols are:
.Cm hci_raw , l2cap_raw , l2cap, rfcomm
and
.Cm rfcomm_s .
.It Fl r
Display a list of active routing entries (if any) for specified protocol.
.It Fl M Ar core
Extract values associated with the name list from the specified core
instead of the default
.Pa /dev/kmem .
.It Fl h
Display usage message and exit.
.El
.Sh BUGS
Most likely. Please report if found.
Most likely.
Please report if found.
.Sh DIAGNOSTICS
.Ex -std
.Sh SEE ALSO
.Xr ng_btsocket 4
.Sh AUTHORS
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com

77
usr.bin/bluetooth/rfcomm_sppd/rfcomm_sppd.1
View File

@ -1,8 +1,6 @@
.\" rfcomm_pppd.1
.\"
.\" Copyright (c) 2001-2003 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,9 +21,10 @@
.\" 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: rfcomm_sppd.1,v 1.1 2003/04/26 23:55:34 max Exp $
.\" $FreeBSD$
.\"
.Dd April 26, 2003
.Dt RFCOMM_SPPD 1
.Os
@ -34,61 +33,66 @@
.Nd RFCOMM Serial Port Profile daemon
.Sh SYNOPSIS
.Nm
.Op Fl a Ar BD_ADDR
.Op Fl b
.Op Fl c Ar channel
.Op Fl t Ar tty
.Op Fl h
.Op Fl bh
.Fl a Ar BD_ADDR
.Fl c Ar channel
.Fl t Ar tty
.Sh DESCRIPTION
The
.Nm
is a Serial Port Profile daemon. It opens RFCOMM connection to the
specified server's BD_ADDR and channel. Once connection is established
utility is a Serial Port Profile daemon.
It opens RFCOMM connection to the specified server's
.Ar BD_ADDR
and
.Ar channel .
Once connection is established, the
.Nm
provides access to the server's remote serial port via
utility provides access to the server's remote serial port via
.Xr pty 4
interface.
.Pp
The
.Nm
opens both master and slave pseudo terminals. This is done to ensure that
RFCOMM connection stays open until
utility opens both master and slave pseudo terminals.
This is done to ensure that RFCOMM connection stays open until
.Nm
is terminated. The data received from the master pseudo terminal are sent over
the RFCOMM connection. The data received from the RFCOMM connection are written
into master pseudo terminal. The application in its turn opens slave pseudo
is terminated.
The data received from the master pseudo terminal are sent over
the RFCOMM connection.
The data received from the RFCOMM connection are written
into master pseudo terminal.
The application in its turn opens the slave pseudo
terminal and operates on it just like it would operate over the standard serial
port.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl a Ar BD_ADDR
This requied option specifies the remote BD_ADDR of the RFCOMM server.
This required option specifies the remote BD_ADDR of the RFCOMM server.
.It Fl b
Detach from the controlling terminal, i.e. run in background.
Detach from the controlling terminal, i.e., run in background.
.It Fl c Ar channel
This required option specifies RFCOMM channel to connect to. This channel
must provide Serial Port service.
.It Fl t Ar tty
Slave pseudo tty name.
This required option specifies RFCOMM channel to connect to.
This channel must provide Serial Port service.
.It Fl h
Display usage message and exit.
.It Fl t Ar tty
Slave pseudo tty name.
.El
.Sh EXAMPLES
.Bl -tag -width indent
.It rfcomm_sppd -a 00:01:02:03:04:05 -c 1 -t /dev/ttyp1
.Dl "rfcomm_sppd -a 00:01:02:03:04:05 -c 1 -t /dev/ttyp1"
.Pp
Will start
Will start the
.Nm
and open RFCOMM connection to the server at
.Em 00:01:02:03:04:05
and channel
.Em 1 .
Once connection has been established
utility and open RFCOMM connection to the server at
.Li 00:01:02:03:04:05
and channel
.Li 1 .
Once the connection has been established,
.Pa /dev/ttyp1
can be used to talk to the remote serial port on the server.
.El
.Sh FILES
.Bl -tag -width /dev/tty[p-sP-S][0-9a-v]x -compact
.Bl -tag -width ".Pa /dev/tty[p-sP-S][0-9a-v]" -compact
.It Pa /dev/pty[p-sP-S][0-9a-v]
master pseudo terminals
.It Pa /dev/tty[p-sP-S][0-9a-v]
@ -97,11 +101,12 @@ slave pseudo terminals
.Sh DIAGNOSTICS
.Ex -std
.Sh BUGS
The
.Nm
currently is not integrated with SDP (Service Discovery Protocol).
utility is not currently integrated with SDP (Service Discovery Protocol).
.Sh SEE ALSO
.Xr pty 4 ,
.Xr ng_btsocket 4 ,
.Xr pty 4 ,
.Xr rfcomm_pppd 8
.Sh AUTHORS
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com

72
usr.sbin/bluetooth/bcmfw/bcmfw.8
View File

@ -1,8 +1,6 @@
.\" bcmfw.8
.\"
.\" Copyright (c) 2003 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,74 +21,72 @@
.\" 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: bcmfw.8,v 1.4 2003/04/28 17:10:56 max Exp $
.\" $FreeBSD$
.\"
.Dd March 31, 2003
.Dt BCMFW 8
.Os
.Sh NAME
.Nm BCMFW
.Nd Firmware download utility for Broadcom BCM2033 chip based Bluetooth USB devices
.Nm bcmfw
.Nd firmware download utility for Broadcom BCM2033 chip based Bluetooth USB devices
.Sh SYNOPSIS
.Nm
.Op Fl n Ar device name
.Op Fl m Ar mini-driver file name
.Op Fl f Ar firmware file name
.Op Fl h
.Fl f Ar firmware_file_name
.Fl m Ar mini-driver_file_name
.Fl n Ar device_name
.Sh DESCRIPTION
The
.Nm
utility downloads specified mini-driver and firmware files to the specified
utility downloads the specified mini-driver and firmware files to the specified
device.
.Pp
This utility will
.Em only
work with Broadcom BCM2033 chip based Bluetooth USB devices. The identification
is currently based on USB vendor ID/product ID pair. The vendor ID should be
0x0a5c (
.Dv USB_VENDOR_BROADCOM
) and the product ID should be 0x2033.
work with Broadcom BCM2033 chip based Bluetooth USB devices.
The identification is currently based on USB vendor ID/product ID pair.
The vendor ID should be 0x0a5c
.Pq Dv USB_VENDOR_BROADCOM
and the product ID should be 0x2033.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl n Ar device name
Specify device name.
.It Fl m Ar mini-driver file name
Specify mini-driver file name for download.
.It Fl f Ar firmware file name
.It Fl f Ar firmware_file_name
Specify firmware file name for download.
.It Fl h
Display usage message and exit.
.It Fl m Ar mini-driver_file_name
Specify mini-driver file name for download.
.It Fl n Ar device_name
Specify device name.
.El
.Sh FILES
.Bl -tag -width xxxxxxxxxxxxxxxxx -compact
.It BCM2033-MD.hex
.Bl -tag -width ".Pa /dev/ubtbcmfw Ns Ar N Ns Pa \&. Ns Ar EE" -compact
.It Pa BCM2033-MD.hex
Mini-driver image.
.It BCM2033-FW.bin
.It Pa BCM2033-FW.bin
Firmware image.
.It Pa /dev/ubtbcmfw Ns Ar N Ns Pa \&. Ns Ar EE
.It Pa /dev/ubtbcmfw Ns Ar N Ns Pa \&. Ns Ar EE
Endpoint
.Ar EE
of device
of device
.Ar N .
.El
.Sh Examples
.Bl -tag -width foo
.It bcmfw -n ubtbcmfw0 -m BCM2033-MD.hex -f BCM2033-FW.bin
.Sh EXAMPLES
To download the firmware into the
.Pa /dev/ubtbcmfw0
device:
.Pp
Will download firmware into
.Pa /dev/ubtbcmfw Ns Ar 0
device.
.El
.Dl "bcmfw -n ubtbcmfw0 -m BCM2033-MD.hex -f BCM2033-FW.bin"
.Sh BUGS
Most likely. Please report if found. This code
.Em was not
tested on a real BCM2033 based hardware.
Most likely.
Please report if found.
.Sh DIAGNOSTICS
.Ex -std
.Sh SEE ALSO
.Xr ugen 4 ,
.Xr ubtbcmfw 4
.Xr ubtbcmfw 4 ,
.Xr ugen 4
.Sh AUTHORS
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com

45
usr.sbin/bluetooth/bt3cfw/bt3cfw.8
View File

@ -1,8 +1,6 @@
.\" bt3cfw.8
.\"
.\" 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,44 +21,47 @@
.\" 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: bt3cfw.8,v 1.3 2003/04/27 19:45:22 max Exp $
.\" $FreeBSD$
.\"
.Dd November 11, 2002
.Dt BT3CFW 8
.Os
.Sh NAME
.Nm BT3CFW
.Nd Firmware download utility for 3Com Bluetooth PC card driver
.Nm bt3cfw
.Nd firmware download utility for 3Com Bluetooth PC card driver
.Sh SYNOPSIS
.Nm
.Op Fl n Ar Netgraph node name
.Op Fl f Ar Firmware file name
.Op Fl h
.Fl f Ar Firmware_file_name
.Fl n Ar Netgraph_node_name
.Sh DESCRIPTION
The
.Nm
utility connects to the specified Netgraph driver node of type
utility connects to the specified Netgraph driver node of type
.Dv BTCCC
and downloads specified firmware file.
and downloads the specified firmware file.
.Pp
Due to copyright issues I will no longer provide firmware with the card
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. I'm using original firmware that came with the card on CD-ROM.
.Bd -literal -offset indent
MD5 (BT3CPCC.BIN) = 36170fda56ea9fdbf1702c966f8a97f1
.Ed
Due to copyright issues, I will no longer provide firmware with the card
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 .
I am using the original firmware that came with the card on CD-ROM.
.Pp
.Dl "MD5 (BT3CPCC.BIN) = 36170fda56ea9fdbf1702c966f8a97f1"
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl n Ar Netgraph node name
Connect to the specified Netgraph driver node of type
.Dv BTCCC .
.It Fl f Ar Firmware file name
.It Fl f Ar Firmware_file_name
Specify firmware file name for download.
.It Fl h
Display usage message and exit.
.It Fl n Ar Netgraph_node_name
Connect to the specified Netgraph driver node of type
.Dv BTCCC .
.El
.Sh BUGS
Please report if found.

199
usr.sbin/bluetooth/hccontrol/hccontrol.8
View File

@ -1,8 +1,6 @@
.\" hccontrol.8
.\"
.\" 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,9 +21,10 @@
.\" 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: hccontrol.8,v 1.3 2003/04/27 19:45:23 max Exp $
.\" $FreeBSD$
.\"
.Dd June 14, 2002
.Dt HCCONTROL 8
.Os
@ -34,34 +33,36 @@
.Nd HCI configuration utility
.Sh SYNOPSIS
.Nm
.Op Fl n Ar HCI node name
.Op Fl h
.Op Ar command
.Fl n Ar HCI_node_name
.Ar command
.Op Ar parameters ...
.Sh DESCRIPTION
The
.Nm
utility connects to the specified Netgraph node of type
.Em HCI
and attempts to send specified command to the HCI Netgraph node or to the
.Dv HCI
and attempts to send specified command to the HCI Netgraph node or to the
associated Bluetooth device.
The
.Nm
will print results to the standard output and error messages to
utility will print results to the standard output and error messages to
the standard error.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl n Ar HCI node name
Connect to the specified HCI Netgraph node.
.It Fl h
Display usage message and exit.
.It command
One of the supported commands (see below). Special command
.Dq help
can be used to obtain the list of all supported commands. To get more
information about specific command use
.Dq help command .
.It parameters
.It Fl n Ar HCI_node_name
Connect to the specified HCI Netgraph node.
.It Ar command
One of the supported commands (see below).
Special command
.Cm help
can be used to obtain the list of all supported commands.
To get more information about specific command use
.Cm help Ar command .
.It Ar parameters
One or more optional space separated command parameters.
.El
.Sh COMMANDS
@ -69,92 +70,92 @@ The currently supported HCI commands in
.Nm
are:
.Pp
.Bd -literal -offset indent -compact
Inquiry
Create_Connection
Disconnect
Add_SCO_Connection
Change_Connection_Packet_Type
Remote_Name_Request
Read_Remote_Supported_Features
Read_Remote_Version_Information
Read_Clock_Offset
Role_Discovery
Switch_Role
Read_Link_Policy_Settings
Write_Link_Policy_Settings
Reset
Read_Pin_Type
Write_Pin_Type
Read_Stored_Link_Key
Write_Stored_Link_Key
Delete_Stored_Link_Key
Change_Local_Name
Read_Local_Name
Read_Connection_Accept_Timeout
Write_Connection_Accept_Timeout
Read_Page_Timeout
Write_Page_Timeout
Read_Scan_Enable
Write_Scan_Enable
Read_Page_Scan_Activity
Write_Page_Scan_Activity
Read_Inquiry_Scan_Activity
Write_Inquiry_Scan_Activity
Read_Authentication_Enable
Write_Authentication_Enable
Read_Encryption_Mode
Write_Encryption_Mode
Read_Class_Of_Device
Write_Class_Of_Device
Read_Voice_Settings
Write_Voice_Settings
Read_Number_Broadcast_Retransmissions
Write_Number_Broadcast_Retransmissions
Read_Hold_Mode_Activity
Write_Hold_Mode_Activity
Read_SCO_Flow_Control_Enable
Write_SCO_Flow_Control_Enable
Read_Link_Supervision_Timeout
Write_Link_Supervision_Timeout
Read_Local_Version_Information
Read_Local_Supported_Features
Read_Buffer_Size
Read_Country_Code
Read_BD_ADDR
Read_Failed_Contact_Counter
Reset_Failed_Contact_Counter
Get_Link_Quality
Read_RSSI
.Ed
.Bl -tag -offset indent -compact
.It Cm Inquiry
.It Cm Create_Connection
.It Cm Disconnect
.It Cm Add_SCO_Connection
.It Cm Change_Connection_Packet_Type
.It Cm Remote_Name_Request
.It Cm Read_Remote_Supported_Features
.It Cm Read_Remote_Version_Information
.It Cm Read_Clock_Offset
.It Cm Role_Discovery
.It Cm Switch_Role
.It Cm Read_Link_Policy_Settings
.It Cm Write_Link_Policy_Settings
.It Cm Reset
.It Cm Read_Pin_Type
.It Cm Write_Pin_Type
.It Cm Read_Stored_Link_Key
.It Cm Write_Stored_Link_Key
.It Cm Delete_Stored_Link_Key
.It Cm Change_Local_Name
.It Cm Read_Local_Name
.It Cm Read_Connection_Accept_Timeout
.It Cm Write_Connection_Accept_Timeout
.It Cm Read_Page_Timeout
.It Cm Write_Page_Timeout
.It Cm Read_Scan_Enable
.It Cm Write_Scan_Enable
.It Cm Read_Page_Scan_Activity
.It Cm Write_Page_Scan_Activity
.It Cm Read_Inquiry_Scan_Activity
.It Cm Write_Inquiry_Scan_Activity
.It Cm Read_Authentication_Enable
.It Cm Write_Authentication_Enable
.It Cm Read_Encryption_Mode
.It Cm Write_Encryption_Mode
.It Cm Read_Class_Of_Device
.It Cm Write_Class_Of_Device
.It Cm Read_Voice_Settings
.It Cm Write_Voice_Settings
.It Cm Read_Number_Broadcast_Retransmissions
.It Cm Write_Number_Broadcast_Retransmissions
.It Cm Read_Hold_Mode_Activity
.It Cm Write_Hold_Mode_Activity
.It Cm Read_SCO_Flow_Control_Enable
.It Cm Write_SCO_Flow_Control_Enable
.It Cm Read_Link_Supervision_Timeout
.It Cm Write_Link_Supervision_Timeout
.It Cm Read_Local_Version_Information
.It Cm Read_Local_Supported_Features
.It Cm Read_Buffer_Size
.It Cm Read_Country_Code
.It Cm Read_BD_ADDR
.It Cm Read_Failed_Contact_Counter
.It Cm Reset_Failed_Contact_Counter
.It Cm Get_Link_Quality
.It Cm Read_RSSI
.El
.Pp
The currently supported node commands in
.Nm
are:
.Pp
.Bd -literal -offset indent -compact
Read_Node_State
Initialize
Read_Debug_Level
Write_Debug_Level
Read_Node_Buffer_Size
Read_Node_BD_ADDR
Read_Node_Features
Read_Node_Stat
Reset_Node_Stat
Flush_Neighbor_Cache
Read_Neighbor_Cache
Read_Connection_List
Read_Node_Link_Policy_Settings_Mask
Write_Node_Link_Policy_Settings_Mask
Read_Node_Packet_Mask
Write_Node_Packet_Mask
Read_Node_Role_Switch
Write_Node_Role_Switch
.Ed
.Pp
.Bl -tag -offset indent -compact
.It Cm Read_Node_State
.It Cm Initialize
.It Cm Read_Debug_Level
.It Cm Write_Debug_Level
.It Cm Read_Node_Buffer_Size
.It Cm Read_Node_BD_ADDR
.It Cm Read_Node_Features
.It Cm Read_Node_Stat
.It Cm Reset_Node_Stat
.It Cm Flush_Neighbor_Cache
.It Cm Read_Neighbor_Cache
.It Cm Read_Connection_List
.It Cm Read_Node_Link_Policy_Settings_Mask
.It Cm Write_Node_Link_Policy_Settings_Mask
.It Cm Read_Node_Packet_Mask
.It Cm Write_Node_Packet_Mask
.It Cm Read_Node_Role_Switch
.It Cm Write_Node_Role_Switch
.El
.Sh BUGS
Most likely. Please report if found.
Most likely.
Please report if found.
.Sh DIAGNOSTICS
.Ex -std
.Sh SEE ALSO

71
usr.sbin/bluetooth/hcsecd/hcsecd.8
View File

@ -1,5 +1,3 @@
.\" hcsecd.8
.\"
.\" Copyright (c) 2001-2002 Maksim Yevmenkin <m_evmenkin@yahoo.com>
.\" All rights reserved.
.\"
@ -26,6 +24,7 @@
.\"
.\" $Id: hcsecd.8,v 1.3 2003/04/27 19:45:32 max Exp $
.\" $FreeBSD$
.\"
.Dd November 16, 2002
.Dt HCSECD 8
.Os
@ -34,68 +33,74 @@
.Nd control link keys and PIN codes for Bluetooth devices
.Sh SYNOPSIS
.Nm
.Op Fl f Ar configfile
.Op Fl d
.Op Fl h
.Op Fl dh
.Fl f Ar configfile
.Sh DESCRIPTION
The
.Nm
daemon controls link keys and PIN code for Bluetooth devices. It opens raw
HCI socket and listens for the
daemon controls link keys and PIN code for Bluetooth devices.
It opens raw HCI socket and listens for the
.Dv Link_Key_Request
and
.Dv PIN_Code_Request
HCI events. Once appropriate HCI event has been received, the daemon will
scan configuration file for matching entry. The remove device BD_ADDR is used
as a key. If no matching entry was found then the default entry will be used.
If no default entry was found than it is assumed no link key and no PIN code
exist. For any given entry link key takes precedence over PIN code. If link key
was not specified then it means device must generate link key from PIN code. If
entry was found and has the link key (or PIN code) then
the
HCI events.
Once appropriate HCI event has been received, the daemon will
scan configuration file for matching entry.
The remove device BD_ADDR is used as a key.
If no matching entry was found, the default entry will be used.
If no default entry was found then it is assumed that no link key and no PIN code
exist.
For any given entry, link key takes precedence over PIN code.
If link key was not specified, it means device must generate link key from
PIN code.
If entry was found and has the link key (or PIN code) then the
.Dv Link_Key_Request_Reply
(or
.Dv PIN_Code_Request_Reply
) command will be sent back to the device. Otherwise the
.Dv PIN_Code_Request_Reply )
command will be sent back to the device.
Otherwise, the
.Dv Link_Key_Request_Negative_Reply
(or
.Dv PIN_Code_Request_Negative_Reply
) command will be sent back to the device.
.Dv PIN_Code_Request_Negative_Reply )
command will be sent back to the device.
.Pp
The
.Nm
daemon currently does not handle HCI
.Dv Link_Key_Notification
event and does not cache link keys created from the PIN codes. It means
that the link key only exists while connection is opened. After the connection
has been terminated the user will have to enter PIN code again.
.Dv Link_Key_Notification
event and does not cache link keys created from the PIN codes.
It means that the link key only exists while connection is opened.
After the connection has been terminated, the user will have to enter PIN code
again.
.Pp
The command line options are as follows:
.Bl -tag -width Ds
.It Fl f Ar filename
Name of configuration file. Default is
.Pa /usr/local/etc/hcsecd.conf .
.Bl -tag -width indent
.It Fl d
Do not detach from the controlling terminal.
.It Fl f Ar configfile
Specify name of the configuration file.
The default is
.Pa /usr/local/etc/hcsecd.conf .
.It Fl h
Display usage message and exit.
.El
.Sh BUGS
Currently there is no way to select link key or PIN code based on which local
device received the request. Everything is based on remote device BD_ADDR.
Also might implement interface for external helpers to obtain link keys and
Currently there is no way to select link key or PIN code based on which local
device received the request.
Everything is based on remote device BD_ADDR.
Also might implement interface for external helpers to obtain link keys and
PIN codes.
.Sh FILES
.Bl -tag -width /etc/usbd.conf -compact
.Bl -tag -width ".Pa /usr/local/etc/hcsecd.conf" -compact
.It Pa /usr/local/etc/hcsecd.conf
.It Pa /var/run/hcsecd.pid
.El
.Sh SEE ALSO
.Xr netgraph 3 ,
.Xr netgraph 4 ,
.Xr ng_hci 4 ,
.Xr ng_btsocket 4 ,
.Xr ng_hci 4 ,
.Xr hccontrol 8 ,
.Xr hcseriald 8
.Xr hcseriald 8
.Sh AUTHORS
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com

66
usr.sbin/bluetooth/hcseriald/hcseriald.8
View File

@ -1,8 +1,6 @@
.\" hcseriald.8
.\"
.\" 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,9 +21,10 @@
.\" 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: hcseriald.8,v 1.2 2003/04/27 19:45:33 max Exp $
.\" $FreeBSD$
.\"
.Dd June 14, 2002
.Dt HCSERIALD 8
.Os
@ -34,51 +33,54 @@
.Nd supervise serial Bluetooth devices
.Sh SYNOPSIS
.Nm
.Op Fl f Ar device
.Op Fl n Ar node name
.Op Fl dh
.Fl f Ar device
.Fl n Ar node_name
.Op Fl s Ar speed
.Op Fl d
.Op Fl h
.Sh DESCRIPTION
The
.Nm
handles serial Bluetooth devices. It does one simple thing. It opens
specified serial device, sets device parameters and pushes
.Em H4
utility handles serial Bluetooth devices.
It does one simple thing:
it opens the specified serial device, sets the device parameters, and pushes
the
.Dv H4
line discipline.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl f Ar device
Callout device name. Example:
.Fl f
.Pa /dev/cuaa0 .
.It Fl n Ar node name
Set H4 Netgraph node name. Example:
.Fl n Ar sio0 .
.It Fl s Ar speed
Set serial device speed to
.Em speed .
Example:
.Fl s Ar 115200 .
.It Fl d
Do not disassociate from the controlling terminal, i.e. run in foreground.
Do not disassociate from the controlling terminal, i.e., run in foreground.
.It Fl f Ar device
Callout device name.
Example:
.Fl f Pa /dev/cuaa0 .
.It Fl h
Display usage message and exit.
.It Fl n Ar node_name
Set H4 Netgraph node name.
Example:
.Fl n Li sio0 .
.It Fl s Ar speed
Set serial device speed to
.Ar speed .
Example:
.Fl s Li 115200 .
.El
.Sh FILES
.Bl -tag -width /dev/consolectl -compact
.It Pa /var/run/hcserial.*.pid
process id of the currently running
.Bl -tag -width ".Pa /var/run/hcserial. Ns Ar * Ns Pa .pid" -compact
.It Pa /var/run/hcserial. Ns Ar * Ns Pa .pid
Process ID of the currently running
.Nm
daemon. Where
.Dq *
is a H4 Netgraph node name.
daemon.
Where
.Ar *
is an H4 Netgraph node name.
.El
.Sh SEE ALSO
.Xr tty 4 ,
.Xr ng_h4 4 ,
.Xr ng_hci 4 ,
.Xr tty 4 ,
.Xr hccontrol 8
.Sh AUTHORS
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com

61
usr.sbin/bluetooth/l2control/l2control.8
View File

@ -1,8 +1,6 @@
.\" l2control.8
.\"
.\" 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,9 +21,10 @@
.\" 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: l2control.8,v 1.3 2003/04/27 19:45:34 max Exp $
.\" $FreeBSD$
.\"
.Dd June 14, 2002
.Dt L2CONTROL 8
.Os
@ -34,33 +33,36 @@
.Nd L2CAP configuration utility
.Sh SYNOPSIS
.Nm
.Op Fl a Ar local BD_ADDR
.Op Fl h
.Op Ar command
.Fl a Ar BD_ADDR
.Ar command
.Op Ar parameters ...
.Sh DESCRIPTION
The
.Nm
utility connects to the local device with specified BD_ADDR and attempts
to send specified command.
utility connects to the local device with the specified BD_ADDR and attempts
to send the specified command.
The
.Nm
will print results to the standard output and error messages to
utility will print results to the standard output and error messages to
the standard error.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl a Ar local BD_ADDR
Connect to the local device with specified BD_ADDR. Example:
.Fl a Ar 00:01:02:03:04:05 .
.It Fl a Ar BD_ADDR
Connect to the local device with the specified BD_ADDR.
Example:
.Fl a Li 00:01:02:03:04:05 .
.It Fl h
Display usage message and exit.
.It command
One of the supported commands (see below). Special command
.Dq help
can be used to obtain the list of all supported commands. To get more
information about specific command use
.Dq help command .
.It parameters
.It Ar command
One of the supported commands (see below).
Special command
.Cm help
can be used to obtain the list of all supported commands.
To get more information about specific command use
.Cm help Ar command .
.It Ar parameters
One or more optional space separated command parameters.
.El
.Sh COMMANDS
@ -68,16 +70,15 @@ The currently supported node commands in
.Nm
are:
.Pp
.Bd -literal -offset indent -compact
Read_Node_Flags
Read_Debug_Level
Write_Debug_Level
Read_Connection_List
Read_Channel_List
Read_Auto_Disconnect_Timeout
Write_Auto_Disconnect_Timeout
.Ed
.Pp
.Bl -tag -offset indent -compact
.It Cm Read_Node_Flags
.It Cm Read_Debug_Level
.It Cm Write_Debug_Level
.It Cm Read_Connection_List
.It Cm Read_Channel_List
.It Cm Read_Auto_Disconnect_Timeout
.It Cm Write_Auto_Disconnect_Timeout
.El
.Sh DIAGNOSTICS
.Ex -std
.Sh SEE ALSO

74
usr.sbin/bluetooth/l2ping/l2ping.8
View File

@ -1,8 +1,6 @@
.\" l2ping.8
.\"
.\" 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,9 +21,10 @@
.\" 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: l2ping.8,v 1.2 2003/04/27 19:45:35 max Exp $
.\" $FreeBSD$
.\"
.Dd June 14, 2002
.Dt L2PING 8
.Os
@ -34,51 +33,62 @@
.Nd send L2CAP ECHO_REQUEST to remote devices
.Sh SYNOPSIS
.Nm
.Op Fl a Ar remote BD_ADDR
.Op Fl S Ar source BD_ADDR
.Op Fl fh
.Fl a Ar BD_ADDR
.Op Fl c Ar count
.Op Fl f
.Op Fl i Ar delay
.Op Fl S Ar BD_ADDR
.Op Fl s Ar size
.Op Fl h
.Sh DESCRIPTION
The
.Nm
uses L2CAP ECHO_REQUEST datagram to elicit a L2CAP ECHO_RESPONSE from a
remote device.
utility uses L2CAP
.Dv ECHO_REQUEST
datagram to elicit an L2CAP
.Dv ECHO_RESPONSE
from a remote device.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl a Ar remote BD_ADDR
Address of remote device to ping. Example:
.Fl a Ar 00:01:02:03:04:05 .
.It Fl S Ar source BD_ADDR
Send L2CAP ECHO_REQUEST from local device that has BD_ADDR. Example:
.Fl S Ar 00:05:04:03:02:01 .
.It Fl a Ar BD_ADDR
Address of remote device to ping.
Example:
.Fl a Li 00:01:02:03:04:05 .
.It Fl c Ar count
Number of packets to send. If this option is not specified,
Number of packets to send.
If this option is not specified,
.Nm
will operate until interrupted.
.It Fl f
.Dq Flood
ping, i.e. no delay between packets.
.It Fl i Ar wait
Wait
.Em wait
seconds between sending each packet. The default is to wait for one
second between each packet. This option is ignored if
.Fl f
has been specified.
.It Fl s Ar size
Specify the number of payload bytes to be sent. The default is 64. The
maximum size is 65531. Use this option with caution. Some implementations
may not like large sizes and may hang or even crash.
ping, i.e., no delay between packets.
.It Fl h
Display usage message and exit.
.It Fl i Ar wait
Wait
.Ar wait
seconds between sending each packet.
The default is to wait for one second between each packet.
This option is ignored if
.Fl f
has been specified.
.It Fl S Ar BD_ADDR
Send L2CAP
.Dv ECHO_REQUEST
from local device that has
.Ar BD_ADDR .
Example:
.Fl S Li 00:05:04:03:02:01 .
.It Fl s Ar size
Specify the number of payload bytes to be sent.
The default is 64.
The maximum size is 65531.
Use this option with caution.
Some implementations may not like large sizes and may hang or even crash.
.El
.Sh BUGS
Could collect more statistic. Could check for duplicated, corrupted
and lost packets.
Could collect more statistic.
Could check for duplicated, corrupted and lost packets.
.Sh DIAGNOSTICS
.Ex -std
.Sh SEE ALSO

220
usr.sbin/bluetooth/rfcomm_pppd/rfcomm_pppd.8
View File

@ -1,8 +1,6 @@
.\" rfcomm_pppd.8
.\"
.\" Copyright (c) 2001-2003 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,9 +21,10 @@
.\" 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: rfcomm_pppd.8,v 1.5 2003/04/27 19:45:37 max Exp $
.\" $FreeBSD$
.\"
.Dd February 4, 2003
.Dt RFCOMM_PPPD 8
.Os
@ -34,96 +33,117 @@
.Nd RFCOMM PPP daemon
.Sh SYNOPSIS
.Nm
.Fl c
.Op Fl dh
.Fl a Ar BD_ADDR
.Fl C Ar channel
.Fl l Ar label
.Nm
.Fl s
.Op Fl dh
.Op Fl a Ar BD_ADDR
.Op Fl c
.Op Fl C Ar channel
.Op Fl d
.Op Fl h
.Op Fl l Ar label
.Op Fl s
.Fl C Ar channel
.Fl l Ar label
.Sh DESCRIPTION
The
.Nm
daemon is a simple wrapper daemon that allows to use standard
.Nm ppp
on RFCOMM connection. It can operate in two modes: client and server.
.Xr ppp 8
on RFCOMM connection.
It can operate in two modes: client and server.
.Pp
In the client mode
.Nm
opens a RFCOMM connection to the specified server's BD_ADRR and channel.
Once RFCOMM connection is established
In the client mode,
.Nm
opens an RFCOMM connection to the specified server's
.Ar BD_ADRR
and
.Ar channel .
Once RFCOMM connection is established,
.Nm
executes
.Nm ppp
.Xr ppp 8
in
.Dq direct
mode with the specified label. The
.Nm ppp
in its turn operates over the RFCOMM connection just like it would operate
.Fl direct
mode with the specified
.Ar label .
The
.Xr ppp 8
in its turn operates over the RFCOMM connection just like it would operate
over the standard serial port thus allowing user to
.Dq dial out
.Dq "dial out"
and connect to the Internet.
.Pp
In the server mode
In the server mode,
.Nm
opens a RFCOMM socket and listens for incomming connections from remote
clients. Once new incomming connection is accepted
opens an RFCOMM socket and listens for incomming connections from remote clients.
Once the new incomming connection is accepted,
.Nm
forks and executes
.Nm ppp
.Xr ppp 8
in
.Dq direct
mode with the specified label. The
.Nm ppp
in its turn operates over the RFCOMM connection just like it would operate over
.Fl direct
mode with the specified
.Ar label .
The
.Xr ppp 8
in its turn operates over the RFCOMM connection just like it would operate over
the standard serial port thus providing network connectivity to remote clients.
.Pp
The options are as follows:
.Bl -tag -width indent
.It Fl a Ar BD_ADDR
In the client mode this requied option specifies the remote BD_ADDR of the
RFCOMM server. In the server mode this option can be used to specify the local
BD_ADDR to listen on. By default server will listen on
In the client mode, this required option specifies the remote BD_ADDR of the
RFCOMM server.
In the server mode, this option can be used to specify the local
BD_ADDR to listen on.
By default, server will listen on
.Dv ANY
address.
.It Fl c
Act as RFCOMM client. This is the default mode.
.It Fl C Ar channel
In both client and server modes this required option specifies RFCOMM channel
In both client and server modes, this required option specifies RFCOMM channel
to connect to or listen on.
.It Fl c
Act as an RFCOMM client.
This is the default mode.
.It Fl d
Do not detach from the controlling terminal, i.e. run in foreground.
Do not detach from the controlling terminal, i.e., run in foreground.
.It Fl h
Display usage message and exit.
.It Fl l Ar label
In both client and server modes this required option specifies which PPP label
will be used.
In both client and server modes, this required option specifies which
.Xr ppp 8
label will be used.
.It Fl s
Act as RFCOMM server.
Act as an RFCOMM server.
.El
.Sh PPP CONFIGURATION
.Ss Important notes on PPP configuration
Special attention is required when adding new RFCOMM configurations to the
existing PPP configuration. Please keep in mind that PPP will
.Ss Important Notes on PPP Configuration
Special attention is required when adding new RFCOMM configurations to the
existing PPP configuration.
Please keep in mind that PPP will
.Em always
execute commands in the
.Dq default
.Dq Li default
label of your
.Pa /etc/ppp/ppp.conf
file. Please make sure that the
.Dq default
label
file.
Please make sure that the
.Dq Li default
label
.Em only
contains commands that apply to
.Em every
other label. If you need to use PPP for both dialing out and accepting incoming
other label.
If you need to use PPP for both dialing out and accepting incoming
RFCOMM connections, please make sure you have moved all commands related to
dialing out from the
.Dq default
section into appropriate outgoing label.
.Ss RFCOMM server
One of the typical examples is LAN access. In this example RFCOMM connection
is used as a null-modem connection between client and server. Both client
.Dq Li default
section into an appropriate outgoing label.
.Ss RFCOMM Server
One of the typical examples is the LAN access.
In this example, RFCOMM connection
is used as a null-modem connection between client and server.
Both client
and server will start talking PPP right after RFCOMM connection was established.
.Bd -literal -offset indent
rfcomm-server:
@ -139,11 +159,13 @@ rfcomm-server:
disable chap
deny chap
.Ed
.Ss RFCOMM client
.Ss RFCOMM Client
The
.Nm
supports both LAN and DUN (DialUp Networking) access. The client's
configuration for the LAN access is very similar to server's and might
look like this.
utility
supports both LAN and DUN (Dial-Up Networking) access.
The client's configuration for the LAN access is very similar to server's and
might look like this.
.Bd -literal -offset indent
rfcomm-client:
enable lqr
@ -160,14 +182,17 @@ rfcomm-client:
disable chap
.Ed
.Pp
The client's configuration for the DUN access is different. In this scenario
the client gets connected to the virtual serial port on the server. To open a
PPP session client must dial a number. Note that by default
.Nm ppp
will not execute any configured chat scripts. The
.Dq force-scripts
option can be used to override this behavior. The example of such configuration
is shown below.
The client's configuration for the DUN access is different.
In this scenario, the client gets connected to the virtual serial port on the
server.
To open a PPP session, client must dial a number.
Note that by default
.Xr ppp 8
will not execute any configured chat scripts.
The
.Ic force-scripts
option can be used to override this behavior.
The example of such configuration is shown below.
.Bd -literal -offset indent
rfcomm-dialup:
# This is IMPORTANT option
@ -178,8 +203,8 @@ rfcomm-dialup:
set authkey
set phone "*99***1#"
# You might want to adjust dial string as well
set dial "ABORT BUSY ABORT NO\\\sCARRIER TIMEOUT 5 \\
# You might want to adjust dial string as well
set dial "ABORT BUSY ABORT NO\\\\sCARRIER TIMEOUT 5 \\
\\"\\" AT OK-AT-OK ATE1Q0 OK \\\\dATD\\\\T TIMEOUT 40 CONNECT"
set login
set timeout 30
@ -190,57 +215,60 @@ rfcomm-dialup:
add default HISADDR
.Ed
.Pp
Note that by adjusting initialization string one can make CSD (Circuit
Note that by adjusting the initialization string, one can make CSD (Circuit
Switched Data), HSCSD (High Speed Circuit Switched Data) or GPRS (General
Packet Radio Service) connection. The availability of the particular connection
Packet Radio Service) connection.
The availability of the particular connection
type depends on the phone model and service plan activated on the phone.
.Sh EXAMPLES
.Bl -tag -width indent
.It rfcomm_pppd -s -a 00:01:02:03:04:05 -C 1 -l rfcomm-server
.Dl "rfcomm_pppd -s -a 00:01:02:03:04:05 -C 1 -l rfcomm-server"
.Pp
Will start
This command will start
.Nm
in the server mode. The RFCOMM server will listen on local address
.Em 00:01:02:03:04:05
and channel
.Em 1 .
Once incomming connection has been accepted
in the server mode.
The RFCOMM server will listen on local address
.Li 00:01:02:03:04:05
and channel
.Li 1 .
Once the incomming connection has been accepted,
.Nm
will execute
.Nm ppp
.Xr ppp 8
in
.Dq direct
.Fl direct
mode with
.Dq rfcomm-server
.Dq Li rfcomm-server
label.
.It rfcomm_pppd -c -a 00:01:02:03:04:05 -C 1 -l rfcomm-client
.Pp
Will start
.Dl "rfcomm_pppd -c -a 00:01:02:03:04:05 -C 1 -l rfcomm-client"
.Pp
This command will start
.Nm
in the client mode.
.Nm
will try to connect to the RFCOMM server at
.Em 00:01:02:03:04:05
address and channel
.Em 1 .
Once connected the
will try to connect to the RFCOMM server at
.Li 00:01:02:03:04:05
address and channel
.Li 1 .
Once connected, the
.Nm
will execute
.Nm ppp
in
.Dq direct
.Xr ppp 8
in
.Fl direct
mode with
.Dq rfcomm-client
.Dq Li rfcomm-client
label.
.El
.Sh DIAGNOSTICS
.Ex -std
.Sh BUGS
The
.Nm
currently is not integrated with SDP (Service Discovery Protocol).
utility
is not currently integrated with the SDP (Service Discovery Protocol).
.Sh SEE ALSO
.Xr ppp 8 ,
.Xr rfcomm_sppd 1 ,
.Xr ng_btsocket 4 ,
.Xr rfcomm_sppd 1
.Xr ppp 8
.Sh AUTHORS
.An Maksim Yevmenkin Aq m_evmenkin@yahoo.com