Андрей Бешков
Некоторое время назад у меня возникла необходимость по выходным дням
наведываться через Интернет в локальную сеть моего работодателя. Казалось бы,
решение вопроса банально. Купить простенький модем, присоединить его к своей
домашней телефонной линии и с помощью обычного десктопа делать то, что нужно.
Но душа просила чего-то более удобного и мобильного. И тогда было решено
подружить между собой мои служебные железки – ноутбук Samsung p25 и мобильный
телефон Nokia 6310i. Побродив по просторам сети и посмотрев, как народ решает
подобные проблемы, я уже было подумал купить себе соединительный кабель Nokia,
прицепить его к последовательному порту и через него работать с GSM-модемом,
встроенным в телефон. Но потом в голову стали приходить мысли о том, что
фирменный соединительный кабель, в отличие от китайских подделок, – штука
дорогая, к тому же при смене модели телефона кабель становится для меня
совершенно бесполезен. Поэтому пришлось перейти ко второму варианту подключения
– к использованию инфракрасной связи IrDA (Infrared Direct Access). Благо
соответствующий функционал был встроен и в телефон, и в ноутбук. Но и тут не
обошлось без недостатков. Во-первых, существует ограничение по радиусу
действия. Во-вторых, устойчивое взаимодействие устройств возможно только в зоне
прямой видимости, что не очень легко выполнить на рабочем столе, заваленном
книгами и распечатками. К тому же глазки IrDA-излучателей должны быть
направлены строго друг на друга и при этом желательно, чтобы приборы не
двигались. Следовать этим требованиям, конечно, возможно, но уж слишком
неудобно себя чувствуешь, да и мобильность какая-то ненастоящая получается.
Немного подумав, я пришел к выводу, что самым
лучшим выходом из сложившейся ситуации будет использование Bluetooth. Телефон
был готов к такому применению, а вот с ноутбуком вышла промашка. На его корпусе
среди прочих полезных сведений о комплектации виднелась надпись, поначалу
внушившая надежду: «Поддержка Memory Stick Slot и Bluetooth». А еще ниже мелким
шрифтом значилось «опция», и, как всегда, эта загадочная дама со странным
именем обошла нас своей благосклонностью. Итак, решено: будем покупать
Bluetooth USB адаптер, в англоязычной документации называемый Bluetooth USB
dongle, а в просторечии «синий свисток». В связи с тем, что на ноутбуке
установлены две операционные системы, встает вопрос, какой именно адаптер
покупать. С Windows проблем, скорее всего, не будет, потому как большинство
производителей оборудования затачивает свои изделия именно под эту ОС. А вот с
Linux крепкой дружбы никто не обещал. Список оборудования, которое удалось
заставить нормально работать под Linux, можно посмотреть тут: http://www.holtmann.org/linux/bluetooth/devices.html.
В нашем случае особое внимание стоит уделить разделу «Bluetooth USB adapters».
Проанализировав прочитанное, пришел к выводу, что самой выгодной покупкой по
соотношению цена-качество будет адаптер BT009X, производимый тайваньской фирмой
Bluetake Technology. Купленное устройство выглядело изящно, миниатюрно и весило
примерно грамм 50. Не удержавшись, конечно разобрал его, посмотрел, что внутри.

