новости
статьи
.sysadmin

подключаем Bluetooth-телефон к Linux

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



Рис. 1.



Рис. 2.

Удовлетворив любопытство, самое время вернуться к предмету нашего разговора.

история появления 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 частот. Обнаружение активных устройств зависит от того, в каком режиме они находятся:

- non-discoverable – не отвечает на запросы о присоединении к piconet;

- limited discoverable – в этом режиме находятся устройства, которые отвечают на запрос только в определенное время или при соблюдении некоторых условий;

- 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, можно увидеть на рисунке 3.



Рис. 3.

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



Рис. 4.

Все базируется на радиочастотных каналах, о которых мы говорили выше по тексту, RF (Radio Frequnce). Каналами управляет аппаратура Baseband. Выше находится Link Manager, реализующий протокол LMP (Link Manager Protocol). В его задачи входит управление каналом и реализация процедур безопасности на физическом уровне. Следующим в иерархии числится L2CAP (Logical Link Control and Adaptation Layer Protocol). Он является базовым транспортным протоколом передачи данных. Большинство вышестоящих протоколов пользуются его услугами для приема и отправки пакетов. Основные свойства L2CAP, на которые стоит обратить внимание:

- Protocol Multiplexing – позволяет определить, кому из протоколов верхнего уровня предназначены те или иные пакеты.

- Segmentation and Reassembly – максимальный размер пакета L2CAP установлен в 64 кб, а Baseband оперирует пакетами размером в 341 байт. Поэтому L2CAP отправителя обязан создавать из больших пакетов последовательность мелких, а получатель в свою очередь должен склеивать их по мере поступления.

QOS – позволяет гарантировать, что ширина полосы и временные задержки для важного трафика не достигнут критических пределов.

Перейдем к протоколам верхнего уровня. Думаю, с TCP/IP все ясно. Протокол HID реализует взаимодействие с устройствами Human Interface Design. К устройствам такого типа принадлежат модификации клавиатур, мышей и прочего оборудования, с которым напрямую взаимодействуюет человек. RFCOMM эмулирует соединение точка-точка через интерфейс стандартного последовательного COM-порта, передавая данные поверх L2CAP. Следующим интересным для нас протоколом является SDP (Service Discovery Protocol). В его обязанности входит выполнение следующих действий:

- поиск и выбор сервисов, предоставляемых другими устройствами по специальным критериям;

- поиск сервисов по классам. К примеру, если нам нужно найти устройство, предоставляющее сервис Dial-up networking, то поиск должен вернуть нам имена только тех устройств, внутри которых есть модем;

- поддержка базы данных доступных служб в актуальном состоянии.

Еще одним объектом, заслуживающим нашего внимания, является HCI (Host Controller Interface). Он представляет собой командный интерфейс к контроллеру baseband и слою, реализующему Link Manager. С его помощью можно узнавать и изменять состояние контрольных регистров bluetooth- устройств.

Закончив с протоколами верхнего уровня, хотелось бы поговорить о службе audio, часто называемой Bluetooth voice. С ее помощью могут одновременно передаваться три голосовых потока. Характеристики каждого из них определяются приложением, передающим данные. Максимальное возможное качество звука достигается при частоте дискретизации в 48 кГц. На схеме от компонента audio не зря исходят две стрелки. Дело в том, что звук может передаваться либо напрямую через Baseband, либо, как и все остальные данные, через L2CAP. Конечно, в случае передачи голоса через L2CAP устройство получает меньше возможностей управлять голосовым трафиком, но такой подход позволяет легко стыковать Bluetooth- и не Bluetooth-сети. Плюс ко всему появляется возможность шифровать голосовой трафик алгоритмами повышенной стойкости.

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

Security mode 1 (non secure) – устройство не инициирует никаких защитных процедур и полностью открыто для общения.

Security mode 2 (service level enforced security) – защитные процедуры выполняются только после установления и настройки параметров соединения. Требования безопасности в данном случае определяют службы, передающие трафик.

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.

