Re: [Comm] Fwd: Каноническое подключение DialUp через Bluetooth

["Vasiliy D. Sevostyanov" <dil8016@mail.ru>]

[-- Attachment #1: Type: text/plain, Size: 3737 bytes --]

Hi, you wrote 14:22 Sat 06 Dec :
> Вот, понадобилось в связи с поломкой usb-разъема в телефоне.
> 
> Кое-как удалось поднять "на коленке", используя инструкции из пакета
> docs-linux_bluetooth_gprs-0.1-alt2 (
> http://heap.altlinux.org/modules/LinuxBluetoothGPRS.kirill/index.html).
> Однако эта инструкция явно устарела.
Да уж. rfcomm командой mknod создавать уже давно не надо. А вот канал
DUN я всегда указываю так, как там сказано (в скрипте `rfcomm bind $RFDEV $MAC 1`),
у меня на всех телефонах 1.
> Интересно, есть ли что посвежее для настройки в стиле "шаг-за-шагом"?
> 
Я на p7 до сих пор пользуюсь pppd+BT. Попробую описать.
> Пока что я пользуюсь таким небольшим списком:
> 
> 1. Проверить, запущены ли службы messagebus и bluetoothd. Кстати, а
> проверяется ли вообще зависимость служб при запуске? Потому как bluetoothd
> без запущенной dbus не стартует, и причину понять можно только по журналам.
> И похоже, у меня аналогичные пробемы со squid, который приходится
> перезапускать уже после входа в систему, иначе он отказывается раздавать
> Inet. Подозреваю, это оттого, что squid стартует раньше network, но пока
> нет времени разобраться.
Я messagebus не трогаю, только bluetoothd, а пару раз даже без него
работало (но нестабильно).
`systemctl restart squid` можно запхать в ip-up.d/05squid, к примеру.
> 
> 2. Создать устройства rfcomm. Пока что делаю это руками, но, похоже,
> правильно это делать как описано в
> http://lists.altlinux.org/pipermail/sysadmins/2009-May/029977.html, хотя
> еще не пробовал.
По идее, NM или MM должны это делать, но на практике они только мешают
(чуть ниже сказано). Руками.
> 
> 3. Настройки ppp сложностей не вызывают, просто используем в качестве
> терминала rfcomm.
> 
> 4. Самое сложное --- соединение компьютера и телефона в BT-пару.
> Исследованные рекомендации отправляют меня к файлам, которых я не могу
> найти. Пока что использую blueman-manager, и то с плясками и бубнами.
> Удаляю устройство, добавляю устройство (иначе пару не образует), создаю
> пару, указываю код доступа, ввожу код доступа на телефоне. В принципе,
> работает, но хотелось бы, чтобы это отрабатывалось в скриптах без запуска
> blueman. И кроме того, в blueman однажды удалось поймать меню, где код
> доступа генерировался автоматически. Сейчас найти это действие не могу.
> Вот, этот вопрос тоже хотелось бы осветить.
Не знаю, разово: включил ВТ, в трее "Добавить устройство", потом после согласования в
телефонах (2 ноклы) ставлю "доверять всегда".
У меня нет blueman, вместо него bluedevil+bluez
14:40:13_demo:/tmp%  rpm -qa |grep blu
libgnome-bluetooth-3.12.0-alt1
libbluray-0.4.0-alt1
libbluedevil1-1.9.4-alt1
bluez-4.101-alt1
python-module-pybluez-0.16-alt2.1.1.1
liblua5.1-5.1.4-alt5
bluez-alsa-4.101-alt1
libbluez-4.101-alt1
bluedevil-1.3.2-alt1

Единственно, после создания канала нужно 2-3 раза подряд вызвать `pppd
call ks-rf rfcommX`, тогда телефон начинает соединение с сетью. И при первом
запуске после создания каждого rfcomm-устройства ModemManager начинает его
тестировать и гнать в порт всякий мусор, я его отключил вообще. А так в
документации у NetworkManager есть опции для ВТ-DUN, но запустить не
получилось.

Прикладываю свои рабочие файлы -- настроечные и скрипт запуска (если им
будете пользоваться, откорректируйте закомментированную часть в начале под свою
систему -- у меня надо поиграть с модулями, чтобы включить ВТ -- баг
#29081; также у меня в call-скрипте нет опции updetach -- это баг #30449 --
если что, раскомментируйте). Для чего несколько rfcomm-устройств: иногда телефон
сглючивает и обрывает соединение, а rfcommX на него остается до
перезагрузки, в таком случае скрипт берёт следующее свободное устройство
(не более 5).


-- 
С уважением, Василий Д. Севостьянов.

[-- Attachment #2: hcid.conf --]
[-- Type: text/plain, Size: 1263 bytes --]

#
# HCI daemon configuration file.
#

# HCId options
options {
	# Automatically initialize new devices
	autoinit yes;

	# Security Manager mode
	#   none - Security manager disabled
	#   auto - Use local PIN for incoming connections
	#   user - Always ask user for a PIN
	#
	security auto;

	# Pairing mode
	#   none  - Pairing disabled
	#   multi - Allow pairing with already paired devices
	#   once  - Pair once and deny successive attempts
	pairing multi;

	# Default PIN code for incoming connections
	passkey "1234";

	#security auto;
	
}

# Default settings for HCI devices
device {
	# Local device name
	#   %d - device id
	#   %h - host name
	name "%h-%d";

	# Local device class
	#class 0x000100;
	class 0x32010C;

	# Default packet type
	#pkt_type DH1,DM1,HV1;

	# Inquiry and Page scan
	iscan disable;
	discovto 0;
	pscan disable;

	# Default link mode
	#   none   - no specific policy 
	#   accept - always accept incoming connections
	#   master - become master on incoming connections,
	#            deny role switch on outgoing connections
	lm none;

	# Default link policy
	#   none    - no specific policy
	#   rswitch - allow role switch
	#   hold    - allow hold mode
	#   sniff   - allow sniff mode
	#   park    - allow park mode
	lp none;
}

[-- Attachment #3: rfcomm.conf --]
[-- Type: text/plain, Size: 504 bytes --]

#
# RFCOMM configuration file.
#

rfcomm0 {
	# Automatically bind the device at startup
	bind yes;

	# Bluetooth address of the device
	device 2C:D2:E7:19:B6:BC;

	# RFCOMM channel for the connection
	channel 1;

	# Description of the connection
	comment "noki 2690";
}
rfcomm1 {
	# Automatically bind the device at startup
	bind no;

	# Bluetooth address of the device
	device 54:79:75:A7:93:DD;

	# RFCOMM channel for the connection
	channel 1;

	# Description of the connection
	comment "noki 112";
}

[-- Attachment #4: inet.sh --]
[-- Type: application/x-sh, Size: 1046 bytes --]

[-- Attachment #5: ks-rf --]
[-- Type: text/plain, Size: 176 bytes --]

#updetach
#/dev/rfcomm0
921600
connect /etc/ppp/peers/chat
disconnect /etc/ppp/peers/dischat
defaultroute
crtscts
lock
noipdefault
noauth
ipcp-accept-local
ipcp-accept-remote