19.4 Bluetooth Текст предоставил Pav Lucistnik.
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 и более новых версиях системы.
19.4.2 Подключение устройства
По умолчанию драйверы устройств Bluetooth поставляются в виде модулей ядра. Перед подключением устройства вам необходимо подгрузить драйвер в ядро.
Если Bluetooth-устройство в момент запуска системы подключено, то загружайте модуль из файла /boot/loader.conf .
Подключите ваше 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 Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8
19.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 для выполнения не требуют прав администратора системы.
19.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
19.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.
19.4.6 Pairing of Devices
По умолчанию связь Bluetooth не аутентифицируется, поэтому любое устройство может общаться с любым другим. Устройство Bluetooth (например, сотовый телефон) может задать обязательность аутентификации для предоставления определённого сервиса (в частности, услугу доступа по коммутируемой линии). Bluetooth-аутентификация обычно выполняется через PIN-коды . PIN-код представляет из себя ASCII-строку длиной до 16 символов. Пользователь обязан ввести один и тот же PIN-код на обоих устройствах. Как только он введёт PIN-код, оба устройства сгенерируют ключ связи . После этого ключ может быть сохранён либо в самом устройстве, либо на постоянном носителе. В следующий раз оба устройства будут использовать ранее сгенерированный ключ соединения. Процедура, описанная выше, носит название подгонки пары (pairing). Заметьте, что если ключ связи потерян любой из сторон, то подбор пары должен быть повторен.
За обработку всех запросов на Bluetooth-аутентификацию отвечает даемон hcsecd (8) . По умолчанию файл конфигурации называется /etc/bluetooth/hcsecd.conf . Пример раздела, содержащего информацию о сотовом телефоне с явно заданным 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
19.4.7 Service Discovery Protocol (SDP)
Протокол обнаружения сервисов SDP даёт возможность клиентским приложениям осуществлять поиск услуг, предоставляемых серверными приложениями, а также характеристик этих услуг. В перечень атрибутов сервиса включается тип класса предлагаемого сервиса и информация о механизме или протоколе, требуемом для использования сервиса.
SDP подразумевает коммуникации между SDP-сервером и SDP-клиентом. Сервер поддерживает список сервисов, в котором описываются параметры сервисов, связанных с сервером. Каждая запись об услуге содержит информацию об одном сервисе. Клиент может запросить информацию об опеределённом сервисе, обслуживаемом SDP-сервером, выдавая SDP-запрос. Если клиент или приложение, связанное с клиентом, решат воспользоваться сервисом, то для его использования необходимо открыть отдельное соединение к устройству, предоставляющему сервис. SDP предоставляет механизм обнаружения услуг и их параметров, но не даёт механизма использования этих сервисов.
Обычно SDP-клиент выполняет поиск услуг на основе некоторых желаемых характеристик услуг. Однако иногда возникает необходимость выяснить полный перечень типов услуг, предоставляемых SDP-сервером, не имея никакой информации об имеющихся сервисах. Такой процесс всех предлагаемых сервисов называется обзором (browsing).
Существующие на данный момент серверы и клиенты SDP реализованы в пакете стороннего разработчика sdp-1.5 , который можно сгрузить здесь . Утилита sdptool является SDP-клиентом, управляемым из командной строки. В следующем примере показано, как выполнять запрос на 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
. и так далее. Заметьте, что каждый сервис имеет перечень атрибутов (например, канал RFCOMM). В зависимости от сервиса вам может потребоваться где-то сохранить эти атрибуты. Некоторые реализации Bluetooth не поддерживают просмотр сервисов и могут возвращать пустой список. В этом случае возможен поиск конкретной услуги. В примере ниже показано, как выполнить поиск службы OBEX Object Push (OPUSH).
# sdptool search —bdaddr 00:07:e0:00:0b:ca OPUSH
Во FreeBSD предоставление сервисов клиентам Bluetooth осуществляется сервером sdpd .
Для регистрации сервиса в локальном SDP-сервере также применяется утилита sdptool . В примере ниже показывается, как зарегистрировать Network Access с услугой PPP (LAN). Заметьте, что некоторые сервисы требуют указания их атрибутов (например, канала RFCOMM).
# sdptool add —channel=7 LAN
Перечень сервисов, зарегистрированных в локальном SDP-сервере, может быть получен посылкой SDP-запроса на просмотр «специального» адреса BD_ADDR.
# sdptool browse ff:ff:ff:00:00:00
19.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-канала на удалённом устройстве используйте утилиту sdptool .
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
Для того, чтобы организовать сервис Network Access with PPP (LAN), необходимо запустить сервер sdpd . Также необходимо зарегистрировать сервис LAN на локальном SDP-сервере. Заметьте, что сервис LAN требует наличия RFCONN-канала. В файле /etc/ppp/ppp.conf должна быть создана новая запись для клиентов LAN. Примеры можно найти в справке по rfcomm_pppd (8) . Наконец, должен быть запущен сервер RFCOMM PPP, который работает и прослушивает на том же самом RFCOMM-канале, что зарегистрирован на локальном SDP-сервере. В примере ниже показано, как запустить сервер RFCOMM PPP.
# rfcomm_pppd -s -C 7 -l rfcomm-server
19.4.9 OBEX Push (OPUSH) Profile
OBEX является широкоиспользуемым протоколом для простой передачи файлов между мобильными устройствами. В основном он используется в коммуникациях через инфракрасный порт для передачи файлов между ноутбуками или КПК компании Palm, а также для пересылки визитных карточек или календарных планов между сотовыми телефонами и другими устройствами с персональными информационными менеджерами.
Сервер и клиент OBEX реализованы в виде пакета стороннего разработчика obexapp-1.0 , который можно сгрузить отсюда . Пакет требует наличия библиотеки openobex (она включена в пакет) и порта devel/glib12 . Заметьте, что для работы 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 . Он также требуется и для регистрации услуги OPUSH на локальном SDP-сервере. Заметьте, что сервис OPUSH требует для своей работы RFCOMM-канал. Должен быть создан корневой каталог, в котором будут сохраняться все поступающие объекты. По умолчанию корневым каталогом является /var/spool/obex . Наконец, сервер OBEX должен работать и прослушивать тот же самый RFCOMM-канал, что зарегистрирован на локальном SDP-сервере. В примере ниже показано, как запустить OBEX-сервер.
19.4.10 Модуль последовательного порта (SP)
Модуль последовательного порта (SP — Serial Port) позволяет 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.
После подключения псевдотерминал можно использовать как последовательный порт.
19.4.11 Решение проблем
19.4.11.1 Удалённое устройство не подключается
Некоторые старые Bluetooth-устройства не поддерживают переключение ролей. По умолчанию, когда FreeBSD подтверждает новое соединение, она пытается выполнить переключение роли и стать ведущим устройством. Устройства, которые это не поддерживают, не смогут подключиться. Заметьте, что переключение ролей выполняется при установлении нового соединения, поэтому невозможно выяснить, поддерживает ли удалённое устройство переключение ролей. На локальной машине имеется возможность отключить переключение ролей при помощи HCI-параметра.
# hccontrol -n ubt0hci write_node_role_switch 0
19.4.11.2 Что-то идёт не так, можно ли посмотреть, что в точности происходит?
Да, можно. Воспользуйтесь пакетом hcidump-1.5 стороннего разработчика, который доступен для сгрузки здесь . Утилита hcidump похожа на tcpdump (1) . Она может использоваться для вывода на терминал содержимого Bluetooth-пакетов и сбрасывать пакеты Bluetooth в файл.
| Prev | Home | Next |
| Беспроводные сети | Up | Мосты |
Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ .
По вопросам связанными с FreeBSD, прочитайте документацию прежде чем писать в < questions@FreeBSD.org >.
По вопросам связанным с этой документацией, пишите < doc@FreeBSD.org >.
По вопросам связанным с русским переводом документации, пишите < frdp@FreeBSD.org.ua >.
Моделирование процедуры соединения bluetooth устройств и есть ли потребность в моделях такого рода
В виде пробного варианта смоделировал процедуру соединения между устройствами bluetooth на языке UML с использованием диаграммы последовательности. Далее приведены текстовое описание данной процедуры и модель построенная по этому описанию.
Этап 1
Процедура inquiry позволяет устройству определить, какие приборы доступны, выяснить адреса и осуществить синхронизацию.
1.1 Посылаются пакеты inquiry и получаются отклики.
1.2 Если адресат, получивший пакет inquiry, находится в состоянии inquiry scan, тогда он способен принимать такие пакеты
1.3 Получатель переходит в состояние inquiry response и посылает отправителю пакет-отклик.
После того как процедура inquiry завершена, соединение может быть установлено с помощью процедуры paging.
Этап 2
Процедура paging реализует соединение. Для осуществления этой процедуры необходим адрес. Устройство, выполняющее процедуру paging, автоматически становится хозяином этого соединения.
2.1 Посылается пакет paging
2.2 Адресат получает этот пакет (находится в состоянии page Scan)
2.3 Получатель посылает отправителю пакет-отклик (находится в состоянии Slave Response)
2.4 Инициатор посылает адресату пакет FHS (находится в состоянии Master Response).
2.5 Получатель посылает отправителю второй пакет-отклик (находится в состоянии Slave Response)
2.6 Получатель и отправитель устанавливают параметры канала заданные инициатором (находятся в состоянии Master Response & Slave Response)
После установления соединения основной узел (master) посылает пакет POLL, чтобы проверить, синхронизовал ли клиент свои часы и настроился ли на коммутацию частот. Клиент при этом может откликнуться любым пакетом.
Исходя из этого описания построена следующая модель в виде диаграммы последовательности.
Приветствуется любая конструктивная критика. Вопрос для меня очень важный, так как не хочу тратить время на не неверные шаги.
- uml
- сетевые технологии
Переводы страниц руководства
hciconfig используется для настройки устройств Bluetooth. hciX — это имя установленного в системе устройства Bluetooth. Если hciX не задан, hciconfig выведет имя и основную информацию обо всех установленных в системе устройствах Bluetooth. Если hciX задан, но не задана команда, программа выведет основную информацию только об устройстве hciX. Основная информация — это тип интерфейса, адрес устройства, ACL MTU, SCO MTU, флаги (up — активен, init — инициализация, running — запуск, raw — необрабатываемый режим, page scan enabled — сканирование страниц включено, inquiry scan enabled — допрашивающее сканирование включено, inquiry — допрос, authentication enabled — аутентификация включена, encryption enabled — шифрование включено).
ОПЦИИ
| -h, —help | Предоставляет список возможных команд. |
| -a, —all | Вывести всю, а не только основную информацию: возможности, тип пакетов, политика канала, режим канала, имя, класс, версию. |
КОМАНДЫ
| up | Открыть и инициализировать устройство HCI. |
| down | Закрыть устройство HCI. |
| reset | Сбросить устройство HCI. |
| rstat | Сбросить счётчики статистики. |
| auth | Включить аутентификацию (перевести устройство в режим безопасности 3). |
| noauth | Отключить аутентификацию. |
| encrypt | |
| Включить шифрование (перевести устройство в режим безопасности 3). | |
| noencrypt | |
| Отключить шифрование. | |
| secmgr | Включить диспетчера безопасности (поддержка текущим ядром ограничена). |
| nosecmgr | |
| Отключить диспетчера безопасности. | |
| piscan | Включить сканирование страниц и допрашивающее сканирование. |
| noscan | Отключить сканирование страниц и допрашивающее сканирование. |
| iscan | Включить допрашивающее сканирование, отключить сканирование страниц. |
| pscan | Включить сканирование страниц, отключить допрашивающее сканирование. |
| ptype [тип] | |
| Если тип не указан, отобразить текущие типы пакетов, иначе — установить все указанные типы пакетов. тип — это разделённый запятыми список типов пакетов, возможными значениями которых являются DM1, DM3, DM5, DH1, DH3, DH5, HV1, HV2, HV3. | |
| name [имя] | |
| Если имя не указано, вывести локальное имя, иначе — задаёт локальное имя. | |
| class [класс] | |
| Если класс не указан, вывести класс устройства, иначе — задать класс устройства. Класс — это 24-битное шестнадцатеричное число, описывающее класс устройства, как описано в разделе 1.2 документа Bluetooth Assigned Numers (назначенные номера Bluetooth). | |
| voice [голос] | |
| Если голос не указан, вывести настройку голоса, иначе — задаёт настройку голоса. Голос — это шестнадцатеричное число, описывающее настройку голоса. | |
| iac [iac] | |
| Если iac не указан, вывести текущую установку IAC, иначе — задать настройку IAC. | |
| inqtpl [уровень] | |
| Если уровень не указан, вывести текущий уровень мощности передачи допроса, иначе — установить уровень мощности передачи допроса. | |
| inqmode [режим] | |
| Если режим не указан, вывести текущий режим допроса, иначе — установить режим допроса. | |
| inqdata [данные] | |
| Если данные не указаны, вывести текущие данные допроса, иначе — установить данные допроса. | |
| inqtype [тип] | |
| Если тип не указан, вывести текущий тип сканирования допросом, иначе — установить тип сканирования допросом. | |
| inqparams [окно:интервал] | |
| Если окно:интервал не указаны, вывести окно и интервал сканирования допросом, иначе — установить окно и интервал сканирования допросом в указанные количества слотов. | |
| pageparms [окно:интервал] | |
| Если окно:интервал не указаны, вывести окно и интервал сканирования страниц, иначе — установить окно и интервал сканирования страниц в указанные количества слотов. | |
| pageto [таймаут] | |
| Если таймаут не указан, вывести таймаут страницы, иначе — задать таймаут страницы в указанное количество слотов. | |
| afhmode [режим] | |
| Если режим не указан, вывести текущий режим AFH, иначе — установить режим AFH. | |
| sspmode [режим] | |
| Если режим не указан, вывести текущий режим Simple Pairing (простого спаривания), иначе — задать режим Simple Pairing. | |
| aclmtu mtu:количество | |
| Задаёт ACL MTU в mtu байт и размер буфера ACL в указанное количество пакетов. | |
| scomtu mtu:количество | |
| Задаёт SCO MTU в mtu байт и размер буфера SCO в указанное количество пакетов. | |
| putkey | |
| Эта команда помещает канальный ключ на устройство с адресом bdaddr. | |
| delkey | |
| Эта команда удаляет сохранённый канальный ключ с устройства с адресом bdaddr. | |
| oobdata | |
| Отобразить локальные данные OOB. | |
| commands | |
| Отобразить поддерживаемые команды. | |
| features | |
| Отобразить возможности устройства. | |
| version | |
| Отобразить информацию о версии. | |
| revision | |
| Отобразить информацию о под-версии. | |
| lm [режим] | |
| Если режим не задан, вывести режим канала. MASTER или SLAVE соответственно означают запрос на переход в режим хозяина или подчинённого, если соединение запросило перейти в него. Дополнительное ключевое слово ACCEPT означает, что будут приниматься соединения в диапазоне частот, если нет сокетов AF_BLUETOOTH, ожидающих соединения. По умолчанию используется режим NONE или список ключевых слов, разделённых запятыми, где возможные ключевые слова — MASTER и ACCEPT. NONE настраивает политику канала по умолчанию, которая означает работу в подчинённом режиме и запрещает принимать соединения в диапазоне частот, если нет сокетов AF_BLUETOOTH, ожидающих соединения. Если одно из ключевых слов — MASTER, устройство перейдёт в режим хозяина, если соединение потребует этого. Если указано ACCEPT, устройство будет принимать соединения в диапазоне частот, если нет сокетов AF_BLUETOOTH, ожидающих соединения. | |
АВТОРЫ
Документ написан Максимом Краснянским (Maxim Krasnyansky) и Марселем Холтманном (Marcel Holtmann)
Страница руководства написана Фабрицио Геннари (Fabrizio Gennari)
АВТОР ПЕРЕВОДА
Перевод на русский язык выполнил Владимир Ступин .
| BlueZ | HCICONFIG (8) | 11 ноября 2002 |
Перейти в начало страницы | Раздел 8 | Главный указатель.
Сгенерировано manServer 1.07 из /home/stupin/man/man8/hciconfig.8.gz с использованием макросов man.
Bluetooth page scan что это
Чтобы установить bluescan, понадобилось также установить libglib2.0-dev, libcairo2-dev, libgirepository1.0-dev. Подсказки на разрешение этих зависимостей давала команда pip3 install bluescan. Команды для установки пакетов нужно запускать с помощью утилиты повышения уровня доступа sudo.
$ sudo apt-get install libglib2.0-dev
$ sudo apt install libcairo2-dev
$ sudo apt install libgirepository1.0-dev
$ sudo pip3 install bluescan
Примечание: новые термины и сокращения, касающиеся технологии Bluetooth, см. в Словарике [4].
Ошибка заключается, как всегда, в проблеме зависимостей кода от библиотек, которые традиционно меняются при смене версии Python. В моей версии Python 2.7.16, установленной на Paspberry Pi [1], не хватало функции removesuffix (этот метод для str появился в версии 3.9+ Python), на что указывало сообщение об ошибке:
Traceback (most recent call last): File "/usr/local/bin/bluescan", line 6, in < module >from bluescan.__main__ import main File "/usr/local/lib/python3.7/dist-packages/bluescan/__main__.py", line 19, in < module >from .br_scan import BRScanner File "/usr/local/lib/python3.7/dist-packages/bluescan/br_scan.py", line 31, in < module >from .common import bdaddr_to_company_name File "/usr/local/lib/python3.7/dist-packages/bluescan/common.py", line 28, in < module >company_id = items[0].removesuffix(' (hex)') AttributeError: 'str' object has no attribute 'removesuffix'
Я не стал заморачиваться с поиском библиотек или переустановкой Python (чтобы не начали вылезать проблемы с другими программами), и временно устранил ошибку, просто удалив вызов функции removesuffix:
#company_id = items[0].removesuffix(' (hex)') company_id = items[0]
Впоследствии можно будет либо самому дописать функцию removesuffix, либо все-таки перейти на более новую версию Python.
[Сканирование классических устройств Bluetooth]
Классические устройства (Classic Bluetooth) могут использовать 3 технологии BR (Basic Rate), EDR (Enhanced Data Rate) и AMP (Alternate MAC/PHY). Поскольку все это относится к системе Basic Rate, можно выполнить сканирование следующим образом, пример сканирования клавиатуры Bluetooth v3.0 компании Oklick, модель 840S:
pi@raspberrypi:~ $ sudo bluescan -m br Unable to init server: Could not connect: Connection refused Unable to init server: Could not connect: Connection refused
(bluescan:4061): Gdk-CRITICAL **: 12:12:55.303: gdk_cursor_new_for_display: assertion 'GDK_IS_DISPLAY (display)' failed
(bluescan:4061): Gdk-CRITICAL **: 12:12:55.306: gdk_cursor_new_for_display: assertion 'GDK_IS_DISPLAY (display)' failed [INFO] BR scanning on hci0 with timeout 10.24 sec
Addr: 0C:FC:85:4F:17:1C (Unknown) Page scan repetition mode: 1 (R1) Reserved: 0x00 CoD: 0x002540 Service Class: 0b1 Limited Discoverable Mode Major Device Class: 0b101, Peripheral (HID) Clock offset: 0x62EB RSSI: -61 Extended inquiry response: Complete Local Name: Bluetooth Keyboard Complete List of 16-bit Service Class UUIDs 0x1124 HumanInterfaceDeviceService
[INFO] Inquiry completed
[INFO] Requesting the name of the scanned devices. 0C:FC:85:4F:17:1C: Bluetooth Keyboard
Примечание: сообщения «Unable to init server» и «‘GDK_IS_DISPLAY (display)’ failed» выводятся потому, что консоль была запущена не в графическом окружении рабочего стола, а просто из консоли SSH. На эти сообщения можно не обращать внимания.
Как показано в примере выше, сканированием BR-устройств мы можем получить MAC-адрес, режим сканирования (page scan repetition mode [2]), класс устройства, смещение тактов (clock offset), уровень радиосигнала (RSSI), ответ на расширенный запрос extended inquiry response (здесь может быть информация об имени, передаваемой мощности, и т. д.).
[Сканирование служб SDP]
Классические устройства Bluetooth сообщают внешнему миру о своем функционале через SDP. После сканирования SDP будут выведены записи службы (service records) указанного Classic Bluetooth-устройства. Пример SDP-сканирования клавиатуры Bluetooth v3.0 компании Oklick, модель 840S:
pi@raspberrypi:~ $ sudo bluescan -m SDP 0C:FC:85:4F:17:1C [INFO] Scanning. Number of service records: 3
Service Record 0x0000: ServiceRecordHandle (uint32) 0x00010000 0x0001: ServiceClassIDList (sequence) 0x1124: HumanInterfaceDeviceService 0x0004: ProtocolDescriptorList (sequence) 0x0100: L2CAP PSM: 0x0011 0x0011: HIDP 0x0005: BrowseGroupList (sequence) 0x1002: PublicBrowseRoot 0x0006: LanguageBaseAttributeIDList (sequence) language name: 0x656e encoding: 0x006a attribute ID base: 0x0100 0x0009: BluetoothProfileDescriptorList (sequence) 0x1124: HumanInterfaceDeviceService v1.0 0x000d: AdditionalProtocolDescriptorList (sequence) 0x0100: L2CAP PSM: 0x0013 0x0011: HIDP 0x0100: ServiceName (text) Airoha BT Keyboard 0x0101: ServiceDescription (text) Bluetooth KB 0x0102: ProviderName (text) Airoha 0x0200: HIDDeviceReleaseNumber (Deprecated) (uint16) 0x0100 0x0201: HIDParserVersion (uint16) 0x0111: USB HID specification v1.1.1 0x0202: HIDDeviceSubclass (uint8) 0x40 0x0203: HIDCountryCode (uint8) 0x00 0x0204: HIDVirtualCable (boolean) True 0x0205: HIDReconnectInitiate (boolean) True 0x0206: HIDDescriptorList (sequence) < Element 'sequence' at 0xae045ed0 >0x0207: HIDLANGIDBaseList (sequence) < Element 'sequence' at 0xae045fc0 >0x0208: HIDSDPDisable (Deprecated) (boolean) False 0x0209: HIDBatteryPower (boolean) True 0x020a: HIDRemoteWake (boolean) True 0x020b: HIDProfileVersion (uint16) 0x0100 0x020c: HIDSupervisionTimeout (uint16) 0x0C80 0x020d: HIDNormallyConnectable (boolean) False 0x020e: HIDBootDevice (boolean) True 0x020f: HIDSSRHostMaxLatency (uint16) 0x0640 0x0210: HIDSSRHostMinTimeout (uint16) 0x0320
Service Record 0x0000: ServiceRecordHandle (uint32) 0x00010001 0x0001: ServiceClassIDList (sequence) 0x1200: PnPInformation 0x0004: ProtocolDescriptorList (sequence) 0x0100: L2CAP PSM: 0x0001 0x0001: SDP 0x0005: BrowseGroupList (sequence) 0x1002: PublicBrowseRoot 0x0009: BluetoothProfileDescriptorList (sequence) 0x1200: PnPInformation v1.0 0x0200: unknown < uint16 value="0x0103" />0x0201: unknown < uint16 value="0x05ac" />0x0202: unknown < uint16 value="0x0239" />0x0203: unknown < uint16 value="0x011b" />0x0204: unknown < boolean value="true" />0x0205: unknown < uint16 value="0x0002" />
Service Record 0x0000: ServiceRecordHandle (uint32) 0x00010006 0x0001: ServiceClassIDList (sequence) 0x1138: 3D Glasses 0x0009: BluetoothProfileDescriptorList (sequence) 0x1139: 3D Synchronization v1.0 0x0100: ServiceName (guess) (text) 3D Glasses
[Сканирование функций LMP]
Детектирование функций LMP для Classic Bluetooth устройств позволяет сделать выводы о нижележащих функций безопасности [3].
[Сканирование BLE-устройств]
Технология Bluetooth, начиная с версии 4.0, в дополнение к системе Basic Rate, поддерживает технологию Bluetooth Low Energy (BLE) system. Пример сканирования:
pi@raspberrypi:~ $ sudo bluescan -m le [WARNING] Before doing an active scan, make sure you spoof your BD_ADDR. [INFO] LE active scanning on hci0 with timeout 10 sec
----------------LE Devices Scan Result---------------- Addr: 8C:EA:48:0A:B2:C3 (Unknown) Addr type: public Connectable: False RSSI: -90 dBm General Access Profile: Manufacturer Specific Data: Company ID: 0x0075 (Samsung Electronics Co. Ltd.) Data: 42040180668CEA480AB2C38EEA480AB2C201000000000000
Addr: E7:36:C9:99:25:85 Addr type: random Connectable: True RSSI: -87 dBm General Access Profile: Manufacturer Specific Data: Company ID: 0x434E (Unknown) Data: C8CF1E3F8D0214940001 Shortened Local Name: Nordic Device
Addr: CD:5C:E2:9C:18:94 (Unknown) Addr type: public Connectable: True RSSI: -87 dBm General Access Profile: Flags: LE General Discoverable Mode BR/EDR Not Supported Manufacturer Specific Data: Company ID: 0x0157 (Anhui Huami Information Technology Co., Ltd.) Data: 02FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF02CD5CE29C1894 Complete Local Name: Mi Smart Band 4 Incomplete List of 16-bit Service Class UUIDs: 0xFEE0 Service Data - 16-bit UUID: UUID: 0xE0FE Data: 64160000
Addr: 7A:EA:14:ED:0E:F3 Addr type: random Connectable: False RSSI: -83 dBm General Access Profile: Manufacturer Specific Data: Company ID: 0x0006 (Microsoft) Data: 010920023D54168B8A79580AE7DAAB7251DF99496B2927632DB566
Addr: FD:F0:FF:F9:A9:9F Addr type: random Connectable: False RSSI: -65 dBm General Access Profile: Manufacturer Specific Data: Company ID: 0x004C (Apple, Inc.) Data: 12020002
Как показано выше, результат LE-сканирования может дать нам адрес, тип адреса, статус соединения, уровень сигнала RSSI, GAP-данные, информацию о производителе.
[Сканирование сервисов GATT]
BLE-устройства говорят внешнему миру о своих открытых службах через GATT. После сканирования GATT мы можем получить представление о функционале и способу доступа к функционалу BLE-устройства. Впоследствии мы сможем прочитать эти GATT-данные (характеристики) с помощью дополнительных утилит [5]. Пример сканирования служб GATT устройства BLE:
pi@raspberrypi:~ $ sudo bluescan -m gatt --addr-type=random D9:9D:36:54:C5:26 [INFO] Agent object registered IO capability: NoInputNoOutput [INFO] Changing D9:9D:36:54:C5:26 untrust succeeded
[INFO] Unregistered Agent object
----------------GATT Scan Result---------------- Number of services: 3
Service (0x0001 - 0x0009, 4 characteristics) Handle: 0x0001 Type: 0x2800 (Primary Service) Value: 00001800-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization
Characteristic (0 descriptors) Handle: 0x0002 Type: 0x2803 (Characteristic) Value: Properties: READ WRITE Handle: 0x0003 UUID: 00002A00-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization Value Handle: 0x0003 Type: 00002A00-0000-1000-8000-00805F9B34FB (Unknown) Value: b'Nordic Relay' Permissions: Higher layer profile or implementation specific
Characteristic (0 descriptors) Handle: 0x0004 Type: 0x2803 (Characteristic) Value: Properties: READ Handle: 0x0005 UUID: 00002A01-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization Value Handle: 0x0005 Type: 00002A01-0000-1000-8000-00805F9B34FB (Unknown) Value: b'\x00\x00' Permissions: Higher layer profile or implementation specific
Characteristic (0 descriptors) Handle: 0x0006 Type: 0x2803 (Characteristic) Value: Properties: READ Handle: 0x0007 UUID: 00002A04-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization Value Handle: 0x0007 Type: 00002A04-0000-1000-8000-00805F9B34FB (Unknown) Value: b'\x06\x00\x18\x00\x00\x00\x90\x01' Permissions: Higher layer profile or implementation specific
Characteristic (0 descriptors) Handle: 0x0008 Type: 0x2803 (Characteristic) Value: Properties: READ Handle: 0x0009 UUID: 00002AA6-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization Value Handle: 0x0009 Type: 00002AA6-0000-1000-8000-00805F9B34FB (Unknown) Value: b'\x01' Permissions: Higher layer profile or implementation specific
Service (0x000A - 0x000A, 0 characteristics)
Handle: 0x000A Type: 0x2800 (Primary Service) Value: 00001801-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization
Service (0x000B - 0xFFFF, 2 characteristics) Handle: 0x000B Type: 0x2800 (Primary Service) Value: 000018FF-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization
Characteristic (0 descriptors) Handle: 0x000C Type: 0x2803 (Characteristic) Value: Properties: READ NOTIFY Handle: 0x000D UUID: 00002A99-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization
Value Handle: 0x000D Type: 00002A99-0000-1000-8000-00805F9B34FB (Unknown) Value: b'' Permissions: Higher layer profile or implementation specific
Characteristic (0 descriptors) Handle: 0x000F Type: 0x2803 (Characteristic) Value: Properties: WRITE NO RESPONSE WRITE Handle: 0x0010 UUID: 00002A3D-0000-1000-8000-00805F9B34FB (Unknown) Permissions: Read Only, No Authentication, No Authorization Value Handle: 0x0010 Type: 00002A3D-0000-1000-8000-00805F9B34FB (Unknown) Value: Unknown Permissions: Higher layer profile or implementation specific
[Ссылки]
1. Raspberry Pi, быстрый старт.
2. Scan Repetition site:dziwior.org.
3. Bluescan Bluetooth Scanner For Scanning BR/LE Devices, LMP, SDP site:pentesttools.net.
4. Bluetooth: аббревиатуры и термины.
5. Сканирование сетей BLE в Linux.