24.4.1. Введение

Bluetooth является беспроводной технологией для создания персональных сетей на расстоянии не более 10 метров, работающей на частоте 2.4 ГГц, которая не подлежит лицензированию. Обычно такие сети формируются из портативных устройств, таких, как сотовые телефоны, КПК и лаптопы. В отличие от Wi-Fi, другой популярной беспроводной технологии, Bluetooth предоставляет более высокий уровень сервиса, например, файловые серверы типа FTP, передачу файлов, голоса, эмуляцию последовательного порта и другие.

Стек протоколов Bluetooth во FreeBSD реализован на основе технологии Netgraph (обратитесь к netgraph(4)). Широкий спектр USB-устройств Bluetooth поддерживается драйвером ng_ubt(4). Устройства Bluetooth на основе набора микросхем Broadcom BCM2033 поддерживается драйвером ng_bt3c(4). Устройства Bluetooth, работающие через последовательные и UART-порты, поддерживаются драйверами sio(4), ng_h4(4) и hcseriald(8). В этом разделе описывается использование Bluetooth-устройств, подключаемых через USB. Поддержка Bluetooth имеется во FreeBSD 5.0 и более новых версиях системы.

24.4.2. Подключение устройства

По умолчанию драйверы устройств Bluetooth поставляются в виде модулей ядра. Перед подключением устройства вам необходимо подгрузить драйвер в ядро:

# kldload ng_ubt

Если Bluetooth-устройство в момент запуска системы подключено, то загружайте модуль из файла /boot/loader.conf:

ng_ubt_load="YES"

Подключите ваше USB-устройство. На консоли (или в журнале 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

Скопируйте файл /usr/share/examples/netgraph/bluetooth/rc.bluetooth в какое-нибудь подходящее место, например, в файл /etc/rc.bluetooth. Этот скрипт используется для запуска и остановки работы Bluetooth-стека. Перед отключением устройства рекомендуется остановить его работы, хотя (обычно) это не фатально. При запуске стека вы получите сообщения, подобные следующим:

# /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

24.4.3. Host Controller Interface (HCI)

Host Controller Interface (HCI) предоставляет интерфейс для управления контроллером передатчика и менеджером соединений, а также доступ к данным о состоянии оборудования и его управляющим регистрам. Этот интерфейс предоставляет унифицированный метод доступа к передающим возможностям Bluetooth. Уровень HCI на управляющей машине обменивается данными и командами с микрокодом HCI в оборудовании Bluetooth. Драйвер для Host Controller Transport Layer (то есть физической шины) предоставляет обоим слоям HCI возможность обмениваться данными друг с другом.

Для одного Bluetooth-устройства создаётся один узел Netgraph типа hci. HCI-узел обычно подключается к узлу драйвера устройства Bluetooth (входящий поток) и к узлу L2CAP (исходящий поток). Все операции с HCI должны выполняться на узле HCI, но не на узле драйвера устройства. В качестве имени по умолчанию для узла HCI используется ``devicehci''. Дополнительные подробности можно найти на справочной странице ng_hci(4).

Одной из самой часто выполняемой задач является обнаружение Bluetooth-устройств в радиусе RF-доступности. Эта операция называется опросом (inquiry). Опрос и другие операции, связанные с HCI, выполняются при помощи утилиты hccontrol(8). Пример ниже показывает, как найти доступные устройства Bluetooth. Список таких устройств должен быть получен в течение нескольких секунд. Заметьте, что удалённые устройства будут отвечать на опрос, если только они находятся в режиме обнаруживаемости (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]

BD_ADDR является уникальным адресом устройства Bluetooth, вроде MAC-адресов сетевых адаптеров. Этот адрес необходим для дальнейшей работы с устройством. Адресу BD_ADDR можно присвоить удобное для чтения имя. Файл /etc/bluetooth/hosts содержит информацию об известных хостах Bluetooth. В следующем примере показано, как получить имя, назначенное удалённому устройству:

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

Если вы выполните опрос на другом Bluetooth-устройстве, но ваш компьютер будет опознан как ``your.host.name (ubt0)''. Имя, назначаемое локальному устройству, может быть в любой момент изменено.

Система Bluetooth предоставляет услуги по соединениям типа точка-точка (при этом задействованы только два устройства Bluetooth) или точка-ко-многим-точкам. В последнем случае соединение используется совместно несколькими устройствам Bluetooth. В следующем примере показывается, как получить список активных для локального устройства соединений:

% 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

Идентификатор соединения (connection handle) полезен, когда необходимо прекратить соединение. Заметьте, что обычно нет нужды делать это вручную. Стек будет автоматически разрывать неактивные соединения.

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

Обратитесь к помощи посредством hccontrol help для получения полного списка доступных HCI-команд. Большинство команд HCI для выполнения не требуют прав администратора системы.

24.4.4. Logical Link Control and Adaptation Protocol (L2CAP)

Протокол L2CAP (Logical Link Control and Adaptation Protocol) предоставляет услуги по работе с данными, как ориентированные на соединения, так и без ориентации на них, протоколам более высокого уровня с возможностями мультиплексирования и обеспечением операций по сегментации и обратной сборке. L2CAP позволяет протоколам более высокого уровня и приложениям передавать и получать пакеты данных L2CAP длиной до 64 Кбайт.

L2CAP основан на концепции каналов. Каналом является логическое соединение поверх соединения по радиоканалу. Каждый канал привязан к некоторому протоколу по принципу многие-к-одному. Несколько каналов могут быть привязаны к одному и тому же протоколу, но канал не может быть привязан к нескольким протоколам. Каждый пакет L2CAP, получаемый каналом, перенаправляется к соответствующему протоколу более высокого уровня. Несколько каналов могут совместно использовать одно и то же радиосоединение.

Для одного Bluetooth-устройства создается один узел Netgraph типа l2cap. Узел L2CAP обычно подключается к узлу Bluetooth HCI (нижестоящий) и узлам Bluetooth-сокетов (вышестоящие). По умолчанию для узла L2CAP используется имя ``devicel2cap''. Для получения дополнительной информации обратитесь к справочной странице по ng_l2cap(4).

Полезной является программа l2ping(8), которая может использоваться для проверки связи с другими устройствами. Некоторые реализации Bluetooth могут не возвращать все данные, посылаемые им, так что 0 bytes в следующем примере - это нормально.

# 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

Утилита l2control(8) используется для выполнения различных операций с узлами L2CAP. В этом примере показано, как получить список логических соединений (каналов) и перечень радиосоединений локального устройства:

% 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

Ещё одним диагностическим инструментом является btsockstat(1). Она выполняет действия, подобные тем, что обычно выполняет netstat(1), но со структурами данных, связанных с работой в сети Bluetooth. В примере ниже описывается то же самое логическое соединение, что и с l2control(8) выше.

% 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

24.4.5. Протокол RFCOMM

Протокол RFCOMM эмулирует последовательные порты поверх протокола L2CAP. Он основан на ETSI-стандарте TS 07.10. RFCOMM представляет собой простой транспортный протокол, с дополнительными возможностями по эмуляции 9 цепей последовательных портов RS-232 (EIATIA-232-E). Протокол RFCOMM поддерживает одновременно до 60 соединений (каналов RFCOMM) между двумя устройствами Bluetooth.

В рамках RFCOMM полный коммуникационный маршрут включает два приложения, работающие на разных устройствах (конечные коммуникационные точки) с коммуникационным сегментом между ними. RFCOMM предназначен для сокрытия приложений, использующих последовательные порты устройств, в которых они расположены. Коммуникационный сегмент по сути является Bluetooth-связью от одного устройства к другому (прямое соединение).

RFCOMM имеет дело с соединением между устройствами в случае прямого соединения, или между устройством и модемом в сетевом случае. RFCOMM может поддерживать и другие конфигурации, такие, как модули, работающие через беспроводную технологию Bluetooth с одной стороны и предоставляющие проводное соединение с другой стороны.

Во FreeBSD протокол RFCOMM реализован на уровне сокетов Bluetooth.

24.4.6. Pairing of Devices

По умолчанию связь Bluetooth не аутентифицируется, поэтому любое устройство может общаться с любым другим. Устройство Bluetooth (например, сотовый телефон) может задать обязательность аутентификации для предоставления определённого сервиса (в частности, услугу доступа по коммутируемой линии). Bluetooth-аутентификация обычно выполняется через PIN-коды. PIN-код представляет из себя ASCII-строку длиной до 16 символов. Пользователь обязан ввести один и тот же PIN-код на обоих устройствах. Как только он введёт PIN-код, оба устройства сгенерируют ключ связи. После этого ключ может быть сохранён либо в самом устройстве, либо на постоянном носителе. В следующий раз оба устройства будут использовать ранее сгенерированный ключ соединения. Процедура, описанная выше, носит название подгонки пары (pairing). Заметьте, что если ключ связи потерян любой из сторон, то подбор пары должен быть повторен.

За обработку всех запросов на Bluetooth-аутентификацию отвечает даемон hcsecd(8). По умолчанию файл конфигурации называется /etc/bluetooth/hcsecd.conf. Пример раздела, содержащего информацию о сотовом телефоне с явно заданным PIN-кодом ``1234'' приведен ниже:

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

Кроме длины, на PIN-коды не накладывается никаких ограничений. Некоторые устройства (например, Bluetooth-гарнитуры) могут иметь фиксированный встроенный PIN-код. Параметр -d позволяет запустить hcsecd(8) как нефоновый процесс, что облегчает просмотр происходящих событий. Задайте получение парного ключа на удалённом устройстве и инициируйте Bluetooth-соединение с этим устройством. Удалённое устройство должно подтвердить получение пары и запросить PIN-код. Введите тот же самый код, что находится в hcsecd.conf. Теперь ваш ПК и удалённое устройство спарены. Альтернативным способом является инициация процесса создания пары на удалённом устройстве. Ниже даётся пример выдачи протокола команды 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

24.4.7. Service Discovery Protocol (SDP)

Протокол обнаружения сервисов SDP даёт возможность клиентским приложениям осуществлять поиск услуг, предоставляемых серверными приложениями, а также характеристик этих услуг. В перечень атрибутов сервиса включается тип класса предлагаемого сервиса и информация о механизме или протоколе, требуемом для использования сервиса.

SDP подразумевает коммуникации между SDP-сервером и SDP-клиентом. Сервер поддерживает список сервисов, в котором описываются параметры сервисов, связанных с сервером. Каждая запись об услуге содержит информацию об одном сервисе. Клиент может запросить информацию об определённом сервисе, обслуживаемом SDP-сервером, выдавая SDP-запрос. Если клиент или приложение, связанное с клиентом, решат воспользоваться сервисом, то для его использования необходимо открыть отдельное соединение к устройству, предоставляющему сервис. SDP предоставляет механизм обнаружения услуг и их параметров, но не даёт механизма использования этих сервисов.

Обычно SDP-клиент выполняет поиск услуг на основе некоторых желаемых характеристик услуг. Однако иногда возникает необходимость выяснить полный перечень типов услуг, предоставляемых SDP-сервером, не имея никакой информации об имеющихся сервисах. Такой процесс всех предлагаемых сервисов называется обзором (browsing).

Bluetooth SDP сервер sdpd(8) и клиент с интерфейсом командной строки sdpcontrol(8) включены в стандартную поставку FreeBSD. В следующем примере показано, как выполнять запрос на 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

... и так далее. Заметьте, что каждый сервис имеет перечень атрибутов (например, канал RFCOMM). В зависимости от сервиса вам может потребоваться где-то сохранить эти атрибуты. Некоторые реализации Bluetooth не поддерживают просмотр сервисов и могут возвращать пустой список. В этом случае возможен поиск конкретной услуги. В примере ниже показано, как выполнить поиск службы OBEX Object Push (OPUSH):

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

Во FreeBSD предоставление сервисов клиентам Bluetooth осуществляется сервером sdpd(8):

# sdpd

Приложение на локальном сервере, желающее предоставить сервис Bluetooth удаленным клиентам, регистрирует сервис через локального даемона SDP. Пример такого приложения -- rfcomm_pppd(8). После запуска оно регистрирует Bluetooth LAN сервис через локального даемона SDP.

Список сервисов, зарегистрированных через локальный SDP сервер, может быть получен путем выдачи запроса на просмотр SDP через локальный контрольный канал:

# sdpcontrol -l browse

24.4.8. Доступ к сети по коммутируемой линии связи (DUN) и по протоколу PPP (LAN)

Модуль работы с коммутируемым доступом к сети (DUN - Dial-Up Networking) в большинстве случаев используется с модемами и сотовыми телефонами. Этот модуль покрывает следующие случаи:

• сотовый телефон или модем используется вместе с компьютером в качестве беспроводного модема для подключения к серверу коммутируемого доступа в Интернет, или другой коммутируемой услуге;

• сотовый телефон или модем используется компьютером для приёма входящих соединений.

Модуль доступа к сети по протоколу PPP (Network Access with PPP - LAN) может использоваться в следующих ситуациях:

• доступ к ЛВС для одного Bluetooth-устройства;

• доступ к ЛВС для нескольких Bluetooth-устройств;

• связь между двумя ПК (при помощи протокола PPP поверх эмулируемого последовательного канала связи).

Во FreeBSD оба случая реализуются при помощи сервисных программ ppp(8) и rfcomm_pppd(8) - это обработчик, преобразующий RFCOMM-соединения Bluetooth в нечто, с чем может работать PPP. Перед тем, как использовать любой модуль, в файле /etc/ppp/ppp.conf должна быть создана новая PPP-метка. Примеры использования можно найти в справочной странице к rfcomm_pppd(8).

В следующем примере rfcomm_pppd(8) будет использоваться для открытия RFCOMM-соединения к удалённому устройству с BD_ADDR 00:80:37:29:19:a4 на DUN RFCOMM-канале. Реальный номер RFCOMM-канала будет получаться с удалённого устройства через SDP. Возможно указать RFCOMM-канал вручную, и в этом случае rfcomm_pppd(8) не будет выполнять SDP-запрос. Для нахождения RFCOMM-канала на удалённом устройстве используйте утилиту sdpcontrol(8).

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

Для того, чтобы организовать сервис Network Access with PPP (LAN), необходимо запустить сервер sdpd(8). В файле /etc/ppp/ppp.conf должна быть создана новая запись для клиентов LAN. Примеры можно найти в справке по rfcomm_pppd(8). Наконец, запустите RFCOMM PPP сервер на существующем номере канала RFCOMM. Сервер RFCOMM PPP автоматически зарегистрирует Bluetooth LAN сервис через локальный SDP даемон. В примере ниже показано, как запустить сервер RFCOMM PPP.

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

24.4.9. OBEX Object Push (OPUSH) Profile

OBEX является широко используемым протоколом для простой передачи файлов между мобильными устройствами. В основном он используется в коммуникациях через инфракрасный порт для передачи файлов между ноутбуками или КПК, а также для пересылки визитных карточек или календарных планов между сотовыми телефонами и другими устройствами с персональными информационными менеджерами.

Сервер и клиент OBEX реализованы в виде пакета стороннего разработчика obexapp, который доступен в виде порта comms/obexapp.

Клиент OBEX используется для посылки или приёма объектов с сервера OBEX. Объектом, к примеру, может быть визитная карточка или указание. Клиент OBEX может получить номер RFCOMM-канала, указав вместо него имя сервиса. Поддерживаются следующие имена сервиса: IrMC, FTRN и OPUSH. Канал RFCOMM можно задать его номером. Ниже даётся пример сеанса OBEX, где с сотового телефона забирается объект с информацией об устройстве, а новый объект (визитная карточка) передаётся в каталог сотового телефона.

% 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)

