Reapply mdoc(7) fixes that got accidentally lost in the last
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:
parent
7f4725bd09
commit
72f00208e5
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user