Удовлетворив любопытство, самое время вернуться к
предмету нашего разговора.
История появления Bluetooth и
механизмы его действия
Началось все примерно тысячу лет назад. В середине X века Данией правил
король – викинг Гарольд I по прозвищу Синий зуб. Он провозгласил девиз
«объединяйтесь все» и собственноручно стал осуществлять его. Благодаря
стараниям короля множество разрозненных княжеств объединились в сильное
государство, завладевшее к тому же частью земель Швеции и Норвегии.
В 1994 году компания Ericsson задалась целью
придумать способ соединения различных устройств с помощью беспроводной связи. К
началу 1997 года разработки, ведущиеся внутри фирмы, начали приносить первые
результаты. Было принято решение о начале переговоров с остальными крупными
производителями телекоммуникационного оборудования. Весной 1998 года компании
Intel, IBM, Nokia, Ericsson и Toshiba объявили о начале совместных работ по
созданию универсального стандарта коммуникаций для бытовых устройств. В честь
доблестного короля – объединителя викингов стандарт решено было назвать Bluetooth,
а само содружество рабочих групп компаний получило обозначение Bluetooth
Special Interest Group (BSIG). Постепенно принять участие в начинании и
присоединиться к BSIG решили Lucent, Motorola, Sun Microsystems, 3Com, Agere,
Microsoft и многие другие производители разнородного оборудования и
программного обеспечения. На данный момент ассоциация разработчиков Bluetooth
насчитывает более двух тысяч компаний разного масштаба и несколько десятков
тысяч волонтеров, принимающих участие в работе над проектом.
В сущности идея проекта довольно проста:
необходимо стандартизировать механизмы соединения всех видов сотовых телефонов,
компьютеров, наладонников, гарнитур hands-free и прочего движимого и
недвижимого оборудования. Добиться этого можно, если отделить механизмы
реализации связи между устройствами от самих устройств. Пусть проблемами
общения занимаются миниатюрные радиоинтерфейсы, встроенные в каждый прибор. Они
работают на частоте 2,45 ГГц ISM (Industrial-Scientific-Medical). В большинстве
стран для вещания в этом диапазоне не требуется дополнительного лицензирования.
Исключением являются Франция, Испания и Япония. Диапазон частот от 2,402 ГГц до
2,480 ГГц разбивается на 79 каналов размером в 1 МГц. Для уменьшения помех от
внешних устройств вроде СВЧ-печей и повышения безопасности 1600 раз в секунду
происходит псевдослучайный выбор одного из каналов. Отправка данных происходит
уже с новым значением базовой частоты, взятым из выбранного интервала. Таким
образом, получается, что приемник и передатчик синхронно переключают каналы
связи. В англоязычной литературе это явление называется Frequency Hopping.
На данный момент существуют два основных подвида
bluetooth-устройств. Отличаются они только дальностью действия. Большинство
имеют зону уверенного приема сигнала радиусом в 10 метров. Хотя некоторые
экземпляры обладают усилителем сигнала и способны взаимодействовать друг с
другом на расстоянии 100 метров при условии, что все это будет происходить на
открытой местности.
Еще одним интересным свойством
такого способа общения является возможность спонтанного
объединения нескольких bluetooth-устройств в своеобразную динамическую
локальную мини-сеть, называемую piconet. Давайте разберемся, как это
реализовано на практике. Устройства, не присоединенные ни к одному piconet, находятся
в режиме Standby и каждые 1,28 секунды слушают эфир на 32 зарезервированных для
этого частотах. Как только они входят в зону устойчивой взаимной слышимости с
другим устройством, одно из устройств принимает на себя главенствующую роль и
начинает отсылать в эфир пакеты Inquiry. После отправки 16 пакетов по одному на
каждую частоту наступает пауза, в течение которой должны прийти ответы от
подчиненных устройств. Если никто не отозвался, то проверяются оставшиеся 16
частот. Обнаружение активных устройств зависит от того, в каком режиме они
находятся:
n Non-discoverable – не отвечает на запросы о
присоединении к piconet.
n Limited discoverable – в этом режиме находятся
устройства, которые отвечают на запрос только в определенное время или при
соблюдении некоторых условий.
n Discoverable mode – отвечает на все полученные
запросы.
На самом деле все обстоит еще сложнее. Вдобавок
для того, чтобы присоединение к сети состоялось, устройство должно работать в
режиме connectable. Если же оно находится в режиме non-connectable, то соседям,
скорее всего, удастся его обнаружить, но обмениваться данными с ним будет
невозможно.
В случае если все необходимые формальности
соблюдены, устройство, инициировавшее обмен пакетами, становится ведущим
(Master), а остальные принимают роль ведомых (Slave). При необходимости любое
из ведомых устройств может запросить смену роли и стать мастером взамен
прежнего лидера. В момент присоединения к piconet каждое Slave-устройство
получает от мастера FHS-пакет, в котором содержится Global_ID, используемый для
определения номера шаблона прыжков по частотному диапазону и параметр clock,
указывающий смещение внутри этого самого шаблона. Войдя в piconet, ведомое
устройство получает трехбитный адрес AMA (Active Member Adress), тем самым
показывая, что оно готово к общению с соседями. Мастер-устройство всегда имеет
адрес 0. С помощью трех бит возможно адресовать не более восьми устройств,
таким образом, получается, что внутри piconet будут одновременно разговаривать
только мастер и семеро подчиненных. Из-за этого в русскоязычных статьях о
bluetooth укоренилось одно из распространенных заблуждений, гласящее, что в
piconet не может быть более восьми устройств. Давайте посмотрим, почему это не
соответствует действительности. При входе в piconet девятого устройства мастер
принудительно переводит одного из подчиненных в режим Park и отбирает у него
адрес AMA, выдавая взамен восьми-битный адрес PMA (Passive Member Adress).
Освободившийся AMA-адрес отдается вновь прибывшему. Припаркованные устройства
продолжают периодически прослушивать эфир в надежде услышать информацию,
адресованную им. В случае если устройство с PMA-адресом хочет что-то сказать,
ему приходится спросить разрешения у мастера, получить отобранный у кого-то
другого AMA-адрес и только после этого начать передавать данные. Комбинация из
AMA- и PMA-адресов позволяет иметь в одном piconet 256 устройств, из которых
лишь 8 активно передают данные. Для экономии энергии мастер может перевести
любое из подчиненных устройств в режимы Hold или Sniff, тем самым говоря:
«Просыпайся каждые n интервалов». Разница между ними состоит в том, что в
режиме Hold устройство должно молчать между пробуждениями, а в режиме Sniff в
случае необходимости оно может передавать данные. В то же время само
управляемое устройство может запросить перевод в любой из вышеупомянутых
режимов.
Мини-сети легко могут сообщаться между собой
через устройства, находящиеся в зоне действия двух и более сетей. Таким
образом, они объединяются в структуры, называемые Scatternet. Стоит отметить
тот факт, что устройство может быть мастером лишь в одном piconet, но это не
мешает ему входить в другой piconet в роли подчиненного. Примерную схему
Scatternet, состоящую из трех piconet, можно увидеть на следующем рисунке.

