![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerПодарил тут жене на новый год новый нетбук, поставил на него 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-ным процессом и демоном, необходимое до момента, когда соединение установлено, реализовывать каким-то другим способом.
Пришлось разбираться с поддержкой 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-ным процессом и демоном, необходимое до момента, когда соединение установлено, реализовывать каким-то другим способом.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-01-04 12:38 pm (UTC)Правда, я сейчас посмотрел на sourceforge и обнаружил, что captnmark оживился. Может быть, я зря списываю icewm.
no subject
Date: 2011-01-04 10:43 am (UTC)no subject
Date: 2011-01-04 11:18 am (UTC)Что касается Wicd, wifi-radar и тем более, упаси боже, NM, то сам не пользуюсь и другим не советую.
Тут скорее логично иметь апплет в трее или где еще на экране, который бы этим управлял. В GNOME, кстати, так и сделано. Правда, возможности подключиться к блютусной Network Access Point, я там не видел. Видимо, из рассчета такого апплета и сделан разрыв соединения при завершении процесса. Просто не подумали, что бывают сценарии работы отличные от "юзер завершил сессию, значит питание компьютера можно выключить".
Не собачье дело "программулины, которой нужна сеть", поднимать эту самую сеть. Тем более если речь идет о PAN, который, как правило, используется для присоединения к сотовому телефону - там сеть ДОРОГАЯ. Поэтому только с явного согласия пользователя.
То есть программулина, которая управляет включением/выключением сети - это специализированная программулина, которая управляет именно этим (ну может еще парой-тройкой других функций).
no subject
Date: 2011-01-04 11:31 am (UTC)no subject
Date: 2011-01-04 11:52 am (UTC)Если у нас стоит задача отслеживания что соединением никто не пользуется, то надо ровно это и отслеживать. Через libpcap например.
А вот идея reference counter-а на ifup/ifdown - она интересная. С одной стороны она много проще, чем работа через libpcap. С другой стороны, она позволяет легко отсечь генераторы паразитного траффика вроде ntpd. Считается только то, что пользователь счел необходимым завернуть в скрипты, работающие со счетчиком ссылок.
И на мой взгляд, явные Connect/Disconnect без имплицитного дисконнекта по завершению процесса, сказавшего connect - куда как правильнее. Тогда можно было бы из скриптов connect черед dbus-send говорить. А долгоживущие программы бы как-нибудь ловили собственное завершение и говорили Disconnect явным образом.
no subject
Date: 2011-01-04 12:56 pm (UTC)no subject
Date: 2011-01-04 01:06 pm (UTC)Но только при условии, что у тебя телефон не умеет Wi-Fi ;-)
Одно из основных применений синезуба у меня - это выход в интернет через телефон, с симкой, которая вообще-то предназначена для голосовых звонков. То есть выход явно нештатный. Для штатного выхода лучше 3G или WiMax-свисток покупать.
Второе применение - беспроводной выход на наушники. Наличие "свистка" при этом практически обесценивает беспроводность.
no subject
Date: 2011-01-04 01:08 pm (UTC)no subject
Date: 2011-01-04 01:27 pm (UTC)Во-вторых, дальность действия у таких дивайсов явно меньше, чем у полноразмерных.
А дальность действия беспроводной связи меньше размеров квартиры это как-то неудобно.
no subject
Date: 2011-01-04 02:02 pm (UTC)no subject
Date: 2011-01-04 02:17 pm (UTC)А наличие отдельной тулзы, умеющей говорить connect/disconnect сетевому интерфейсу (для каковой тулзы и нужен вызов коннект не прерывающийся по завершению тулзы) сделает ошибку автора долгоживущей программы безопасной (легко исправимой) для пользователя.
no subject
Date: 2011-01-04 11:42 am (UTC)no subject
Date: 2011-01-04 11:46 am (UTC)no subject
Date: 2011-01-06 04:24 pm (UTC)к слову - на роутере вполне может оказаться, что свопиться некуда.
no subject
Date: 2011-01-07 11:34 am (UTC)no subject
Date: 2011-01-07 11:38 am (UTC)no subject
Date: 2011-01-07 11:57 am (UTC)no subject
Date: 2011-01-04 04:49 pm (UTC)По-моему, создатели bluez userspace просто юродивые. Мне надо срочно взять себя в руки, и портировать affix userspace на современный bluetooth.
no subject
Date: 2011-01-05 08:22 am (UTC)У меня есть представление что вообще-то нужно не портировать что-то, а писать с нуля, как следует проработав ТЗ на верхних уровнях абстракции, начиная с user story. Писать-то там в общем не шибко много. Всю ядерную часть, включая alsa, например, можно и так оставить.
no subject
Date: 2011-01-05 02:40 pm (UTC)no subject
Date: 2011-01-05 03:38 pm (UTC)Хиловатенько там. Только DUN да PAN. Ну HID еще немножко. Никаких usage scenario для RFCOMM кроме DUN не описано. Про HSP и A2DP вообще ни слова.
no subject
Date: 2011-01-05 03:40 pm (UTC)no subject
Date: 2011-01-05 03:44 pm (UTC)no subject
Date: 2011-01-05 05:09 pm (UTC)no subject
Date: 2011-01-05 06:32 pm (UTC)А сейчас это самое важнейшее "из искусств".
А затем что я как-то попробовал юзать rfcomm для самого обычного логина в систему посредтсвом cu в качестве эмулятора терминала. Получилось довольно криво. В смысле на том конце, где надо запускать login.
Вот как раз с исходящими у bluez никаких проблем - а со входящими траблы. А в Linux серверный конец протокола должен, на мой взгляд, всегда работать не хуже, чем клиентский.
Исходящий коннект к блютусному GPS-приемнику, например, работает. А как насчет того, чтобы раздать подключенный к linux-машине (или встроенный в нее) gps через gpsd наружу?
Date: 2011-02-01 09:35 am (UTC)