[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bluetooth и getty



Hi Victor,

* Victor Wagner <vitus@wagner.pp.ru>
* 2007-12-04 18:38:
> А вот как был поднять getty на /dev/rfcommX?
> 
> Т.е идея такая - организовать что-то типа dun, только присоединившееся
> устройство получает не ppp-сессию, а login prompt и консольную сесию в
> случае успешной авторизации. 
> 
> Мануал по dund читал, там ничего интересоного не написано.
> В мануале по rfcomm(1) описана опция --listen,  но что произойдет,
> когда клиент таки придет, и куда лошадь (то есть getty) запрягать,  не
> написано.

Не хочу обманывать, но вроде как rfcomm должен связать bluetooth
сервис/порт с TTY /dev/rfcomm?
Потом в FAQ написано, что можно работать как с рядовым
устройством например minicom-ом. Только время открытия порта
сравнительно большое. Чтобы вторая сторона "увидела" этот порт надо
объявить его с sdptool.

Мне надо было написать обертку под win32, общую для COM и bluetooth
(свой протокол для автодел, в машине одноплатка с Linux). MS bluetooth слой
(часто со всякими недорогими USB девайсами идет что-то стороннее) видела порты,
и я даже пробовал HyperTerminal-ом подключаться, но дело не выгорело - оно
все время спрашивало пароль (был он на стороне bluez или нет) и в итоге
никуда не пускало. Кто был виноват я так и не разобрался - написал все в
итоге через сокеты. Тоже не сахар, но google помог, благо win32 часть
oграничена WinXP SP2 и Windows Mobile 5. На стороне Linux никаких
сюрпризов, все есть в примерах.

Были еще одни грабли - с какой-то версии bluez видимо по соображениям
безопасности через 30 если не ошибаюсь секунд отключается не то inquery
scan не то page scan. Получается, если знаешь адрес удаленного
устройства, то другая сторон может найти порт для запрашиваемого
сервиса. Но обнаружить само устройство не зная адреса уже нельзя.
По-этому приходилось вскючать это дело hciconfig-ом.

Извиняюсь, что все так неточно и с постоянным "вроде" - времени было в
обрез, и читать теорию было некогда.


-- 
Best regards,
Sergey Chumakov 2:450/77[.43]



Reply to: