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 для выполнения не требуют прав администратора системы.
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
Протокол 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.
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. Теперь ваш ПК и удалённое устройство спарены. Альтернативным способом является инициация процесса создания пары на удалённом устройстве.
Во FreeBSD 5.5, 6.1 и в более новых, следующая строка может быть добавлена к /etc/rc.conf, чтобы hcsecd запускался автоматически во время старта системы:
hcsecd_enable="YES"
Ниже даётся пример выдачи протокола команды 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
Дата добавления: 2018-10-26; просмотров: 323; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!