23.4. Bluetooth

23.4.1. Introducción

Bluetooth es una tecnología inalámbrica que opera en banda de 2.4 GHz (donde no se necesita licencia). Se trata de una tecnología pensada para la creación de redes de ámbito personal (de cobertura reducida, normalmente de unos 10 metros). Las redes se suelen construir en modo “ad-hoc” utilizando dispositivos heterogéneos como teléfonos móviles, dispositivos manuales (“handhelds”) y computadoras portátiles. A diferencia de otras tecnologías inalámbricas como Wi-Fi, Bluetooth ofrece perfiles de servicio más detallados; por ejemplo un perfil para actuar como un servidor de ficheros basado en FTP, para la difusión de ficheros (“file pushing”), para el transporte de voz, para la emulación de línea serie y muchos más.

La pila de Bluetooth en FreeBSD se implementa utilizando el entorno de Netgraph (véase netgraph(4)). La mayoría de los dispositivos USB Bluetooth se pueden utilizar mediante el controlador ng_ubt(4). Los dispositivos Bluetooth basados en el chip Broadcom BCM2033 están soportados mediante los controladores ubtbcmfw(4) y ng_bt3c(4). Los dispositivos Bluetooth basados en la interfaz serie o de Rayos Infrarrojos (UART) se controlan mediante sio(4), ng_h4(4) y hcseriald(8). Este capítulo describe el uso de dispositivos Bluetooth USB. El soporte para Bluetooth se encuentra en las versiones de FreeBSD 5.0 y posteriores.

23.4.2. Instalación del Dispositivo

Por defecto los controladores de los dispositivos Bluetooth se encuentran disponibles como módulos del kernel. Antes de enchufar el dispositivo Bluetooth se debe cargar el módulo correspondiente dentro del núcleo.

# kldload ng_ubt

Si el dispositivo Bluetooth se encuentra conectado cuando el sistema arranca se debe cargar el módulo modificando a tal efecto el fichero /boot/loader.conf.

ng_ubt_load="YES"

Al conectar el dispositivo Bluetooth aparecerá en la consola (o en syslog) la siguiente información:

ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
      wMaxPacketSize=49, nframes=6, buffer size=294

Se debe copiar /usr/share/examples/netgraph/bluetooth/rc.bluetooth a algún lugar más conveniente, por ejemplo /etc/rc.bluetooth. Este script se usa para ejecutar y detener la pila Bluetooth del sistema. Se suele recomendar quitar la pila antes de desenchufar el dispositivo pero si no se hace no debería producirse ningún desastre. Cuando se arranca la pila aparece un mensaje similar a este:

# /etc/rc.bluetooth start ubt0
BD_ADDR: 00:02:72:00:d4:1a
Features: 0xff 0xff 0xf 00 00 00 00 00
<3-Slot> <5-Slot> <Encryption> <Slot offset>
<Timing accuracy> <Switch> <Hold mode> <Sniff mode>
<Park mode> <RSSI> <Channel quality> <SCO link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
<Paging scheme> <Power control> <Transparent SCO data>
Max. ACL packet size: 192 bytes
Number of ACL packets: 8
Max. SCO packet size: 64 bytes
Number of SCO packets: 8

23.4.3. Interfaz de la Controladora de la Máquina (HCI)

La interfaz de la Controladora de la Máquina (Host Controller Interface) proporciona una interfaz de comandos para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control. Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base. La capa HCI de la máquina intercambia comandos y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas.

Se crea un nodo Netgraph de tipo HCI para cada dispositivo Bluetooth. El nodo Netgraph HCI se conecta normalmente con el nodo que representa el controlador del dispositivo Bluetooth de la máquina (sentido de bajada) y con el nodo Netgraph L2CAP en el sentido de subida. Todas las operaciones HCI se realizan sobre el nodo Netgraph HCI y no sobre el el nodo que representa al dispositivo. El nombre por defecto para el nodo HCI es “devicehci”. Para obtener más detalles, por favor consulte la página del manual de ng_hci(4).

