![[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-ным процессом и демоном, необходимое до момента, когда соединение установлено, реализовывать каким-то другим способом.