Тут нужно сделать маленькое отступление. Дело в том, на свете существует несколько реализаций стека протоколов bluetooth. Самые распространенные из них – это OpenBT, первоначально созданный фирмой Axis, и Bluez – детище Qualcom. Оба поставляются вместе с исходниками. Некоторое время назад безусловным лидером являлся OpenBT, потому что его реализация на тот момент была надежнее и проще. Да и возможности работы с BCSP были весьма мощные. Но по мере дозревания Bluez стал догонять, а затем и превзошел OpenBT по всем показателям. Отдельного упоминания стоит удобство и гибкость использования PAN (Personal Area Network). К тому же Bluez позволяет легко работать с протоколом OBEX поверх RFCOMM. В деле популяризации Bluez не последнюю роль сыграл тот факт, что он по умолчанию включен во все новые ядра Linux. К тому же алгоритмы работы с RFCOMM у Bluez оказались написаны на редкость удачно, что позволило создавать весьма гибкие решения.

Также стоит упомянуть, что в природе существуют программные комплексы BlueDrekar от IBM и Affix от Nokia. Внутри первого из них встроена полноценная реализация 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. Давайте посмотрим, как выглядит содержимое этого файла, и разберемся, что именно означает каждая опция:

Открывается блок опсиания опций:

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). Значит оставляем поле закоментированным.

Разрешение на сканирование устройств методами 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:
"" (0x111e)
Version: 0x0100

Service Name: Dial-up networking
Service RecHandle: 0x10027
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100


Думаю, что для выхода в Интернет нам лучше всего использовать сервис под названием «Dialup Networking», привязанный к каналу номер 1 (Channel: 1). Для того чтобы воспользоваться интересующим сервисом, нужно связать его с устройством rfcomm.

Проверим, есть ли у нас в системе столь необходимые устройства:

# ll /dev/rfcomm*

lrwxrwxrwx 1 root root 6 Aug 4 09:29 /dev/rfcomm0 -> ttyUB0
lrwxrwxrwx 1 root root 6 Aug 4 09:29 /dev/rfcomm1 -> ttyUB1
lrwxrwxrwx 1 root root 6 Aug 4 09:29 /dev/rfcomm2 -> ttyUB2


Для того чтобы получить возможность работать с устройством rfcomm, как с обычным COM-портом, нужно привязать его к каналу, через который доступен интересный для нас сервис. Как уже упоминалось выше, Dial-up Networking в телефоне Nokia 6310i закреплен за первым каналом. В устройствах от других производителей могут использоваться номера каналов, отличающиеся от приведенных в этой статье.

Привязать канал к rfcomm можно либо на постоянной основе с помощью команды bind, либо на один раз с помощью команды connect. В первом случае привязка сохранится вне зависимости от того, сколько раз мы соединялись с устройством, а во втором после окончания соединения привязка будет разорвана. Привожу оба варианта:

# rfcomm bind rfcomm0 00:02:EE:B6:6A:E5 1
# rfcomm connect rfcomm0 00:02:EE:B6:6A:E5 1


После выполнения любой из этих команд нужно проверить, правильно ли все работает. Делается это с помощью вызова следующей команды:

# rfcomm show
rfcomm0: 00:02:EE:B6:6A:E5 channel 1 clean


Самые нетерпеливые могут присоединиться к устройству /dev/rfcomm0 программой minicom и управлять модемом с помощью стандартных AT-команд. Я же предпочитаю пойти другим путем. Для дозвона к провайдеру у меня используется программа kppp, интерфейс которой можно увидеть на рис. 5. Впрочем, все желающие могут использовать стандартный pppd. Это всего лишь дело вкуса, потому что kppp все равно запускает pppd.



Рис. 5.

Далее все просто. Получаем данные от нашего оператора (телефон дозвона, логин и пароль, возможно, статические IP-адреса. Заносим все эти данные в вашу любимую звонилку. Если все настроено правильно, то при попытке дозвониться на дисплее телефона должен появиться следующий запрос на разрешение установления соединения.

Согласившись, вводим PIN-код, который в дальнейшем будет использоваться для авторизации соединения с устройством tigroid.

На экране компьютера появится аналогичный запрос на ввод PIN-кода.

Стоит отметить, что принятием кода занимается программа pin_helper, о которой мы говорили ранее. К сожалению, не во всех дистрибутивах она работает гладко. Если у вас дело обстоит именно так, то можно написать свой собственный pin_helper примерно такого содержания:

#!/bin/sh
echo "PIN:12345"


Даем ему исполняемые атрибуты и вписываем название в /etc/bluetooth/hcid.conf. Проблем – как не бывало. В случае, если оба устройства опознают друг друга с помощью одинакового PIN-кода, происходит соединение в пару.

Иначе получаем уведомление об ошибке.

Если все прошло хорошо, то телефон начнет набирать номер провайдера и попытается с ним соединиться. Кстати, стоит сказать, что подобную процедуру ручной авторизации необходимо выполнить всего один раз. После этого в файле /etc/bluetooth/link_key появится ключ соединения, а телефон внесет компьютер по имени tigroid в список парных устройств. Впредь авторизация будет происходить автоматически, не требуя нашего вмешательства.

Во время работы я столкнулся с такой проблемой. Несмотря на то что телефон признал в компьютере свою пару, подключение не срабатывало. В этом случае рекомендуется разрушить парность устройств, воспользоваться меню, изображенными на следующих снимках. Затем, удалив файл /etc/bluetooth/link_key, заново пройти процедуру авторизации.

Опробовав полученное соединение, вновь возвращаемся к настройке системы.

Мы запускали всех демонов и привязывали устройства вручную. Конечно, для настройки и отладки это вполне подходит, но в реальной системе хотелось бы иметь немного больше удобства. В этом нам поможет сервис Bluetooth. Для того чтобы автоматически привязывать нужный канал к устройству rfcomm, вносим в файл /etc/rfcomm.conf следующие строчки:

rfcomm0 {

Далее укажем, нужно ли выполнять автоматическую привязку:

bind yes;

Адрес удаленного устройства:

device 00:02:EE:B6:6A:E5;

Номер канала:

channel 1;

Описание соединения:

comment "Dial-up Networking";

}


После этого стоит всего лишь выполнить команды:

# service bluetooth stop
# service bluetooth start


И все нужные устройства будут подключены автоматически.

В принципе система работает, но при каждом запуске сервиса bluetooth на экране появляются ошибки:

# service bluetooth start

which: no hid2hci in (/sbin:/bin:/usr/sbin:/usr/bin)

Starting Bluetooth subsystem:
Starting hcid service: [ DONE ]
Starting sdpd service: [ DONE ]
Starting hidd service: Can't open HIDP control socket: Invalid argument [FAILED]
Starting rfcomm service: [ DONE ]


Дело в том, что в моей системе нет Bluetooth-мышей, клавиатур и прочих HID-устройств, но скрипт упорно настаивает на необходимости работать с ними. И это несмотря на то, что HID отключен установкой переменных в значение false.

HIDD_ENABLE=false
HID2HCI_ENABLE=false


Видимо, придется немного подчистить мелкие недочеты автора скрипта /etc/init.d/bluetooth.

Все проблемы возникают оттого, что скрипт пытается искать местонахождение программ раньше, чем станет известно, нужны ли они пользователю. Для исправления ошибок находим следующие строки и либо удаляем их, либо комментируем:

HCID_EXEC="`which $HCID_NAME || true`"
SDPD_EXEC="`which $SDPD_NAME || true`"
HIDD_EXEC="`which $HIDD_NAME || true`"
HID2HCI_EXEC="`which $HID2HCI_NAME || true`"
RFCOMM_EXEC="`which $RFCOMM_NAME || true`"
PAND_EXEC="`which $PAND_NAME || true`"DUND_EXEC="`which $DUND_NAME || true`"


Затем ищем блок строк, отвечающий за включение сервисов:

HCID_ENABLE=true
SDPD_ENABLE=true

HIDD_ENABLE=false
HID2HCI_ENABLE=false

RFCOMM_ENABLE=true
DUND_ENABLE=false

PAND_ENABLE=false


И после него вставляем вот такую конструкцию:

if $HCID_ENABLE ; then
HCID_EXEC="`which $HCID_NAME || true`"

fi

if $SDPD_ENABLE ; then
SDPD_EXEC="`which $SDPD_NAME || true`"

fi

if $HIDD_ENABLE ; then
HIDD_EXEC="`which $HIDD_NAME || true`"

fi

if $HID2HCI_ENABLE ; then
HID2HCI_EXEC="`which $HID2HCI_NAME || true`"

fi

if $RFCOMM_ENABLE ; then
RFCOMM_EXEC="`which $RFCOMM_NAME || true`"

fi

if $DUND_ENABLE ; then
PAND_EXEC="`which $PAND_NAME || true`"

fi

if $PAND_ENABLE ; then
DUND_EXEC="`which $DUND_NAME || true`"

fi


После этого проблемы должны исчезнуть.



Андрей Бешков
обсудить статью
© сетевые решения
.
.