Журнал Системный Администратор, Октябрь 2004

Журнал Системный Администратор

Октябрь 2004

Цена: $4.5 US

  Подписаться

Зарегистриванные пользователи, пожалуйста следуйте этой ссылке

Версия для печати Вернуться к оглавлению

Bluetooth + Linux, или Синий зуб на службе cистемного администратора

Андрей Бешков

Некоторое время назад у меня возникла необходимость по выходным дням наведываться через Интернет в локальную сеть моего работодателя. Казалось бы, решение вопроса банально. Купить простенький модем, присоединить его к своей домашней телефонной линии и с помощью обычного десктопа делать то, что нужно. Но душа просила чего-то более удобного и мобильного. И тогда было решено подружить между собой мои служебные железки – ноутбук 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 метров при условии, что все это будет происходить на открытой местности.

Еще одним интересным свойством такого способа общения является возможность спонтанного[1] объединения нескольких 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;

 

    # Тип пакетов по умолчанию.

    # Обычно разрешены все возможные типы[2].

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