 |
|
|
|
Bluetooth + Linux, или Синий зуб на службе cистемного администратора
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. Купленное устройство выглядело изящно, миниатюрно и весило примерно грамм 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 частот. Обнаружение активных устройств зависит от того, в каком режиме они находятся:
На самом деле все обстоит еще сложнее. Вдобавок для того, чтобы присоединение к сети состоялось, устройство должно работать в режиме 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, на которые стоит обратить внимание:
Перейдем к протоколам верхнего уровня. Думаю, с TCP/IP все ясно. Протокол HID реализует взаимодействие с устройствами Human Interface Design. К устройствам такого типа принадлежат модификации клавиатур, мышей и прочего оборудования, с которым напрямую взаимодействуюет человек. RFCOMM эмулирует соединение точка-точка через интерфейс стандартного последовательного COM-порта, передавая данные поверх L2CAP. Следующим интересным для нас протоколом является SDP (Service Discovery Protocol). В его обязанности входит выполнение следующих действий:
Еще одним объектом, заслуживающим нашего внимания является HCI (Host Controller Interface). Он представляет собой командный интерфейс к контроллеру baseband и слою, реализующему Link Manager. С его помощью можно узнавать и изменять состояние контрольных регистров bluetooth-устройств. Закончив с протоколами верхнего уровня, хотелось бы поговорить о службе audio, часто называемой bluetooth voice. С ее помощью могут одновременно передаваться три голосовых потока. Характеристики каждого из них определяются приложением, передающим данные. Максимальное возможное качество звука достигается при частоте дискретизации в 48 кГц. На схеме от компонента audio не зря исходят две стрелки. Дело в том, что звук может передаваться либо напрямую через Baseband, либо, как и все остальные данные, через L2CAP. Конечно, в случае передачи голоса через L2CAP устройство получает меньше возможностей управлять голосовым трафиком, но такой подход позволяет легко стыковать bluetooth- и не bluetooth-сети. Плюс ко всему появляется возможность шифровать голосовой трафик алгоритмами повышенной стойкости. Раз уж зашел разговор о шифровании, стоит поговорить о системе безопасности, применяемой в устройствах bluetooth. Технология защиты данных изначально встроена в протокол. В зависимости от ценности передаваемых данных можно применять один из трех режимов безопасности.
Стоит обратить внимание на то, что второй и третий режимы можно комбинировать, обеспечивая повышенную безопасность соединения. Получается, что сначала устанавливается защищенное соединение, а затем данные, передаваемые по нему, шифруются в соответствии с требованиями сервисов отправителя и получателя. Краеугольным камнем системы безопасности bluetooth является сеансный ключ. Он создается в момент соединения и впоследствии используется для шифрования и идентификации всего передаваемого трафика. Впрочем, никто не мешает дополнительно шифровать трафик на уровне приложений. Несмотря на попытку рассказывать только о ключевых моментах, оставляя несущественные подробности за бортом, я, признаться, немного устал излагать теорию работы bluetooth. Посему предлагаю сейчас же перейти к практическому применению полученных знаний. Bluetooth + Linux на практике Чтобы система смогла увидеть наше usb bluetooth-устройство, первым делом убеждаемся, что мы работаем на достаточно свежем ядре. У меня используется ALT Linux, версия ядра 2.4.26-std-up-alt6. Давайте посмотрим, какой тип контроллера USB у нас установлен. # lspci
Судя по выводу, у нас есть UHCI- и EHCI-контроллеры USB. Проверяем, что написано про USB в /etc/modules, среди всего прочего там должны быть строки: usbcore usb-uhci А в файле /etc/modules.conf нужно найти следующее сочетание символов: alias usb-interface usb-uhci Теперь необходимо убедиться в том, что все модули, необходимые для поддержки USB, загружены в память. # lsmod | grep usb
Если это не так, то следует перезагрузить систему, чтобы загрузка нужных модулей прошла автоматически на основе содержимого файлов /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:
Перезагружаем машину, чтобы проверить, как автоматически загружаются модули bluez. Конечно, можно было загрузить их вручную с помощью modprobe и imsmod, но мне больше нравится, чтобы все делалось автоматически. После окончания загрузки системы проверяем, как себя чувствует модуль bluez. # lsmod | grep bluez
Затем вставляем bluetooth-адаптер в разъем USB. В файле /var/log/messages и на двенадцатой консоли должны появиться следующие сообщения:
Стоит отметить, что каждое bluetooth-устройство имеет уникальный шестизначный адрес, в дальнейшем называемый BD (Bluetooth Device)-адрес. Больше все это похоже на MAC-адреса обычных сетевых карт. Проверяем, как система видит наш USB-адаптер. # hciconfig –a
Надпись «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
Судя по выводу, все идет как надо. Локальное bluetooth-устройство получило BD-адрес 00:0A:3A:53:36:41. Давайте теперь поищем удаленные bluetooth-устройства. Для этого включаем bluetooth на телефоне.
Указанием на то, что телефон включил bluetooth, можно считать появление в верхнем левом углу дисплея значка, изображающего радиоволны. С помощью утилиты hcitool начинаем сканирование окружающего пространства. # hcitool scan
Наш телефон благополучно нашелся. Теперь мы знаем, что его BD-адрес 00:02:EE:B6:6A:E5. В дальнейшем мы будем обращаться к нему именно по этому адресу. Проверим, насколько надежно работает передача пакетов между двумя устройствами. Для этого воспользуемся программой l2ping. # l2ping 00:02:EE:B6:6A:E5
Теперь посмотрим дополнительную информацию об удаленном устройстве. # hcitool info 00:02:EE:B6:6A:E5
В комплект программ, предназначенных для работы с HCI, входит еще одна полезная программа, hcidump. Думаю, по ее названию вы смогли догадаться, что перед нами утилита для прослушивания трафика, проходящего через HCI-интерфейсы. Эта программа становится особенно полезной в ситуациях, когда не удается подружить два bluetooth-устройства. К примеру, давайте посмотрим, какие данные проходят через используемый нами интерфейс hci0 во время выполнения команды hcitool info. Для этого на одной консоли запускаем hcidump, а на второй снова выполняем команду hcitool info. # hcidump -i hci0 -X
С помощью ключа –i можно указать, какой именно интерфейс нужно прослушивать. В нашем случае это hci0. Делать это необходимо только в системах с двумя и более hci-интерфейсами. В противном случае hcidump будет прослушивать первый по порядку интерфейс. Как говорил один известный персонаж, «Все ходы у нас записаны». И в случае чего можно будет запросто заняться отладкой неработающего соединения. Теперь было бы интересно узнать, какие сервисы Nokia 6310i может нам предоставить. Для этого на компьютере должен работать sdp-демон, который реализует протокол Service Discovery Protocol. А вслед за ним необходимо запустить утилиту sdptool, получающую данные от демона и показывающую их пользователю. # sdpd # sdptool browse 00:02:EE:B6:6A:E5
Думаю, что для выхода в Интернет нам лучше всего использовать сервис под названием «Dialup Networking», привязанный к каналу номер 1 (Channel: 1). Для того чтобы воспользоваться интересующим сервисом, нужно связать его с устройством rfcomm. Проверим, есть ли у нас в системе столь необходимые устройства: # ll /dev/rfcomm*
Для того чтобы получить возможность работать с устройством 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
Самые нетерпеливые могут присоединиться к устройству /dev/rfcomm0 программой minicom и управлять модемом с помощью стандартных AT-команд. Я же предпочитаю пойти другим путем. Для дозвона к провайдеру будет использоваться программа kppp. Впрочем, все желающие могут использовать стандартный pppd. Это всего лишь дело вкуса, потому что kppp все равно запускает pppd. Запустив kppp, воспользуемся кнопкой «Настроить», затем выбираем вкладку соединения и жмем «Создать –> Ручная настройка». Настраиваем все так, как показано на следующих рисунках.
Завершив настройку соединения, переходим на вкладку «Устройство» и изменяем данные, отображенные на ней, следующим образом.
Выбираем только что созданное соединение, указав имя пользователя и пароль, жмем «Подключиться». Если все настроено правильно, то на дисплее телефона должен появиться следующий запрос:
Согласившись, вводим 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 на экранt появляются ошибки: # service bluetooth start
Дело в том, что в моей системе нет 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 После этого проблемы должны исчезнуть. Думаю, что на этом наш сегодняшний разговор о bluetooth стоит завершить. Дайте мне знать, если вас заинтересовала данная тема. В случае необходимости я напишу продолжение этого материала. В нем будет рассказано о том, как, пользуясь созданным bluetooth-соединением, управлять различными сервисами телефона и отправлять sms. Литература:
|
АНДРЕЙ БЕШКОВ
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
