Компы и автомобили (Posts about Bluetooth)

СМС-оповещения

at-hacker — Fri, 13 Apr 2012 09:12:00 GMT

У нас на фре трудится система мониторинга Zabbix. Обо всяких критических события, типа пропадания питания или неожиданной перезагрузки серверов хотелось бы, чтобы оповещения приходили на СМС заинтересованным лицам. Выкопал я у товарища старый бесхозный мобильник Motorola L6 и вознамерился его использовать. Чтобы не искать кабель, который, как водится, может ещё и не подойти, решил его сразу по bluetooth подключить. Долго курил мануалы, прописывал ключи и включал автоматический доступ на Мотороле с компа, чтобы она не запрашивала каждый раз подверждение. Вроде заработало. Написал скрипт для автоматического запуска rfcomm_sppd, которая создавала виртуальный COM-порт через bluetooth, через который, в свою очередь, комплект smstools отправлял сообщения.

Тока вот этот виртуальный COM-порт, через который работал rfcomm_sppd, постоянно отваливался. И каждый раз требовался танец с бубном, чтобы всё это опять заработало, причём каждый раз я не мог понять, почему такие же действия две минуты назад никакого эффекта не давали. Удалось выяснить, что выключение/включение голубого зуба на телефоне позволяло в течение пары минут запустить скрипт и тогда порт появлялся. Но сегодня не помогло даже это. Руками запускаю rfcomm_sppd с нужными ключами — порт есть. Делаю то же самое скриптом — connection refused. В конце концов меня это задрало.

Я с горя взял обычный провод USB-miniUSB, оставшийся от павшего смертью храбрых внешнего HDD, и подключил им телефон к серваку с FreeBSD. Оценил обстановку в логах. Обстановка гласила:

Apr 13 12:25:11 proxy root: Unknown USB device: vendor 0x22b8 product 0x4902 bus uhub2Apr 13 12:25:11 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2Apr 13 12:32:57 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2 (disconnected)Apr 13 12:33:05 proxy kernel: ugen2.3: <Motorola Inc.> at usbus2Apr 13 12:33:05 proxy root: Unknown USB device: vendor 0x22b8 product 0x4902 bus uhub2

Попандос, думаю — ugen2.3. Это значит, что фря устройство видит, но как с ним работать — не знает, драйвера нет. Полазил по интернетам. Рекомендуют запускать модуль ucom. Ок, пробуем:

kldload ucom

kldload: can't load ucom: No such file or directory

Нету модуля, значит. Та же петрушка с рекомендованным модулем umodem. Лезем сначала в /usr/src/sys/modules/usb/ucom, и делаем там

make

make install clean

Потом то же самое в каталоге /usr/src/sys/modules/usb/umodem

Потом грузим модули:

kldload ucom

kldload umodem

Перетыкаем кабель в телефоне, палим логи:

Apr 13 12:46:38 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2Apr 13 12:46:38 proxy kernel: umodem0: <Motorola Inc. Motorola Phone (L6), class 2/0, rev 1.10/0.01, addr 2> on usbus2Apr 13 12:46:38 proxy kernel: umodem0: data interface 1, has CM over data, has no breakApr 13 12:46:38 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2 (disconnected)Apr 13 12:46:38 proxy kernel: umodem0: at uhub2, port 1, addr 2 (disconnected)Apr 13 12:48:01 proxy kernel: ugen2.2: <Motorola Inc.> at usbus2Apr 13 12:48:01 proxy kernel: umodem0: <Motorola Communication Interface> on usbus2Apr 13 12:48:01 proxy kernel: umodem0: data interface 1, has CM over data, has no break

Ну круто, umodem нашёл телефон. В системе появился порт /dev/cuaU0 (не путать с COM1, который /dev/cuau0 — разница в регистре в имени). Это и есть искомый COM-порт для коммуникации с телефоном. Прописываем его в конфиге демона smsd из комплекта smstools, и получаем щастье! И никаких хитрых процедур и скриптов запуска по голубому зубу. Остаётся только прописать загрузку этих двух модулей в /boot/loader.conf, чтобы оно автоматом грузилось при старте системы.

Сеть по bluetooth с помощью btpand

at-hacker — Thu, 07 Jan 2010 02:30:00 GMT

В упомянутом уже ThinkPad 600X сетки не было. Точнее, сетевая PCMCIA была, но товарищ не нашёл проводочек, который подключается одним концом к сетевухе, а другим — к коннектору RJ-45. Поскольку CDROM в ноуте старый и довольно глючный, пришлось что-то придумывать. Вариант был ровно один — поскольку USB-порт там один есть, остаётся только Bluetooth, ну, или всякие USB-сетевые, проводные или WiFi. Покупать для этого ноута USB-сетевую меня заломало — не такая уж важная птица, а адаптеров голобуго зуба у меня навалом.

Под фрёй 7.2 я настроил сетку с помощью LAN over PPP, настроил rfcomm_pppd и полетели. Запускалось оно несколько криво — из rc.local, и требовало ещё не менее трёхсекундной паузы для прописывания маршрутизации, но в общем, работало.

После перехода на 8-ую фрю начали наблюдаться проблемы — примерно через час прослушивания интернет-радио голубозубый линк отваливался, и не поднимался до тех пор, пока я не выдерну и не вставлю обратно bluetooth-адаптер на серверной стороне, с последующим перезапуском rfcomm_pppd с обоих сторон. Разбираться с этим бесполезно — никаких сообщений в логах нет, ничего не происходит, сервер по голубому зубу при обзоре устройств виден, и линк поднимается, но трафика по нему не идёт. Я такое уже видел, правда, с КПК, но побороть так и не смог. Решил перейти на btpand, раз уж он появился — это софтина, портированная во фрю из NetBSD (не прошло и 8 лет, как фря наконец-то начала вкуривать BT PAN, ггг).

Потестил btpand при ручном запуске. На сервере запускаем:

ifconfig tap0 create

btpand -d ubt0 -i tap0 -s NAP

ifconfig tap0 192.168.2.1 netmask 255.255.255.0

На клиенте:

ifconfig tap0 create

btpand -d ubt0 -i tap0 -s NAP -a 00:18:e7:1a:24:9b

ifconfig tap0 192.168.2.2 netmask 255.255.255.0

Ну, тут всё понятно — создаём интерфейс tap0, через который будет работать голубозубый линк, поднимаем сам линк, и затем конфигурируем интерфейсы — прописываем IP-адрес, на котором оно будет работать.

Проверяем наличие присутствия связи:

notebook# ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=22.778 ms
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=18.257 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=39.277 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=18.313 ms

Типа, работает, что ли? Афигеть... :-)

Ну чо, подадим на ноут интернет теперь — пропишем nameserver на ноуте в /etc/resolv.conf, а серверный голубозубый IP-шник в качестве шлюза и перенастроим правила файрвола, чтобы он ноут пускал в интернет:

route add default 192.168.2.1

Проверяем:

notebook# ping ya.ru
PING ya.ru (77.88.21.8): 56 data bytes
64 bytes from 77.88.21.8: icmp_seq=0 ttl=57 time=85.294 ms
64 bytes from 77.88.21.8: icmp_seq=1 ttl=57 time=74.188 ms
64 bytes from 77.88.21.8: icmp_seq=2 ttl=57 time=217.258 ms

Круто! Грузим KDE и пытаемся открыть http://shoutcast.com Получаем облом. Сайт грузится, но не до конца, и запустить прослушивание чего-нибудь оттуда невозможно — даже плейлист не качается. Интуиция подсказывает, что раз что-то работает, а что-то нет при живом линке, то это проблемы с MTU. Начинаю гонять пинги разного размера, определяя, какой максимальный размер пинга пройдёт. Оказалось, что пинги размером 641 байт проходят, и больше — хрен. А MTU на интерфейсах tap0 выставился дефолтный в 1500. Мораль — надо копать. Накопал только вот это. Симптомы там у товарища в точности как у меня — MTU в районе 600 байт, иначе хеликоптер нихт. Но потом он перезагрузил телефон, к которому подключал комп по BT, и чудесным образом всё заработало с правильным MTU 1500. Но у меня такая маза не прокатила — сразу после перезагрузки оно вроде заработал с MTU 1500, но через пару минут всё отвалилось, в том числе ssh. Так что на текущий момент MTU 640 является обязательным.

Ну, теперь надо как-то организовать, чтобы вся эта хрень запускалась при старте системы. Условия у меня довольно специфические — в сервере BT-адаптер торчит всегда, а в ноуте — практически всегда, потому что я его в качестве плейера радива из интернета использую. Значит, надо либо в rc.local вписывать, что проще, но криво, либо написать rc-скрипт. Поскольку лёгких путей мы не ищем, то я выбрал второй вариант.

Скрипт будет принимать такие параметры:

btpand_enable — разрешено или нет запускать btpand (по умолчанию NO);
btpand_device — девайс bluetooth, с которого работаем;
btpand_interface — интерфейс, на котором работать (по умолчанию tap0);
btpand_servicebtpand_service — сервис, который мы используем (GN, NAP, PANU, по умолчанию NAP);
btpand_linkup — скрипт, выполняемый при установлении соединения;
btpand_linkdown — скрипт, выполняемый при разрыве соединения;
btpand_server — MAC-адрес сервера, к которому будем подключаться, если работаем как клиент;
btpand_iface_addr — это параметр для конфигурирования интерфейса — прописывания IP-адреса и пр. Синтаксис такой же, как и у параметров rc.conf типа «ifconfig_rl0» — эта строка просто скармливается ifconfig'у.