Для того, чтобы предоставить сервис OBEX Push, должен быть запущен сервер sdpd(8). Должен быть создан корневой каталог, в котором будут сохраняться все поступающие объекты. По умолчанию корневым каталогом является /var/spool/obex. Наконец, запустите OBEX сервер на существующем номере канала RFCOMM. OBEX сервер автоматически зарегистрирует сервис OBEX Object Push через локального даемона SDP. В примере ниже показано, как запустить OBEX-сервер.

# obexapp -s -C 10

24.4.10. Профиль последовательного порта (SPP)

Профиль последовательного порта (SPP - Serial Port Profile) позволяет Bluetooth-устройствам осуществлять эмуляцию последовательного порта RS232 (или подобного). Этот профиль покрывает случаи, касающиеся работы унаследованных приложений с Bluetooth в качестве замены кабельному соединению, при это используется абстракция виртуального последовательного порта.

Утилита rfcomm_sppd(1) реализует профиль последовательного порта. В качестве виртуального последовательного порта используется псевдотерминал. В примере ниже показано, как подключиться к сервису Serial Port удалённого устройства. Заметьте, что вы не указываете RFCOMM-канал - rfcomm_sppd(1) может получить его с удалённого устройства через SDP. Если вы хотите переопределить это, укажите RFCOMM-канал явно в командной строке.

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

После подключения псевдотерминал можно использовать как последовательный порт:

# cu -l ttyp6

24.4.11. Решение проблем

# hccontrol -n ubt0hci write_node_role_switch 0