Bluetooth é uma tecnologia sem fio para criar redes pessoais operando na banda não licenciada de 2.4GHz, com alcance de 10 metros. As redes geralmente são criadas sob medida para este propósito, a partir de dispositivos portáteis como telefones celulares, handhelds e laptops. Diferente de outras tecnologias sem fio populares, como Wi-Fi, o Bluetooth oferece perfis de serviço de alto nível, por exemplo: servidores de arquivos similares ao FTP, distribuição de arquivos, transporte de voz, emulação de linha serial e outras.
A pilha Bluetooth em FreeBSD é implementada usando o framework Netgraph (veja netgraph(4)). Uma ampla variedade de plugues USB Bluetooth é suportada pelo gerenciador ng_ubt(4). Os dispositivos baseado no chip Bluetooth Broadcom BCM2033 são suportados através dos gerenciadores ubtbcmfw(4) e ng_ubt(4). O cartão PC Bluetooth 3Com 3CRWB60-A é suportado pelo gerenciador ng_bt3c(4). Dispositivos Bluetooth baseados em serial e UART são suportados via sio(4), ng_h4(4) e hcseriald(8). Este capítulo descreve o uso do plugue Bluetooth USB. O suporte ao Bluetooth está disponível em sistemas com FreeBSD 5.0 e mais recentes.
Por padrão, os gerenciadores de dispositivos Bluetooth estão disponíveis na forma de módulos de kernel. Antes de ligar um dispositivo, você vai precisar carregar o gerenciador no kernel.
# kldload ng_ubt
Se o dispositivo Bluetooth está presente no sistema durante a inicialização, carregue o módulo de /boot/loader.conf.
ng_ubt_load="YES"
Conecte seu plugue USB. Uma saída similar à seguinte será exibida na console (ou no syslog).
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
Copie /usr/share/examples/netgraph/bluetooth/rc.bluetooth para algum lugar conveniente como /etc/rc.bluetooth. Este script é usado para iniciar e parar a pilha Bluetooth. É uma boa idéia parar a pilha antes de desplugar o dispositivo, mas, se o dispositivo for desplugado sem a parada da pilha, isto (geralmente) não é fatal. Quando iniciar a pilha, você poderá ver uma saída similar à seguinte:
# /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
A Interface Controladora de Sistema, ou, Host Controller Interface (HCI) fornece uma interface de comando para o controlador de banda base e o gerenciador de ligação, e acesso ao estado do hardware e registradores de controle. Esta interface fornece um método uniforme de acesso às capacidades de banda base do Bluetooth. A camada HCI no Sistema troca dados e comandos com o firmware HCI no hardware Bluetooth. O gerenciador da Camada de Transporte Controladora do Sistema - Host Controller Transport Layer - (barramento físico) fornece a ambas as camadas HCI a capacidade de trocar informações com a outra.
Um único nó Netgraph do tipo hci é criado para um único dispositivo Bluetooth. O nó HCI normalmente é conectado ao nó do gerenciador de dispositivo Bluetooth (downstream) e ao nó L2CAP (upstream). Todas as operações HCI devem ser desempenhadas no nó HCI e não no nó do gerenciador de dispositivo. O nome padrão para o nó HCI é ``devicehci''. Para maiores detalhes consulte a página de manual ng_hci(4).
Uma das tarefas mais comuns é o descobrimento de dispositivos Bluetooth nas proximidades de radiofreqüência, RF. Esta operação chama-se investigação (inquiry). A investigação e outras operações relativas a HCI são feitas com o utilitário hccontrol(8). O exemplo abaixo exibe como encontrar quais dispositivos Bluetooth estão dentro de alcance. Você deve receber a lista de dispositivos em poucos segundos. Note que um dispositivo remoto somente vai responder à investigação se estiver em modo ``encontrável'' (discoverable).
% 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]
O BD_ADDR é o endereço único de um dispositivo Bluetooth, similar ao endereço MAC de uma placa de rede. Este endereço é necessário para promover comunicações com um dispositivo. É possível designar um nome legível por humanos a um BD_ADDR. O arquivo /etc/bluetooth/hosts contém informação relativas aos sistemas Bluetooth conhecidos. O seguinte exemplo mostra como obter um nome legível por humanos que foi designado a um 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
Se você executar uma investigação em um dispositivo Bluetooth remoto, ele irá encontrar seu computador como ``nome.do.seu.sistema (ubt0)''. O nome designado para o dispositivo local pode ser trocado a qualquer hora.
O sistema Bluetooth fornece conexão ponto-a-ponto (somente duas unidades envolvidas), ou uma conexão ponto-a-multiponto. Na conexão ponto-a-multiponto, a mesma é compartilhada entre diversos dispositivos Bluetooth. O exemplo a seguir mostra como obter a lista de conexões de banda base para o 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
Um identificador de conexão (handle) é útil quando é necessário o encerramento de uma conexão de banda base. Note que geralmente não é necessário se fazer isto manualmente. A pilha automaticamente irá encerrar conexões de banda base inativas.
# hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16]
Consulte hccontrol help para uma listagem completa dos comandos HCI disponíveis. A maioria dos comandos HCI não requerem privilégios de superusuário.
O Protocolo de Controle Lógico da Ligação e de Adaptação - Logical Link Control and Adaptation Protocol - (L2CAP), fornece serviços de dados orientados à conexão e desconectados (connectionless) aos protocolos dos níveis superiores com capacidade de multiplexação e operação de segmentação e remontagem. O L2CAP permite aos protocolos dos níveis superiores e aplicações transmitirem e receberem pacotes de dados L2CAP de até 64 kilobytes de comprimento.
O L2CAP é baseado em torno do conceito de canais (channels). Um canal é uma conexão lógica sobre uma conexão de banda base. Cada canal está ligado a um único protocolo de modo muitos-para-um. Múltiplos canais podem ser ligados ao mesmo protocolo, mas um canal não pode ser ligado a múltiplos protocolos. Cada pacote L2CAP recebido em um canal é direcionado ao protocolo de nível superior apropriado. Múltiplos canais podem compartilhar a mesma conexão banda base.
Um único nó Netgraph do tipo l2cap é criado para um único dispositivo Bluetooth. O nó L2CAP geralmente é conectado a um nó Bluetooth HCI (downstream) e nós de dispositivos de envio/recepção (sockets) Bluetooth (upstream). O nome padrão para o nó L2CAP é ``devicel2cap''. Para maiores detalhes consulte a página de manual ng_l2cap(4).
Um comando útil é o l2ping(8), que pode ser usado para testar (ping) outros dispositivos. Algumas implementações Bluetooth podem não responder a todos os dados a elas enviado, então o resultado 0 bytes no exemplo abaixo é considerado 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
O utilitário l2control(8) é usado para executar diversas operações em nós L2CAP. Este exemplo mostra como obter a lista de conexões lógicas (canais) e a lista de conexões banda base para o 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
Outra ferramenta de diagnóstico é btsockstat(1). Esta ferramenta faz um trabalho similar ao de netstat(1), mas para estruturas de dados Bluetooth relacionadas à rede. O exemplo abaixo mostra a mesma conexão lógica que l2control(8), acima.
% 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
O protocolo RFCOMM fornece emulação de portas seriais sobre o protocolo L2CAP. O protocolo é baseado no padrão ETSI TS 07.10. O RFCOMM é um protocolo de transporte simples, com provisões adicionais para emular os nove circuitos das portas seriais RS-232 (EIATIA-232-E). O protocolo RFCOMM suporta até 60 conexões simultâneas (canais RFCOMM) entre dois dispositivos Bluetooth.
Para os propósitos do RFCOMM, um caminho completo de comunicação envolve duas aplicações rodando em dispositivos diferentes (as pontas da comunicação) com um segmento de comunicação entre eles. O RFCOMM é planejado para cobrir aplicações que utilizem as portas seriais dos dispositivos em que residem. O segmento de comunicação é uma ligação Bluetooth de um dispositivo para outro (conexão direta).
O RFCOMM preocupa-se somente com o caso da conexão direta entre os dispositivos, ou com o caso de rede entre um dispositivo e um modem. O RFCOMM pode suportar outras configurações, como módulos que comunicam-se via tecnologia sem fio Bluetooth em um lado, e fornecem uma interface cabeada na outra ponta.
No FreeBSD o protocolo RFCOMM é implementado na camada de sockets Bluetooth.
Por padrão, a comunicação Bluetooth não é autenticada e qualquer dispositivo pode falar para qualquer outro dispositivo. Um dispositivo Bluetooth (por exemplo, um telefone celular) pode escolher exigir autenticação para fornecer um serviço particular (por exemplo, acesso discado). A autenticação no Bluetooth é feita normalmente com código PIN. Um código PIN é uma seqüência de caracteres ASCII de até 16 caracteres de comprimento. É preciso que o usuário entre com o mesmo código PIN em ambos os dispositivos. Uma vez que o usuário entrou com o código PIN, ambos os dispositivos vão gerar uma chave de ligação (link key). Depois, a chave de ligação pode ser armazenada nos próprios dispositivos ou em um armazenamento persistente. Da próxima vez, ambos os dispositivos vão usar a chave de ligação previamente armazenada. O procedimento acima descrito é chamada de união (pairing). Note que se a chave de ligação for perdida por qualquer dispositivo, então a união precisará ser repetida.
O daemon hcsecd(8) é responsável por tratar todas as solicitações de autenticação Bluetooth. O arquivo de configuração padrão é /etc/bluetooth/hcsecd.conf. Abaixo é mostrada uma seção de exemplo para um telefone celular com o código PIN configurado arbitrariamente para ``1234''.
device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
}
Não há limites em códigos de PIN (exceto tamanho). Alguns dispositivos (por exemplo, fones Bluetooth) podem ter um código PIN fixo embutido. O parâmetro -d força o daemon hcsecd(8) a se manter rodando em primeiro plano, de forma que seja fácil observar o que está acontecendo. Ajuste o dispositivo remoto para receber união e iniciar a conexão Bluetooth ao dispositivo remoto. O dispositivo remoto deveria dizer que a união foi aceita, e solicitar o código PIN. Entre o mesmo código PIN que você tem em hcsecd.conf. Agora seu PC e o dispositivo remoto estão unidos. Alternativamente, você pode iniciar a união no dispositivo remoto. Abaixo, a amostra da saída do comando 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
O Protocolo de Descoberta de Serviço - Service Discovery Protocol (SDP) - fornece os meios para as aplicações clientes descobrirem a existência de serviços fornecidos por aplicações servidoras, bem como os atributos destes serviços. Os atributos de um serviço incluem o tipo de classe de serviço oferecido e a informação do protocolo ou mecanismo necessários para utilizar o serviço.
O SDP envolve comunicação entre um servidor SDP e um cliente SDP. O servidor mantém uma lista de registros de serviços que descrevem as características dos serviços associados com o servidor. Cada registro de serviço contém informação sobre um único serviço. Um cliente pode recuperar informação de um serviço mantido pelo servidor SDP emitindo uma solicitação SDP. Se um cliente ou uma aplicação associada com o cliente decide usar um serviço, ele precisa abrir uma conexão separada ao provedor para utilizá-lo. O SDP fornece um mecanismo para descoberta de serviços e seus atributos, mas não fornece um mecanismo para utilização destes serviços.
Normalmente, um cliente SDP busca por serviços baseados em algumas características desejadas dos serviços. Entretanto, há momentos nos quais é desejável descobrir quais tipos de serviços estão descritos por registros de serviço de um servidor SDP sem qualquer informação a priori sobre os mesmos. ESte processo de procurar por quaisquer serviços oferecidos é chamado de navegação (browsing).
Atualmente, o cliente e o servidor SDP são implementados em uma pacote externo, sdp-1.5, que pode ser copiado daqui. O sdptool é um cliente SDP de linha de comando. O seguinte exemplo mostra como executar uma solicitação de navegação SDP.
# sdptool browse 00:80:37:29:19:a4 Browsing 00:80:37:29:19:A4 ... Service Name: Dial-up Networking Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Service Name: Fax Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 2 Service Name: Voice gateway Service Class ID List: "Headset Audio Gateway" (0x1112) "Generic Audio" (0x1203) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 3
...e assim por diante. Note que cada serviço tem uma lista de atributos (canal RFCOMM, por exemplo). Dependendo do serviço você pode precisar anotar alguns dos atributos. Algumas implementações Bluetooth não suportam navegação nos serviços, e podem retornar uma lista vazia. Neste caso, é possível buscar pelo serviço específico. O exemplo abaixo mostra como buscar pelo serviço OBEX Object Push (OPUSH).
# sdptool search --bdaddr 00:07:e0:00:0b:ca OPUSH
Oferecendo serviços em FreeBSD a clientes Bluetooth é feito com o servidor sdpd.
# sdpd
O sdptool também é usado para registrar um serviço no servidor SDP local. O exemplo abaixo mostra como registrar o serviço de Acesso à Rede com PPP (LAN). Repare que alguns serviços exigem atributos (canal RFCOMM, por exemplo).
# sdptool add --channel=7 LAN
A lista de serviços registrados com o servidor SDP local pode ser obtida emitindo uma requisição de navegação SDP a um BD_ADDR ``especial''.
# sdptool browse ff:ff:ff:00:00:00
O perfil de acesso discado - Dial-Up Networking (DUN) - é mais usado com modems e telefones celulares. Os cenários cobertos por este perfil são os seguintes:
uso de um telefone celular ou modem por um computador como modem sem-fio (wireless) para conectar à Internet através de um servidor de acesso discado, ou usar outros serviços de acesso discado;
uso de um telefone celular ou modem por um computador para receber chamadas de dados.
O perfil de Acesso à Rede com PPP (LAN) pode ser usado nas seguintes situações:
Acesso na Rede Local (LAN) para um único dispositivo Bluetooth;
Acesso à Rede Local para múltiplos dispositivos Bluetooth;
PC a PC (usando rede PPP sobre emulação de cabo serial).
No FreeBSD ambos os perfis são implementados com ppp(8) e rfcomm_pppd(8) - uma cobertura (wrapper) que converte a conexão Bluetooth RFCOMM em algo com o qual o PPP pode operar. Antes que qualquer perfil possa ser usado, um novo rótulo PPP deve ser criado em /etc/ppp/ppp.conf. Consulte a página de manual rfcomm_pppd(8) para ver exemplos.
No seguinte exemplo, rfcomm_pppd(8) será usado para abrir uma conexão RFCOMM ao dispositivo remoto com o BD_ADDR 00:80:37:29:19:a4 no canal RFCOMM DUN. O número do canal RFCOMM atual será obtido do dispositivo remoto via SDP. É possível especificar o canal RFCOMM manualmente, e, neste caso, rfcomm_pppd(8) não irá executar uma requisição SDP. Use sdptool para descobrir o canal RFCOMM no dispositivo remoto.
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
Para fornecer o serviço de Acesso à Rede com PPP (LAN), o servidor sdpd deve estar sendo executado. Também é necessário registrar o serviço de Rede Local com o servidor SDP local. Note que o serviço de rede exige o atributo do canal RFCOMM. Uma nova entrada para clientes da Rede Local precisa ser criada no arquivo /etc/ppp/ppp.conf. Consulte a página de manual rfcomm_pppd(8) para ver exemplos. Finalmente, o servidor PPP RFCOMM precisa estar rodando e ouvindo no mesmo canal RFCOMM como foi registrado com o servidor SDP local. O exemplo abaixo mostra como iniciar o servidor PPP RFCOMM.
# rfcomm_pppd -s -C 7 -l rfcomm-server
O OBEX é um protocolo amplamente usado para transferências de arquivos simples entre dispositivos móveis. Seu principal uso é nas comunicação em infravermelho, onde é usado para transferências de arquivos genéricos entre notebooks ou dispositivos Palm, e para enviar cartões de visita ou entradas em calendários entre telefones celulares e outros dispositivos com aplicações de Gerenciamento de Informações Pessoal (PIM).
O cliente e o servidor OBEX são implementados como pacotes de terceiros obexapp-1.0 que pode ser copiada daqui. O pacote requer a biblioteca openobex (já incluída) e o port devel/glib12. Note que obexapp não requer privilégios de superusuário (root) para operar.
O cliente OBEX é usado para remeter e/ou copiar objetos do servidor OBEX. Um objeto pode, por exemplo, ser um cartão de visitas ou um agendamento. O cliente OBEX pode obter um número de canal RFCOMM do dispositivo remoto via SDP. Isto pode ser feito especificando-se o nome do serviço ao invés do número do canal RFCOMM. Nomes de dispositivos suportados são: IrMC, FTRN e OPUSH. É possível especificar o canal RFCOMM como um número. Abaixo está um exemplo de sessão OBEX, onde o objeto de informação do dispositivo é copiado do telefone celular e, um novo objeto (cartão de visita) é remetido à agenda do telefone.
% 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 fornecer o serviço de envio OBEX, o servidor sdpd precisa estar sendo executado. Também é necessário registrar o serviço OPUSH no servidor SDP local. Note que o serviço OPUSH requer o atributo do canal RFCOMM. Uma pasta raiz, onde todos os objetos recebidos serão armazenados, precisa ser criado. O caminho padrão para a pasta raiz é /var/spool/obex. Finalmente, o servidor OBEX precisa estar rodando e ouvindo no mesmo canal RFCOMM como registrado com o servidor SDP local. O exemplo abaixo mostra como iniciar o servidor OBEX.
# obexapp -s -C 10
A porta serial - Serial Port (SP) - permite a um dispositivo Bluetooth executar uma emulação de cabo serial RS232 (ou similar). O cenário abordado neste perfil trata de aplicações legadas usando o Bluetooth como substituto do cabo, através de uma abstração de porta serial virtual.
O utilitário rfcomm_sppd(1) implementa o perfil de Porta Serial. Um pseudo tty é usado como uma abstração de porta serial virtual. O exemplo abaixo mostra que você não tem que especificar o canal RFCOMM - rfcomm_sppd(1) pode obtê-lo do dispositivo remoto via SDP. Se você quiser ativar manualmente isto, especifique o canal RFCOMM na linha de comando.
# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6...
Uma vez conectado, o pseudo tty pode ser usado como porta serial.
# cu -l ttyp6
Alguns dispositivos Bluetooth mais antigos não suportam troca de função. Por padrão, quando o FreeBSD está aceitando uma nova conexão, ele tenta efetuar uma troca de função e tornar-se um mestre. Os dispositivos que não suportarem esta característica, não serão capazes de se conectar. Note que a troca de função é executada quando uma nova conexão está sendo estabelecida, de forma que não seja possível perguntar ao dispositivo remoto se ele suporta troca de função. Há uma opção HCI para desabilitar a troca de função na ponta local.
# hccontrol -n ubt0hci write_node_role_switch 0
Sim, você pode. Use o pacote de terceiros hcidump-1.5, que pode ser copiado daqui. O utilitário hcidump é similar ao tcpdump(1). Ele pode ser usado para mostrar o conteúdo dos pacotes Bluetooth no terminal, e jogar pacotes em um arquivo.
Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.