Скрипты linkup/linkdown мне нужны, чтобы прописывать шлюз по умолчанию. В других задачах, возможно, потребуется ещё что-нибудь делать. Это необязательный параметр. Как, в общем, и многие другие. Обязательным будет являеться только btpand_enable и btpand_iface_addr для обоих компов, и btpand_server — только при запуске на клиенте. Остальное либо не обязательно, либо конфигурируется по умолчанию, как параметр btpand_interface.

Собственно, родился такой несложный скрипт:

!/bin/sh

PROVIDE: btpand

REQUIRE: DAEMON sdpd

BEFORE: LOGIN

KEYWORD: nojail

. /etc/rc.subr

name=«btpand»
rcvar=set_rcvar
command=«/usr/sbin/btpand»

load_rc_config $name

eval «${rcvar}=\${${rcvar}:-'NO'}»

btpand_interface=${btpand_interface:-«tap0»}
btpand_device=${btpand_device:-«ubt0hci»}
btpand_service=${btpand_service:-«NAP»}
btpand_server=${btpand_server:-«no»}
btpand_iface_addr=${btpand_iface_addr:-«dhcp»}
btpand_linkup=${btpand_linkup:-«no»}
btpand_linkdown=${btpand_linkdown:-«no»}

start_cmd=«btpand_start»
stop_precmd=«btpand_stopprecmd»
stop_postcmd=«/sbin/ifconfig ${btpand_interface} destroy»

btpand_start()
{
if [ ! -e /dev/${btpand_interface} ]
then /sbin/ifconfig ${btpand_interface} create
fi
/sbin/ifconfig ${btpand_interface} mtu 640
if [ «dhcp» = «${btpand_iface_addr}» ]
then /sbin/dhclient ${btpand_interface}
else /sbin/ifconfig ${btpand_interface} ${btpand_iface_addr}
fi
if [ «no» = «${btpand_server}» ]
then $command -d ${btpand_device} -s ${btpand_service} -i ${btpand_interface} > /dev/null 2>&1
else $command -d ${btpand_device} -s ${btpand_service} -i ${btpand_interface} \
-a ${btpand_server} > /dev/null 2>&1
fi
if [ ! «no» = «$btpand_linkup» ]
then sh ${btpand_linkup}
fi
}

btpand_stopprecmd()
{
if [ ! «no» = «$btpand_linkdown» ]
then sh ${btpand_linkdown}
fi
}

run_rc_command «$1»

Осталось это всё запустить. На сервере говорим:

echo btpand_enable=«YES» >> /etc/rc.conf

echo btpand_iface_addr=«192.168.2.1 netmask 255.255.255.0» >> /etc/rc.conf

На клиенте прописываем:

echo btpand_enable=«YES» >> /etc/rc.conf

echo btpand_iface_addr=«192.168.2.2 netmask 255.255.255.0» >> /etc/rc.conf

echo btpand_server=«00:18:e7:1a:24:9b» >> /etc/rc.conf

echo btpand_linkup=«/home/vasya/bt_linkup» >> /etc/rc.conf

И создаём файл /home/vasya/bt_linkup с таким содержанием:

!/bin/sh

route add default 192.168.2.1

Перезапускаем сервер, перезапускаем ноут — судя по лампочкам на BT-адаптере, линк поднялся. Проверяем:

notebook# ping ya.ru
PING ya.ru (77.88.21.8): 56 data bytes
64 bytes from 77.88.21.8: icmp_seq=0 ttl=57 time=66.597 ms
64 bytes from 77.88.21.8: icmp_seq=1 ttl=57 time=93.634 ms
64 bytes from 77.88.21.8: icmp_seq=2 ttl=57 time=49.616 ms

Точно, поднялся. Ну, значит, топаем в KDE и запускаем чего-нибудь с Shoutcast'a бодрое на прослушивание! :-)

Область применения

Вообще-то, это можно юзать не только для связи двух компов с фрёй между собой. BT-сервис «LAN over PPP» — довольно специфический, виндовые драйвера, которые я пробовал, его просто не видят, так что когда я захотел ноут с виндой, не имеющий WiFi адаптера, но имеющий BT, подключить в интернет через LAN over PPP, настроенный на серваке, то круто обломался.

Да и мобильные устройства далеко не все умеют LAN over PPP. Например, у меня был КПК HP hx2190 — он мог подключаться к такому сервису на сервере, и ходить через него в интернет и прослушивать музыку. А вот коммуникатор HTC Touch уже к серваку подключиться не мог — его BT-стек не поддерживает этот сервис. Touch, конечно, может работать по WiFi, который у меня всё равно в квартире есть, но WiFi гораздо более прожорлив в смысле батарейки, так что BT сильно предпочтительней, тем более что разницы в скорости между BT и WiFi линках на коммуникаторе практически незаметно.

К тому же, в коммуникаторе нет сервиса Dial-up internet, он интернет умеет раздавать только через PAN. При наличии btpand можно спокойно подключить 8-ую фрю к коммуникатору и заюзать интернет через EDGE.