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

В упомянутом уже 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.