Una de las tareas más importantes que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Esta operación o otras operaciones HCI relacionadas se realizan mediante la utilidad hccontrol(8). El siguiente ejemplo muestra cómo descubrir dispositivos en pocos segundos. Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo descubrimiento (discoverable mode).

% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
       BD_ADDR: 00:80:37:29:19:a4
       Page Scan Rep. Mode: 0x1
       Page Scan Period Mode: 00
       Page Scan Mode: 00
       Class: 52:02:04
       Clock offset: 0x78ef
Inquiry complete. Status: No error [00]

BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos. Se puede asignar un nombre más significativo para los humanos en la variable BD_ADDR. El fichero /etc/bluetooth/hosts contiene información relativa a los dispositivos Bluetooth conocidos. El siguiente ejemplo muestra cómo obtener un nombre significativo para los humanos que fué asignado a un dispositivo remoto:

% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4
BD_ADDR: 00:80:37:29:19:a4
Name: Pav's T39

Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como “nombre.de.su.sistema (ubt0)”. El nombre asignado al dispositivo local se puede modificar en cualquier momento.

El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth. El siguiente ejemplo muestra como obtener una lista de las conexiones de banda base activas en el dispositivo local:

% hccontrol -n ubt0hci read_connection_list
Remote BD_ADDR    Handle Type Mode Role Encrypt Pending Queue State
00:80:37:29:19:a4     41  ACL    0 MAST    NONE       0     0 OPEN

Resulta útil disponer de un manejador de la conexión cuando se necesita terminar la conexión de banda base. Es importante recalcar que normalmente no es necesario realizar esta terminación de forma manual. La pila Bluetooth puede concluír automáticamente las conexiones de banda base que se encuentren inactivas.

# hccontrol -n ubt0hci disconnect 41
Connection handle: 41
Reason: Connection terminated by local host [0x16]

Se ruega consultar la salida del comando hccontrol help para obtener un listado completo de los comandos HCI que se encuentran disponibles. La mayoría de éstos comandos no requiren privilegios de superusuario.

23.4.4. Protocolo de Adaptación y de Control de Enlace a nivel Lógico (L2CAP)

El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje. L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud.

L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel.

Para cada dispositivo Bluetooth se cre un único nodo Netgraph de tipo l2cap. El nodo L2CAP se conecta normalmente conectado al nodo Netgraph HCI (hacia abajo) y con nodos Bluetooth tipo “sockets” hacia arriba. El nombre por defecto para el nodo Netgraph L2CAP es “devicel2cap”. Para obtener más detalles se ruega consultar la página del manual ng_l2cap(4).

Un comando muy útil es el l2ping(8), el cual se puede utilizar para hacer ping a otros dispositivos. Algunas implementaciones de Bluetooth no devuelven todos los datos que se envían, de tal forma que el valor 0 bytes que se observa a continuación es normal:

# l2ping -a 00:80:37:29:19:a4
0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0

La herramienta l2control(8) se utiliza para realizar varias operaciones sobre los nodos L2CAP. Este ejemplo muestra cómo obtener la lista de conexiones lógicas (canales) y la lista de conexiones de banda base (física) que mantiene el dispositivo local:

% l2control -a 00:02:72:00:d4:1a read_channel_list
L2CAP channels:
Remote BD_ADDR     SCID/ DCID   PSM  IMTU/ OMTU State
00:07:e0:00:0b:ca    66/   64     3   132/  672 OPEN
% l2control -a 00:02:72:00:d4:1a read_connection_list
L2CAP connections:
Remote BD_ADDR    Handle Flags Pending State
00:07:e0:00:0b:ca     41 O           0 OPEN

Otra herramienta de diagnóstico interesante es btsockstat(1). Realiza un trabajo similar al comando netstat(1), pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior.