Разобравшись с тем, как строятся взаимоотношения
bluetooth-устройств на самом нижнем уровне, давайте посмотрим, как реализован
стек протоколов.

Все базируется на радиочастотных
каналах, о которых мы говорили выше по тексту, RF (Radio Frequnce). Каналами
управляет аппаратура Baseband. Выше находится Link Manager, реализующий
протокол LMP (Link Manager Protocol). В его задачи входит управление каналом и
реализация процедур безопасности на физическом уровне. Следующим в иерархии
числится L2CAP (Logical Link Control and Adaptation Layer Protocol). Он
является базовым транспортным протоколом передачи данных. Большинство
вышестоящих протоколов пользуются его услугами для приема и отправки пакетов.
Основные свойства L2CAP, на которые стоит обратить внимание:
n Protocol Multiplexing – позволяет определить,
кому из протоколов верхнего уровня предназначены те или иные пакеты.
n Segmentation and Reassembly – максимальный
размер пакета L2CAP установлен в 64 кб, а Baseband оперирует пакетами размером
в 341 байт. Поэтому L2CAP отправителя обязан создавать из больших пакетов
последовательность мелких, а получатель в свою очередь должен склеивать их по
мере поступления.
n QOS – позволяет гарантировать, что ширина
полосы и временные задержки для важного трафика не достигнут критических
пределов.
Перейдем к протоколам верхнего
уровня. Думаю, с TCP/IP все ясно. Протокол HID реализует взаимодействие с
устройствами Human Interface Design. К устройствам такого типа принадлежат
модификации клавиатур, мышей и прочего оборудования, с которым напрямую взаимодействуюет
человек. RFCOMM эмулирует соединение точка-точка через интерфейс стандартного
последовательного COM-порта, передавая данные поверх L2CAP. Следующим
интересным для нас протоколом является SDP (Service Discovery Protocol). В его
обязанности входит выполнение следующих действий:
n Поиск и выбор сервисов, предоставляемых другими
устройствами по специальным критериям.
n Поиск сервисов по классам. К примеру, если нам
нужно найти устройство, предоставляющее сервис Dial-up networking, то поиск
должен вернуть нам имена только тех устройств, внутри которых есть модем.
n Поддерживать базу данных доступных служб в
актуальном состоянии.
Еще одним объектом, заслуживающим нашего внимания
является HCI (Host Controller Interface). Он представляет собой командный интерфейс
к контроллеру baseband и слою, реализующему Link Manager. С его помощью можно
узнавать и изменять состояние контрольных регистров bluetooth-устройств.
Закончив с протоколами верхнего уровня, хотелось бы поговорить о службе audio,
часто называемой bluetooth voice. С ее помощью могут одновременно передаваться
три голосовых потока. Характеристики каждого из них определяются приложением,
передающим данные. Максимальное возможное качество звука достигается при
частоте дискретизации в 48 кГц. На схеме от компонента audio не зря исходят две
стрелки. Дело в том, что звук может передаваться либо напрямую через Baseband,
либо, как и все остальные данные, через L2CAP. Конечно, в случае передачи
голоса через L2CAP устройство получает меньше возможностей управлять голосовым
трафиком, но такой подход позволяет легко стыковать bluetooth- и не
bluetooth-сети. Плюс ко всему появляется возможность шифровать голосовой трафик
алгоритмами повышенной стойкости.
Раз уж зашел разговор о
шифровании, стоит поговорить о системе безопасности, применяемой в устройствах
bluetooth. Технология защиты данных изначально встроена в протокол. В
зависимости от ценности передаваемых данных можно применять один из трех
режимов безопасности.
n Security mode 1 (non secure) – устройство не
инициирует никаких защитных процедур и полностью открыто для общения.
n Security mode 2 (service level enforced
security) – защитные процедуры выполняются только после установления и
настройки параметров соединения. Требования безопасности в данном случае определяют
службы, передающие трафик.
n Security mode 3 (link level enforced security)
– защита инициализируется в процессе установления и настройки соединения. В
случае если второе устройство не может выполнить требования безопасности,
соединение беспрекословно разрывается.
Стоит обратить внимание на то, что второй и
третий режимы можно комбинировать, обеспечивая повышенную безопасность
соединения. Получается, что сначала устанавливается защищенное соединение, а
затем данные, передаваемые по нему, шифруются в соответствии с требованиями
сервисов отправителя и получателя.
Краеугольным камнем системы безопасности
bluetooth является сеансный ключ. Он создается в момент соединения и
впоследствии используется для шифрования и идентификации всего передаваемого
трафика. Впрочем, никто не мешает дополнительно шифровать трафик на уровне
приложений.
Несмотря на попытку рассказывать только о
ключевых моментах, оставляя несущественные подробности за бортом, я,
признаться, немного устал излагать теорию работы bluetooth. Посему предлагаю
сейчас же перейти к практическому применению полученных знаний.
Bluetooth + Linux на практике
Чтобы система смогла увидеть наше usb bluetooth-устройство, первым делом
убеждаемся, что мы работаем на достаточно свежем ядре. У меня используется ALT
Linux, версия ядра 2.4.26-std-up-alt6. Давайте посмотрим, какой тип контроллера
USB у нас установлен.
# lspci
00:00.0 Host
bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
00:01.0 PCI
bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
00:1d.0 USB
Controller: Intel Corp. 82801DB (ICH4) USB UHCI #1 (rev 03)
00:1d.1 USB
Controller: Intel Corp. 82801DB (ICH4) USB UHCI #2 (rev 03)
00:1d.2 USB
Controller: Intel Corp. 82801DB (ICH4) USB UHCI #3 (rev 03)
00:1d.7 USB
Controller: Intel Corp. 82801DB (ICH4) USB2 EHCI Controller (rev 03)
00:1e.0 PCI
bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 83)
00:1f.0 ISA
bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03)
00:1f.1 IDE
interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage Controller (rev 03)
00:1f.3 SMBus:
Intel Corp. 82801DB/DBM (ICH4) SMBus Controller (rev 03)
00:1f.5
Multimedia audio controller: Intel Corp. 82801DB (ICH4) AC'97 Audio Controller
(rev 03)
00:1f.6 Modem:
Intel Corp. 82801DB (ICH4) AC'97 Modem Controller (rev 03)
01:00.0 VGA
compatible controller: ATI Technologies Inc Radeon R250 Lf [Radeon Mobility
9000 M9] (rev 02)
02:03.0 CardBus
bridge: Ricoh Co Ltd RL5c475 (rev b8)
02:03.1 FireWire
(IEEE 1394): Ricoh Co Ltd R5C551 IEEE 1394 Controller
02:07.0 CardBus
bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
02:08.0 Ethernet
controller: Intel Corp. 82801BD PRO/100 VE (LOM) Ethernet Controller (rev 83)
Судя по выводу, у нас есть UHCI- и
EHCI-контроллеры USB. Проверяем, что написано про USB в /etc/modules, среди
всего прочего там должны быть строки:
usbcore
usb-uhci
А в файле /etc/modules.conf нужно найти следующее
сочетание символов:
alias usb-interface usb-uhci
Теперь необходимо убедиться в том, что все
модули, необходимые для поддержки USB, загружены в память.
lsmod | grep usb
hci_usb
8600 1
usb-storage
139744 0
usb-uhci
21676 0 (unused)
usbcore
58464 1 [hci_usb ehci-hcd usb-storage usb-uhci]
scsi_mod
95296 5 [sg sr_mod sd_mod usb-storage ide-scsi]
Если это не так, то следует перезагрузить
систему, чтобы загрузка нужных модулей прошла автоматически на основе
содержимого файлов /etc/modules и /etc/modules.conf, либо загрузить модули
вручную с помощью команды insmod.
Подробнее почитать о реализации USB в Linux можно
в статье Виктора Костромина http://vikos.lrn.ru//kos.php?name=
papers/usb/USB-Lin.html и, конечно же, на сайте www.linux-usb.org.
Тут нужно сделать маленькое отступление. Дело в
том, на свете существует несколько реализаций стека протоколов bluetooth. Самые
распространенные из них – это OpenBT, первоначально созданный фирмой Axis: http://developer.
axis.com/software/bluetooth и Bluez – детище Qualcom http://bluez.sourceforge.net. Оба
поставляются вместе с исходниками. Некоторое время назад безусловным лидером
являлся OpenBT, потому что его реализация на тот момент была надежнее и проще.
Да и возможности работы с BCSP были весьма мощные. Но по мере дозревания Bluez
стал догонять, а затем и превзошел OpenBT по всем показателям. Отдельного
упоминания стоит удобство и гибкость использования PAN (Personal Area Network).
К тому же Bluez позволяет легко работать с протоколом OBEX поверх RFCOMM. В
деле популяризации Bluez не последнюю роль сыграл тот факт, что он по умолчанию
включен во все новые ядра Linux. К тому же алгоритмы работы с RFCOMM у Bluez
оказались написаны на редкость удачно, что позволило создавать весьма гибкие
решения.
Также стоит упомянуть, что в природе существуют
программные комплексы BlueDrekar от IBM: http://www.alphaWorks.ibm.com/tech/bluedrekar
и Affix от Nokia http://affix.
sourceforge.net. Внутри первого из них встроена полноценная реализация
bluetooth, но, к сожалению, исходных текстов этого продукта никто не видел. А
вот вторая разработка, изначально развивавшаяся под эгидой компании Nokia, на
данный момент является типичным OpenSource.
Приняв во внимание все вышеизложенные факты,
делаем однозначный вывод. Для работы с нашими bluetooth-устройствами удобнее
всего будет использовать Bluez.
Настало время установить пакеты, необходимые для
работы bluetooth.
# apt-get install libbluez
libbluez-devel bluez-hciemu bluez-hcidump bluez-utils
Смотрим, что добавилось в /etc/modules.conf:
alias net-pf-31
bluez
alias bt-proto-0
l2cap
alias bt-proto-2
sco
Перезагружаем машину, чтобы проверить, как
автоматически загружаются модули bluez. Конечно, можно было загрузить их
вручную с помощью modprobe и imsmod, но мне больше нравится, чтобы все делалось
автоматически. После окончания загрузки системы проверяем, как себя чувствует
модуль bluez.
# lsmod | grep
bluez
bluez
30116 1 [hci_usb]
Затем вставляем bluetooth-адаптер в разъем USB. В
файле /var/log/messages и на двенадцатой консоли должны появиться следующие
сообщения:
Sep 28 21:23:19
tiger kernel: hub.c: new USB device 00:1d.0-1, assigned address 2
Sep 28 21:23:24
tiger kernel: BlueZ Core ver 2.3 Copyright (C) 2000,2001 Qualcomm Inc
Sep 28 21:23:24
tiger kernel: Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
Sep 28 21:23:24
tiger kernel: BlueZ HCI USB driver ver 2.5 Copyright (C) 2000,2001 Qualcomm Inc
Sep 28 21:23:24
tiger kernel: Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
Sep 28 21:23:24
tiger kernel: usb.c: registered new driver hci_usb
Стоит отметить, что каждое bluetooth-устройство
имеет уникальный шестизначный адрес, в дальнейшем называемый BD (Bluetooth
Device)-адрес. Больше все это похоже на MAC-адреса обычных сетевых карт.
Проверяем, как система видит наш USB-адаптер.
# hciconfig -a
hci0: Type: USB
BD Address:
00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0
sco:0 events:0 errors:0
TX bytes:0 acl:0
sco:0 commands:0 errors:0
Features: 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00
Packet type: DM1
DH1 HV1
Link policy:
Link mode: SLAVE
ACCEPT
Надпись «DOWN» и BD-адрес, полный нолей, говорят
о том, что в системе не запущен демон hcid (Bluetooth Host Controller Interface
Daemon). Поведение демона определяется настройками, обычно находящимися в файле
/etc/bluetooth/hcid.conf. Давайте посмотрим, как выглядит содержимое этого
файла, и разберемся, что именно означает каждая опция. Файл
/etc/bluetooth/hcid.conf:
options {
# Автоматически
инициализировать новые устройства
#
autoinit yes;
# Настройки менеджера
безопасности:
# none – менеджер
отключен;
# auto – при получении
входящего соединения запрашивать PIN-код;
# user – запрашивать
PIN-код всех соединений
# без исключения
#
security auto;
# Настройки соединения в
пару:
# none – соединение
отключено;
# multi – разрешение
создавать пару с теми устройствами, которые уже состоят в других парах;
# once – производить
попытку соединения только один раз
#
pairing multi;
# Программа, принимающая
PIN-код от пользователя и передающая его удаленному bluetooth-устройству,
# обычно называется
pin_helper.
#
pin_helper
/usr/bin/bluepin;
# Имя программы, выдающей
PIN для режима D-Bus, как видите, в нашем случае она не используется
#
#dbus_pin_helper;
}
# Настройки по умолчанию для
всех HCI-устройств
device {
# Имя локального
bluetooth-устройства в принципе может быть любым, хотя, конечно, лучше вписать
что-то
# осмысленное. В качестве
необязательного дополнения можно вписать в текст имени символы подстановки.
# %d – id устройства
# %h – имя хоста
# Например, такая запись
name "Bluetooth (%h)" в моей системе создаст имя устройства
«Bluetooth tiger».
# В случае если имя хоста
слишком длинное, подстановка может не производиться. Соответственно, получим
просто
# «Bluetooth».
#
name "tigroid";
# Класс локального устройства.
# 0x100 обозначает
компьютер.
#
class 0x100;
# Тип пакетов по
умолчанию.
# Обычно разрешены все
возможные типы.
# DM3 DM5 DH1 DH3 DH5 HV1
HV2 HV3
#pkt_type DH1, DM1, HV1;
# Разрешение на
сканирование устройств методами Inquiry и Page
#
iscan enable;
pscan enable;
# Режим соединения по
умолчанию
# none – не использовать
никаких политик для соединения
# accept – всегда
принимать входящие соединения
# master – брать на себя
роль ведущего устройства при получении входящего соединения, и запрещать смену
# ролей для исходящих
соединений.
#
lm accept, master;
# Политика соединения по
умолчанию
# none – не использовать
никаких политик для соединения
# rswitch – разрешить
смену ролей
# hold – разрешить режим
hold
# sniff – разрешить режим
sniff
# park – разрешить
парковку
#
lp rswitch, hold, sniff,
park;
# Аутентификация и
шифрование
auth enable;
encrypt enable;
}
Закончив изучение настроек, запускаем демон hcid
и смотрим, как изменились характеристики USB bluetooth-адаптера.
# hcid
# hciconfig -a
hci0: Type: USB
BD Address:
00:0A:3A:53:36:41 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN
ISCAN AUTH ENCRYPT
RX bytes:2947
acl:80 sco:0 events:149 errors:0
TX bytes:2610
acl:59 sco:0 commands:61 errors:0
Features: 0xff
0xff 0x0b 0x00 0x00 0x00 0x00 0x00
Packet type: DM1
DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
RSWITCH
Link mode: SLAVE
ACCEPT
Name: 'tigroid'
Class: 0x000100
Service Classes:
Unspecified
Device Class:
Computer, Uncategorized
HCI Ver: 1.1
(0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x20d
Manufacturer:
Cambridge Silicon Radio (10)
Судя по выводу, все идет как надо. Локальное
bluetooth-устройство получило BD-адрес 00:0A:3A:53:36:41. Давайте теперь поищем
удаленные bluetooth-устройства. Для этого включаем bluetooth на телефоне.

Указанием на то, что телефон включил bluetooth,
можно считать появление в верхнем левом углу дисплея значка, изображающего
радиоволны.
С помощью утилиты hcitool начинаем сканирование
окружающего пространства.
# hcitool scan
Scanning ...
00:02:EE:B6:6A:E5 Nokia 6310i
Наш телефон благополучно нашелся. Теперь мы
знаем, что его BD-адрес 00:02:EE:B6:6A:E5. В дальнейшем мы будем обращаться к
нему именно по этому адресу. Проверим, насколько надежно работает передача пакетов
между двумя устройствами. Для этого воспользуемся программой l2ping.
# l2ping
00:02:EE:B6:6A:E5
Ping:
00:02:EE:B6:6A:E5 from 00:0A:3A:53:36:41 (data size 20) ...
0 bytes from
00:02:EE:B6:6A:E5 id 200 time 31.69ms
0 bytes from
00:02:EE:B6:6A:E5 id 201 time 39.49ms
0 bytes from
00:02:EE:B6:6A:E5 id 202 time 30.31ms
0 bytes from
00:02:EE:B6:6A:E5 id 203 time 34.12ms
4 sent, 4
received, 0% loss
Теперь посмотрим дополнительную информацию об
удаленном устройстве.
# hcitool info
00:02:EE:B6:6A:E5
Requesting
information ...
BD
Address: 00:02:EE:B6:6A:E5
Device
Name: Nokia 6310i
LMP
Version: 1.1 (0x1) LMP Subversion: 0x22c
Manufacturer: Nokia Mobile Phones (1)
Features:
0xbf 0x28 0x21 0x00 0x00 0x00 0x00 0x00
<3-slot
packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <sniff mode> <SCO link>
<HV3 packets> <CVSD>Х
В комплект программ, предназначенных для работы с
HCI, входит еще одна полезная программа, hcidump. Думаю, по ее названию вы
смогли догадаться, что перед нами утилита для прослушивания трафика,
проходящего через HCI-интерфейсы. Эта программа становится особенно полезной в
ситуациях, когда не удается подружить два bluetooth-устройства. К примеру,
давайте посмотрим, какие данные проходят через используемый нами интерфейс hci0
во время выполнения команды hcitool info. Для этого на одной консоли запускаем
hcidump, а на второй снова выполняем команду hcitool info.
# hcidump -i hci0
-X
HCIDump - HCI
packet analyzer ver 1.12
device: hci0
snap_len: 1028 filter: 0xffffffff
> HCI Event:
Command Status (0x0f) plen 4
0000: 00 01 05
04 ....
> HCI Event:
Command Complete (0x0e) plen 10
0000: 01 0b 04
00 e5 6a b6 ee 02 00 .....j....
> HCI Event:
Connect Complete (0x03) plen 11
0000: 00 29 00
e5 6a b6 ee 02 00 01 01 .)..j......
> HCI Event:
Command Complete (0x0e) plen 6
0000: 01 0d 08
00 29 00 ....).
> HCI Event:
Command Status (0x0f) plen 4
0000: 00 01 19
04 ....
> HCI Event:
Remote Name Req Complete (0x07) plen 255
0000: 00 e5 6a
b6 ee 02 00 4e 6f 6b 69 61 20 36 33 31 ..j....Nokia 631
0010: 30 69 00
00 00 00 00 00 00 00 00 00 00 00 00 00 0i..............
0020: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00d0: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00e0: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0: 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 ...............
> HCI Event:
Command Status (0x0f) plen 4
0000: 00 01 1d
04 ....
> HCI Event:
Read Remote Ver Info Complete (0x0c) plen 8
0000: 00 29 00
01 01 00 2c 02 .)....,.
> HCI Event:
Command Status (0x0f) plen 4
0000: 00 01 1b
04 ....
> HCI Event:
Read Remote Supported Features (0x0b) plen 11
0000: 00 29 00
bf 28 21 00 00 00 00 00 .)..(!.....
> HCI Event:
Command Status (0x0f) plen 4
0000: 00 01 06
04 ....
> HCI Event:
Disconn Complete (0x05) plen 4
0000: 00 29 00
16 .)..
> HCI Event:
Command Status (0x0f) plen 4
> HCI Event:
Read Remote Supported Features (0x0b) plen 11
> HCI Event:
Command Status (0x0f) plen 4
> HCI Event:
Disconn Complete (0x05) plen 4
С помощью ключа –i можно указать, какой именно
интерфейс нужно прослушивать. В нашем случае это hci0. Делать это необходимо
только в системах с двумя и более hci-интерфейсами. В противном случае hcidump
будет прослушивать первый по порядку интерфейс.
Как говорил один известный персонаж, «Все ходы у
нас записаны». И в случае чего можно будет запросто заняться отладкой
неработающего соединения.
Теперь было бы интересно узнать, какие сервисы
Nokia 6310i может нам предоставить. Для этого на компьютере должен работать
sdp-демон, который реализует протокол Service Discovery Protocol. А вслед за
ним необходимо запустить утилиту sdptool, получающую данные от демона и
показывающую их пользователю.
# sdpd
# sdptool browse
00:02:EE:B6:6A:E5
Browsing
00:02:EE:B6:6A:E5 ...
Service Name: Fax
Service
RecHandle: 0x1001e
Service Class ID
List:
"Fax"
(0x1111)
"Generic
Telephony" (0x1204)
Protocol
Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
Language Base
Attr List:
code_ISO639:
0x656e
encoding:
0x6a
base_offset:
0x100
Profile
Descriptor List:
"Fax"
(0x1111)
Version:
0x0100
Service Name:
OBEX Object Push
Service
RecHandle: 0x1001f
Service Class ID
List:
"OBEX
Object Push" (0x1105)
Protocol
Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 9
"OBEX" (0x0008)
Language Base
Attr List:
code_ISO639:
0x656e
encoding:
0x6a
base_offset:
0x100
Profile
Descriptor List:
"OBEX
Object Push" (0x1105)
Version:
0x0100
Service Name:
Audio Gateway
Service
RecHandle: 0x10020
Service Class ID
List:
"Headset
Audio Gateway" (0x1112)
"Generic
Audio" (0x1203)
Protocol
Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 12
Language Base
Attr List:
code_ISO639:
0x656e
encoding:
0x6a
base_offset:
0x100
Profile
Descriptor List:
"Headset" (0x1108)
Version: 0x0100
Service Name: COM
1
Service
RecHandle: 0x10021
Service Class ID
List:
"Serial
Port" (0x1101)
Protocol
Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Language Base
Attr List:
code_ISO639:
0x656e
encoding:
0x6a
base_offset:
0x100
Service Name:
Voice Gateway
Service
RecHandle: 0x10022
Service Class ID
List:
""
(0x111f)
"Generic
Audio" (0x1203)
Protocol
Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 13
Language Base
Attr List:
code_ISO639:
0x656e
encoding:
0x6a
base_offset:
0x100
Profile
Descriptor List: