Журнал Витуса

В документации на гарнитуру Motorola S305 утверждается что она поддерживает multipoint connection. То есть её можно спарить с двумя устройствами одновременно и она будет работать с обоими сразу - например с одного принимать музыку по A2DP, а со второго - звонки по HSP.

Попробовал точно по инструкции спарить её одновременно с Nokia N900 и Asus Transformer 300.
Не получается. Либо с тем, либо с другим.

Что я делаю не так? Может проблема в том, что оба устройства поддерживают HSP? И если да, то может в Android 4.0 его можно выключить (благо устройство телефоном не является)?

Подарил тут жене на новый год новый нетбук, поставил на него sqeeze.
Пришлось разбираться с поддержкой bluetooth в этом дистрибутиве.

Мне и раньше пару раз сообщали что моя программка btpasskey не работает с Bluez 4.x.
Я отмахивался, говоря, что вот появится у меня где-нибудь машина с Bluez 4.x, тогда и займусь.

Ну вот этот момент настал.

Обнаружилось что в очердном major release они опять сделали до основания а затем. Вместо кучи мелких pand hcid sdpd, появился один огромный bluetoothd. И все что раньше делалось запуском этих мелких демонов с параметрами предполагается делать через dbus api этого bluetoothd. Правда, серверную часть DUN и PAN они, естественно, забыли. Поэтому в Debian остался пакет bluez-compat, содержащий dund и pand.

Зато клиентская часть PAN реализуется легко. Никаких sudo не надо. Просто дернул метод Connect и все работает. Секьюрити на уровне Windows95. Правда, скрипт, прописанный в /etc/bluetooth/network.conf не вызывается. Но это и не страшно. Если в /etc/network/interfaces написано allow-hotplug bnep0 - само поднимется.

Но вот за идею что при завершении процесса, позвавшего функцию Connect (вернее при отключении его от системной шины dbus) сетевое соединение прерывается, хочется дизайнерам этого API оторвать яйца.

Из положительных черт - стали класть в examples набор питоновских скриптов, куда более осмысленных чем то, что там лежало в предыдущих версиях. В частности есть скрипт test-network которым PAN-соединения можно поднимать, и он почти достаточен для моих целей, если бы не идиотская система что ему нужно висеть запущенным все время, пока пользователь пользуется сетью,
и скрипт simple-agent который почти реализует ту функциональность ради которой я писал btpasskey.

Почти - потому что его писал человек, не имеющий ни малейшего представления о правилах хорошего тона при написании юниксовых утилит. Чуть-чуть поправить на предмет буферизации stdout и кодов завершения, и можно пользоваться.

С переписыванием test-network будет сложнее. Там нужно аккуратно разбираться с демонизацией и взаимодействием демонизации с dbus. Видимо проще всего коннектиться к dbus уже после fork, а общение между forground-ным процессом и демоном, необходимое до момента, когда соединение установлено, реализовывать каким-то другим способом.

По примеру tobotras. Так долго тормозил потому, что нужно было дождаться, пока выйдет версия gammu, которая поддерживает Nokia 3109c.

В чем отличия моего сетапа от тоботрасовского:
1. Я точно знаю, что rfcomm bind для работы gammu не нужен, и точно знаю куда класть PIN
2. Телефонов бэкапится пока два (мой и жены), но если вдруг в доме появятся еще, то прописать их тоже должно быть легко. Мне очень не понравилось то, что в варианте Бориса BT-адрес телефона должен быть записан в два места - в сам скрипт и в ~/.gammurc.
3. Bluetooth на телефонах обычно включен, а вот discoverability - хрен. Поэтому использовать для обнаружения телефона hcitool, как это делает Борис - нельзя.
4. Историю изменений записной книжки хочется хранить, используя для этого минимум места. Поэтому сбэкапленная база чекинится в RCS.
\
Поэтому я написал скрипт, который читает .gammurc, и проверяет наличие телефона, адрес которого там указан, посредством sdptool search DUN. Честно сказать, не пытался разбираться, какой именно профайл использует gammu (возможно - разный для разных типов соединения), но уж DUN-то на телефоне всяко есть.

Из-за необходимости парсить .gammurc скрипт написан на perl, а не на shell.

( Текст скрипта )

Пользоваться этим так:
1. Настраиваем в .gammurc отдельную секцию c именем [gammuN] для каждого телефона
2. Запускаем какую-нибудь утилиту для ввода PIN (мой btpasskey или какой-нибудь bluez-gnome) и тестируем конфиг запуском gammu вручную. Заодно и pin запишется куда надо.
3. Запускаем скрипт вручную в первый раз. При первом чекине в RCS оно потребует ввести message со stdin.
Можно даже и ввести что-нибудь осмысленное. При последующих чекинах (при существующем файле ,v) вопросов уже не будет, опция -m в скрипт забита.
4. Прописываем скрипт в crontab, например каждые 15 минут.

Сегондя наконец собрался и выложил то, что за отпуск написал на тему btcli. В общем-то - крайне мало. Только новая версия btpasskey.

Но зато завел для btcli CVS-репозиторий для btcli.