% btsockstat
Active L2CAP sockets
PCB      Recv-Q Send-Q Local address/PSM       Foreign address   CID   State
c2afe900      0      0 00:02:72:00:d4:1a/3     00:07:e0:00:0b:ca 66    OPEN
Active RFCOMM sessions
L2PCB    PCB      Flag MTU   Out-Q DLCs State
c2afe900 c2b53380 1    127   0     Yes  OPEN
Active RFCOMM sockets
PCB      Recv-Q Send-Q Local address     Foreign address   Chan DLCI State
c2e8bc80      0    250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3    6    OPEN

23.4.5. Protocolo RFCOMM

El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protoclo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultaneas (canales RFCOMM) entre dos dispositivos Bluetooth.

Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa).

RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro.

En FreeBSD el protocolo RFCOMM se implementa utilizando la capa de “sockets” de Bluetooth.

23.4.6. Enparejamiento de Dispositivos

Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem). La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos. Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave. El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento.

El dæmon hcsecd(8) se encarga de gestionar todas las peticiones de autenticación Bluetooth. El archivo de configuración predeterminado se denomina /etc/bluetooth/hcsecd.conf. A continuación se muestra una sección de ejemplo de un teléfono celular con el código PIN arbitrariamente fijado al valor “1234”:

device {
        bdaddr  00:80:37:29:19:a4;
        name    "Pav's T39";
        key     nokey;
        pin     "1234";
      }

No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN. La opción -d fuerza al dæmon hcsecd(8) a permanecer ejecutádose en primer plano, de tal forma que se puede observar fácilmente lo que ocurre. Si se configura el dispositivo Bluetooth remoto para aceptar el procedimiento de emparejamiento y se inicia la conexión con dicho dispositivo, el dispositivo remoto debería decir que el procedimiento de emparejamiento se ha aceptado y debería solicitar el código PIN. Si se introduce el mismo código PIN que se escribió en su momento en el fichero hcsecd.conf el procedimiento de emparejamiento y de generación de la clave de enlace debería terminar satisfactoriamente. Por otra parte el procedimiento de emparejamiento se puede iniciar en el dispositivo remoto. A continuación se muestra un ejemplo de la salida del dæmon hcsecd.

hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist
hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists
hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4

23.4.7. Protocolo de Descubrimiento de Servicios (SDP)

El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen. Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios.

SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP. El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios.

Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing.

El servidor Bluetooth SDP denominado sdpd(8) y el cliente de línea de comando denominado sdpcontrol(8) se incluyen en la instalación estándar de FreeBSD. El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP.

% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
        Service Discovery Server (0x1000)
Protocol Descriptor List:
        L2CAP (0x0100)
                Protocol specific parameter #1: u/int/uuid16 1
                Protocol specific parameter #2: u/int/uuid16 1

Record Handle: 0x00000001
Service Class ID List:
        Browse Group Descriptor (0x1001)

Record Handle: 0x00000002
Service Class ID List:
        LAN Access Using PPP (0x1102)
Protocol Descriptor List:
        L2CAP (0x0100)
        RFCOMM (0x0003)
                Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
        LAN Access Using PPP (0x1102) ver. 1.0

... y así sucesivamente. Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. El ejemplo siguiente muestra cómo buscar el servicio OBEX Object Push (OPUSH):

% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH

En FreeBSD los servicios a clientes Bluetooth se suministran mediante el servidor sdpd(8).

# sdpd

La aplicación local servidora que quiere proporcionar servicio Bluetooth a los clientes remotos puede registrar su servicio con el dæmon SDP local. Un ejemplo de dicha aplicación Un ejemplo de dicha aplicación lo constituye el dæmon rfcomm_pppd(8). Una vez ejecutado el dæmon registra un servicio LAN de Bluetooth en el dæmon SDP local.

Se puede obtener la lista de servicios registrados con el servidor SDP local lanzando una consulta de navegación SDP utilizando el canal de control local.

# sdpcontrol -l browse

23.4.8. Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante perfiles PPP (LAN)

El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación:

• Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados;

• Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos.

El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones:

• Acceso LAN para un único dispositivo Bluetooth;

• Acceso LAN para múltiples dispositivos Bluetooth;

• Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie).

En FreeBSD ambos perfiles se implementan bajo los comandos ppp(8) y rfcomm_pppd(8), un encapsulador que convierte la conexión RFCOMM de Bluetooth en algo que puede ser utilizado por PPP. Antes de que se puedan utilizar los perfiles se debe definir una nueva etiqueta PPP en el fichero de configuración /etc/ppp/ppp.conf. Consulte rfcomm_pppd(8) para ver algunos ejemplos.

En el siguiente ejemplo se va a utilizar rfcomm_pppd(8) para abrir una conexión RFCOMM con un dispositivo remoto con BD_ADDR 00:80:37:29:19:a4 sobre un canal RFCOMM basado en DUN (Dial-Up Networking). El número de canal RFCOMM se obtiene a partir del dispositivo remoto a través de SDP. Es posible especificar el canal RFCOMM a mano, en cuyo caso rfcomm_pppd(8) no realizará ninguna consulta SDP. Se puede utilizar el comando sdpcontrol(8) para descubrir el canal RFCOMM utilizado en el dispositivo remoto.

# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup

Para proporcionar el servicio de Acceso a Redes a través de PPP (LAN) se debe ejecutar el servidor sdpd(8). Se debe crear una nueva entrada en /etc/ppp/ppp.conf. Le rogamos que consulte rfcomm_pppd(8) y observe los ejemplos que se facilitan. Por último se debe ejecutar el servidor PPP RFCOMM sobre un número de canal RFCOMM adecuado. El servidor PPP RFCOMM registrará automáticamente el servicio LAN de Bluetooth con el servidor SDP local. El ejemplo que se muestra a continuación describe cómo ejecutar el servidor PPP RFCOMM.

# rfcomm_pppd -s -C 7 -l rfcomm-server

23.4.9. Perfil OBEX Object Push (OPUSH)

OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM.

El cliente y el servidor de OBEX se implementan como un paquete denominado obexapp disponible como “ port” en comms/obexapp.

El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número. A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono.

% obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get
get: remote file> telecom/devinfo.txt
get: local file> devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put
put: local file> new.vcf
put: remote file> new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)

Para proporcionar servicio de OBEX el servidor sdpd(8) debe estar en funcionamiento. Además se debe crear un directorio raíz donde todos los objetos van a ser almacenados. La ruta por defecto para el directorio raíz es /var/spool/obex. Por último se debe ejecutar el servidor OBEX en un número de canal RFCOMM válido. El servidor OBEX registra automáticamente el servicio de Object Push con el dæmon SDP local. El ejemplo que se muestra a local. El ejemplo que se muestra a continuación continuación describe cómo ejecutar el servidor OBEX.

# obexapp -s -C 10

23.4.10. Perfil de Puerto Serie (SP)

El perfil de puerto serie (Serial Port o SP) permite que dispositivos Bluetooth realicen emulación de RS232 (o similar). El escenario cubierto por este perfil trata con con aplicaciones comerciales que utilizan Bluetooth como un sustituto sustituto del cable, utilizando una capa de abstracción que representa un puerto serie virtual.

La aplicación rfcomm_sppd(1) implementa el perfil Puerto Serie. Usa una pseudo tty como abstracción de puerto serie virtual. El ejemplo de más abajo muestra cómo conectarse a un servicio de dispositivo remoto de Puerto Serie. Observe que no necesita especificarse el canal RFCOMM: rfcomm_sppd(1) puede obtenerlo del dispotivo remoto via SDP. Si necesita especificarlo por alguna razón hágalo en la propia línea de comandos.

# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6
rfcomm_sppd[94692]: Starting on /dev/ttyp6...

Una vez conectado el pseudo tty se puede utilizar como un puerto serie.

# cu -l ttyp6

23.4.11. Depuración de Problemas

# hccontrol -n ubt0hci write_node_role_switch 0