Новая версия btpasskey умеет следующее:
1. Для компиляции не нужна libbluetooth - все делается черед D-Bus API hcid
2. Оно умеет на время своей работы включить адаптер в discoverable mode
3. Оно умеет инициировать процесс pairing с указанными устройством (правда, только по адресу. Библиотеку для резолвинга имен в адреса пока не написал)
4. Оно умеет удалять бондинг с указанным устройством. Что бывает полезно, потому что некоторые устройства не могут нормально провести процесс спаривания, если они когда-то были спарены с данным компьютером, а потом спарены с другим и в результате забыли ключ. А компьютер его помнит.
Upd: Народ, посоветуйте, а как себя должен вести btpasskey -d если в момент его запуска ни одного bluetooth адаптера не обнаружено
1. Внятно ругаться и завершаться.
2. Внятно ругаться и работать так же как без -d (то есть ждать запроса на ввод passkey не пытаясь переключать режимы адаптера
3. Ловить сигнал DefaultAdapterChanged, и по появлении адаптера переключать его в режим discoverable.

Еще один скрипт из комплекта bluetooth-cli. Обертка вокруг pand, которая обррабатывает типичные ситуации
Использование:
bluenet on
найти первую активную точку доступа с профайлом NAP из перечисленных в /etc/bluetooth/NAP (в порядке перечисления) и присоединиться
bluenet off
отсоединиться
bluenet address профиль
Где профиль NAP (по умолчанию) или GN - присоединться к указанной точке доступа
bluenet master профиль
Изобразить из себя точку доступа (если профиль NAP) или мастера ad-hoc сети (если профиль GN).

( Собственно скрипт )

( Вспомогательные скрипты, вызываемые pand при поднятии интерфейса )
Не хватает еще скрипта, который добавляет hostname приконнектившихся машин в файл, из которого резолвит имена dnsmasq.
Но вообще, если в режиме клиента я этим скриптом пользуюсь уже давно, и для коннекта к телефону, и для коннекта к компьютеру
(в /etc/bluetooth/NAP у меня две строчки - адрес домашнего компьютера, и адрес моего телефона - именно в такой последовательности), то режим сервера я активно не тестировал. Последнее время ad-hoc сети чаще делаются по Wi-Fi, чем по bluetooth.

В процессе изысканий по проекту BlueTooth CLI написал в виде шелловского скрипта утилиту, которой мне крайне не хватало в etch и lenny - командно строчный скрипт, который позволяет посмотреть и установить статус bluetooth адаптера (в смысле, connectable он, discoverable или что). А то новые версии bluez стартуют адаптер в non-discoverable mode, и включить discoverability можно только через гномовский апплет.
Оказывается, dbus-send для этого вполне достаточно

( страшный shell с регекспами )

Тут в предыдущем треде была поднята тема форка bluez-utils. Подумавши немного, я пришел к выводу, что тут нужен не форк, вернее не совсем форк. Существующие bluez-utils это фактически отладочные инструменты для проверки работоспособности bluetooth-стека и libbluetooth. Поэтому понятно что для работы они не приспособлены.

Хотя надо сказать, во времена оны делали по другому. Возьмем, к примеру стэк TCP/IP. На протяжении десятилетий для отладки tcp/ip протоколов пользовались telnet - программой, которая вообще-то предназначена для РАБОТЫ с одним из протоколов, но заодно и обладает отладочными возможностями - просто передавать ввод-вывод на указанный TCP/IP сервер. И только много позже появился netcat. Который вообще-то тоже не для отладки предназначен, а для скриптования.

Разработчики bluez не шмогли разработать такой набор утилит, который был бы удобен и для отладки, и для работы. Ну да хрен бы с ними. Надо просто разработать более другой набор утилит, предназначеный для реализации типичных сценариев работы пользователя с bluetooth-подсистемой и заточенный для использования из скриптов, так чтобы можно было легко и удобно реализовывать нетипичные сценарии. libbluetooh, hcid и bluetooth-подсистему в ядре по умолчанию считаем спроектированными правильно, и пригодными к употреблению. Ежели в процессе работы выяснится что это не так, тогда и будем думать как править.

Кстати, не исключено что надо сразу зарекаться на работоспособность утилит с более другими стэками bluetooth, например FreeBSD-шным. Там местами сделано более правильно.

Рассмотрев те сценариии использования bluetooth, которые приходилось использовать мне я пришел к выводу, что нужны следующие инструменты:

( Подробности технические )

Это то, что мне придумалось исходя из моего опыта использования различных bluetooth-устройств. Всякие прочие user stories, предложения и дополнения приветсвуются

Я таки собрался сделать из passkey-agent.c из examples к bluez нечто с более-менее вменяемым интерфейсом. Чтобы сначала рассказывала что за устройство pairing запрашивает (причем не только адрес, но и имя), а потом просила ввести PIN. Естественно, вписать туда setvbuf(stdout,NULL,_IONBF,0) и то же самое для stdin не забыл. А то многие о таких вещах забывают и через пару пайпов с их программой не поработаешь.

Что характерно, родные примеры на питоне на http://wiki.bluez.org имя устройства показывать не умеют. А моё - умеет. Правда, имя оно запрашивает не через DBUS, а через libbluetooth на низком уровне. Потому что это проще.
А если человеку нужен bluetooth passkey agent, то libbluetooth в системе заведомо есть.

Теперь можно писать passkey-агенты на любых скриптовых языках, независимо от наличия биндинга к D-BUS. Ибо аналоги popen и управление буферизацией есть везде.

Теперь бы еще с obexpushd разобраться. А то он только в версии 0.6 научился отдавать скрипту адрес устройства, откуда прислали файл. (а про имя в changelog ни слова). А в etch версия 0.4.

Да, если кто еще не знает, где берут мои debian-овские пакеты:

deb http://ftp.wagner.pp.ru/pub/debian-cosy etch local updates tcl

http://www.sotovik.ru/news/news_29127.html
http://www.minsvyaz.ru/ministry/170/174/3005.shtml

Российские власти резко усложнили процедуру сертификации Bluetooth-устройств для ввозва в Россию. Утверждается что процедура такова, что сертификация конкретной модели будет занимать примерно полгода, а у многих производителей за это время модельный ряд успевает смениться.

Причем никакого разумного основания с точки зрения ГБ-шной паранойи для запрета устройств радиусом действия в десятки метров - нет.

Единственная причинно-следственная связь, которая приходит в голову - недавние изменения в ПДД, которые запретили разговор по мобильному телефону за рулем без использования гарнитуры. Это, естественно, вызвало бум на рынке Bluetooth-гарнитур, и чиновникам хочется урвать свой кусочек.

Интересно, распростнаяется эти новые правила на Wi-Fi или нет?
Если да, то перспективы использования Wi-Fi mesh networking в качестве альтернативы интернету, который, увы, слишком легко контролировать, становятся печальными.

Эти перспективы были бы радужными в том случае, если бы у каждого второго жителя крупных городов и в каждом первом офисе было бы какое-нибудь Wi-Fi оборудование, и пытаться что-то там запрещать было бы эквивалентно запрету собираться на улицах по-трое.

Продолжаю потихоньку хакать obexsync, бывший t68tool. Пора бы уже выкладывать, так как по сравнению с t68tool 0.4 есть заметный прогресс - поддерживаются русские (и прочие не Latin-1) имена файлов. Из всех прочих командно-строчных инструментов, виденных мной, на такое заморачивается только BSD-шный obexapp. Остальные ничтоже сумняшеся зовут OBEX_CharToUnicode из libopenobex, которая, ну вы понимаете, попросту вставляет перед каждым байтом 0.

Но хочется ещё в довершение блока работы с перекодировками сделать нормализацию скачиваемых телефонных книжек и календарей. Дело в том, что как было выяснено экспериментальным путем, каждый телефон кодирует VCARD-ы кто во что горазд. Ericsson (ещё с до-Sony-евских времен, с R520) любит UTF-7, попадались также Quoted-printable-encoded Windows-1251 и даже iso8859-5.

В то же время, столь же экспериментально выяснено, что все эти телефоны прекрасно понимают если им передать ENCODING=8BIT;CHARSET=UTF-8. А если хранить записную книжку на компьютере именно в таком виде, то её удобно просматривать текстовым редактором. Опять же, у меня уже есть, и должна войти в комплект утилита поиска по записной книжке (в том числе и умеющая работать query_command в mutt). Она как раз рассчитана на 8bit и utf-8. Поэтому книжку надо нормализовать. Раньше этим занималась внешняя скриптовая обвязка. Но с появлением в 0.4 Bluetooth name resolution она как-то лишняя стала.

Зато всплыла засада с OBEX File Transfer Profile. Почему-то при работе obexftp телефон (один раз за сессию) спрашивает "а правда, что вы хотите дать этому устройству (компьютеру) доступ к вашим данным", а при коннекте t68tool - сразу посылает как unauthorized. Долго смотрел в исходники, так и не понял. Запрос GET формируется совершенно одинаково, значит разница только в CONNECT. Исходный автор t68tool зачем-то пихает туда OBEX_HDR_WHO со значением Linux, но его удаление почти ничего не меняет. А в obexftp туда пихают OBEX_HDR_TARGET с каким-то UUID в качестве значения. В блютусовских спецификациях описания этого UUID не нашел, надо в IrMC-шных искать. Но добавление UUID тоже не помогает, похоже там где-то есть еще какой-то промежуточный обмен сообщениями. Надо бы найти описание, может можно сделать так, чтобы телефон глупых вопросов не задавал. А то впихнуть всю транзакцию в один вызов командно-строчной утилиты вряд ли получится.

Еще выяснилось что почему-то для IrMC надо делать GET с полным путем (telecom/pb.vcf), а для FTP - сначала SETPATH в нужное место, а потом GET без пути - иначе не работает. Ну эту логику я как раз уже впихнул. Правда, опять же спецификации читать надо - это заморочка конкретного телефона или общий принцип. Если первое, то надо эту фичу делать отключаемой, и позволять каким-то образом делать GET по полному пути без SETPATH.