Toshiba Satellite A100-811: ещё немного о Bluetooth. Удалённый доступ.

Итак, мы настроили устройство Bluetooth-адаптера. Что дальше? Ну, для начала, если Ваш телефон умеет GPRS и у Вас есть подписка, можно настроить удалённый доступ через GPRS-модем, в роли которого будет выступать Ваш телефон, оснащённый Bluetooth. В принципе, всё, о чём пойдёт речь ниже - вполне применимо и к настройке доступа с помощью GPRS + IrDA. Разве что во втором случае в качестве модема будет использоваться устройство ircomm, а не знакомый нам уже rfcomm.

Самый простой способ ИМХО, это настроить соединение в какой-нибудь звонилке, а ля kppp. Хотя, можно сделать это и с помощью скриптов ppp. Описание второго способа попадалось мне довольно часто, поэтому я думаю, у желающих и без меня будет масса возможностей настроить доступ с помощью скриптов. Я приведу пример, но подробно останавливаться на деталях не буду. С kppp и того проще. Моя цель лишь указать на некоторые вещи, которые мешают установить работоспособное соединение и которые не всегда очевидны для начинающих пользователей.

Будем исходить их того, что Bluetooth у Вас уже настроен, как рассказывалось ранее и есть конфиг для устройства, эмулирующего последовательную линию - rfcomm (для IrDA это будет устройство ircomm). На настройках телефона останавливаться не будем. Они в любом случае не универсальны и будут зависеть от Вашего оператора, которого и надо будет терроризировать на предмет информации по этому поводу :)

Первое, что мы сделаем, это убедимся, что телефон предоставляет услугу удалённого доступа (для Bluetooth это профиль DUN, для IrDA всё немного проще, ибо у IrDA устройств нет профилей, как это имеет место с Bluetooth). При включенном Bluetooth-адаптере запускаем:

root@devel0:/home/f0x# hcitool scan
Scanning ...
        00:0E:07:DC:F8:3E       Red Quick Fox
root@devel0:/home/f0x# hcitool inq
Inquiring ...
        00:0E:07:DC:F8:3E       clock offset: 0x71ce    class: 0x520204
root@devel0:/home/f0x# sdptool browse
Inquiring ...
Browsing 00:0E:07:DC:F8:3E ...
Service Name: Dial-up Networking
Service RecHandle: 0x10000
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100

Service Name: Voice gateway
Service RecHandle: 0x10002
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0100

Service Name: Serial Port 1
Service RecHandle: 0x10003
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 4

Service Name: Serial Port 2
Service RecHandle: 0x10004
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 5

Service Name: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100

Service Name: IrMC Synchronization
Service RecHandle: 0x10006
Service Class ID List:
  "IrMC Sync" (0x1104)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 11
  "OBEX" (0x0008)
Profile Descriptor List:
  "IrMC Sync" (0x1104)
    Version: 0x0100

Service Name: HF Voice gateway
Service RecHandle: 0x10007
Service Class ID List:
  "Handfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 6
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0100

Service Name: OBEX Basic Imaging
Service RecHandle: 0x1000b
Service Class ID List:
  "Imaging Responder" (0x111b)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 15
  "OBEX" (0x0008)
Profile Descriptor List:
  "Imaging" (0x111a)
    Version: 0x0100

Service Name: OBEX File Transfer
Service RecHandle: 0x1000f
Service Class ID List:
  "OBEX File Transfer" (0x1106)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 7
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX File Transfer" (0x1106)
    Version: 0x0100

Первой командой мы просто сканируем эфир в поисках другого Bluetooth-устройства и находим его. Второй командной смотрим, что это за устройство - класс. Хотя второе - это скорее чисто эстетический манёвр для маньяков :) И наконец с помощью третьей команды мы узнаём, какие сервисы нам предоставляет удалённое устройство. Первый блок информации и есть то, что нам нужно:

Service Name: Dial-up Networking
Service RecHandle: 0x10000
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100

Это наш профиль DUN (Dial-Up Networking).

Чобы создать соединение РРР, в /etc/ppp/peers создайте файл с именем новой точки. В этот файл мы свалим параметры для нового соединения. Скорее всего (во всяком случае, так обстоит дело с моим оператором), нам придётся отключить всякое сжатие. Должно получиться что-то вроде этого:

/dev/rfcomm0 # [ устройство, эмулирующее последовательною линию RS-232 по Bluetooth ]
 115200
 connect "/usr/sbin/chat /etc/chatscripts/gprs"

 noauth 
 defaultroute 
 lock 
 debug   # [ вставляем на всякий случай, пока всё не будет обкатано ]
 novjccomp
 nopcomp
 noaccomp
 nodeflate
 novj
 noccp
 nobsdcomp
 default-asyncmap
 ipcp-accept-local
 ipcp-accept-remote
 lcp-echo-failure 100
 lcp-echo-interval 30
 usepeerdns
 user <user_name>

Здесь user_name - имя пользователя, под которым Вы будете стучаться на РРР-сервер Вашего оператора. Как показывает практика, у некототорых операторов есть определённые ограничения на работу с PPP при доступе по GPRS. Это касается прежде всего поддержки сжатия (специально наматывают траф? :( ). Отключаем, всё что можно:

1. novjccomp, novj - отключить сжатие TCP/IP по Ван Якобсону.
2. nobsdcomp - отключить сжатие пакетов по схеме BSD.
3. nodeflate - отключить сжатие Deflation.
4. noaccomp - отключить сжатие адресов/управляющих пакетов.
5. nopcomp - отключить согласование сжатия между удалённой точкой и нашей машиной.
6. noccp - отключить протокол управления сжатием.

Далее, часто встречается ситуация, когда удалённая точка по каким-либо причинам не в состоянии корректно обеспечить управление линией (на уровне LCP - Link Control Protocol - протокол управления линией). Как правило, это выражается в том, что клиентская машина посылает LCP-запросы, чтобы выяснить состояние линии, но не получает отклика от сервера. В подобном случае содинение разрывается по инициативе клиента, т.к. pppd исходит из того, что линия неработоспособна. Насколько это хорошо, сказать сложно. Но изменить поведение демона, отключив ожидание откликов не представляется возможным. Я более склонен возложить вину на оператора, нежели на демон pppd, ибо ИМХО это вполне в силах оператора обеспечить корректную работу ppp-сервера.

Работа LCP в частности управляется параметрами lcp-echo-failure и lcp-echo-interval (на самом деле, параметров LCP, конечно, немного больше). Первый (lcp-echo-failure) задаёт максимальное количество попыток, по истечении которого считается, что произошёл сбой линии. Второй параметр (lcp-echo-interval) определяет временной интервал между посылками LCP-запросов, на которые удалённый сервер должен прислать своё эхо. Время устанавливается в секундах. В нашем случае параметры имеют значения 100 и 30 соответственно, т.е. если ни на один из посланных 100 запросов не был получен отклик, при том, что запросы отправляются с периодичностью в 30 с, то линия считается мёртвой и демон разрывает соединение. При этом в лог сыплется что-то вроде этого (при включении debug):

Nov  3 23:55:57 devel0 pppd[19993]: pppd 2.4.4 started by f0x, uid 1000
Nov  3 23:55:57 devel0 pppd[19993]: Using interface ppp0
Nov  3 23:55:57 devel0 pppd[19993]: Connect: ppp0 <--> /dev/rfcomm0
Nov  3 23:55:57 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 0
Nov  3 23:55:57 devel0 pppd[19993]: PAP authentication succeeded
Nov  3 23:55:58 devel0 pppd[19993]: local  IP address 10.20.85.219
Nov  3 23:55:58 devel0 pppd[19993]: remote IP address 212.98.170.50
Nov  3 23:55:58 devel0 pppd[19993]: primary   DNS address 77.74.32.66
Nov  3 23:55:58 devel0 pppd[19993]: secondary DNS address 77.74.32.11
Nov  3 23:56:27 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 1
Nov  3 23:56:57 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 2
Nov  3 23:57:27 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 3
...
Nov  4 00:43:29 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 95
Nov  4 00:43:59 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 96
Nov  4 00:44:29 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 97
Nov  4 00:44:59 devel0 pppd[19993]: LCP: Rcvd Code-Reject for code 9, id 98
Nov  4 00:45:59 devel0 pppd[19993]: No response to 100 echo-requests

lock - традиционный параметр, предписывающий pppd создавать файл блокировки и т.о. обеспечивает исключительный доступ к соединению. defaultroute - установить новый маршрут к PPP-шлюзу, полученный при установке соединения, маршрутом по умолчанию. usepeerdns - использовать DNS удалённой точки, позволяет не заботиться о поиске собственного DNS :) noauth - не требовать от удалённой точки авторизации. ipcp-accept-local и ipcp-accept-remote - параметры, определяющие, будут ли приняты адреса удалённой точки и нашей машины по инициативе удалённого сервера, даже если локально адреса уже были заданы. Так в общих чертах обстоит дело с конфигурированием соединения с удалённой точкой - РРР-сервером.

Далее, в случае с настройкой соединения с помощью скриптов идёт скрипт чата, определяющий реакцию на состояния линии ("занято", "звонок", "удалённый модем положил трубку" и т.п.). Здесь же прописывается номер, который набирает модем. В общих чертах скрипт чата выглядит так:

ECHO ON 
 ABORT '\nBUSY\r' 
 ABORT '\nERROR\r' 
 ABORT '\nNO ANSWER\r' 
 ABORT '\nNO CARRIER\r' 
 ABORT '\nNO DIALTONE\r' 
 ABORT '\nRINGING\r\n\r\nRINGING\r' 
 '' \rAT 
 TIMEOUT 12 
 OK ATH 
 OK ATE1 
 OK AT+CGDCONT=1,"IP","internet-address" 
 OK ATD*99*1# 
 TIMEOUT 22 
 CONNECT

Кладём этот файл в /etc/chatscripts/ под именем, ну, хотя бы gprs (за более подробными сведениями обращайтесь к man-страницам). Далее, в файле /etc/ppp/pap-secrets прописываем имя пользователя и пароль:

user_name * password

где user_name и password - соответственно имя пользователя и пароль, под которыми Вы ходите на сервер оператора. В общих чертах, всё. Теперь можно устанавливать соединение командой pppd call peer-name, где peer-name - имя точки доступа в /etc/ppp/peers.

Настройка доступа с помощью kppp отличается лишь тем, что параметры конфигурации для pppd и прочее нужно прописывать не в файлах ppp, а в диалогах kppp. В качестве устройства модема при конфигурировании устройства в kppp указывайте /dev/ircomm0 (или другое число вместо нуля в зависимости от того, как у вас настроена подсистема ircomm).

Toshiba Satellite A100-811: Bluetooth (solved)

Привет, мир! Я долго и упорно молчал, как румынский партизан и вот, наконец нашёл о чём написать :) Долго мне не удавалось заставить полноценно работать встроенный в ноутбук Bluetooth-адаптер. В конце-концов, задача была решена. Не скажу, что решение оказалось экстраординарным, но как это часто бывает, правильные мысли появляются пост-фактум.

Как писалось ранее, в некоторых моделях Toshiba Bluetooth включается через интерфейс HCI, в некоторых - через ACPI. Но стандартные драйвера toshiba и toshiba_acpi, входящие в ядро, для меня так и не заработали. Таким образом, первая проблема, с которой я здесь столкнулся, оказалось отсутствие драйвера. После некоторых поисков я наткнулся на проект omnibook на sourceforge.net. Предполагается, что все необходимые дайверы были скомпилированы статически или в виде модулей. Конфигурация приблизительно такая:

Configuration for 2.6 kernels
  Networking --->


<*> Bluetooth subsystem support  --->


--- Bluetooth subsystem support
<M>   L2CAP protocol support
<M>   SCO links support
<M>   RFCOMM protocol support
[*]     RFCOMM TTY support
<M>   BNEP protocol support
[*]     Multicast filter support
[*]     Protocol filter support
<M>   HIDP protocol support


Bluetooth device drivers  --->
<M> HCI USB driver
[*]   SCO (voice) support
<M> HCI UART driver
[*]   UART (H4) protocol support
[*]   BCSP protocol support
[*]   Transmit CRC with every BCSP packet
<M> HCI BCM203x USB driver
<M> HCI BPA10x USB driver
<M> HCI BlueFRITZ! USB driver
(The four drivers below are for PCMCIA Bluetooth devices and will only
show up if you have also selected PCMCIA support in your kernel.)
<M> HCI DTL1 (PC Card) driver
<M> HCI BT3C (PC Card) driver
<M> HCI BlueCard (PC Card) driver
<M> HCI UART (PC Card) device driver
(The driver below is intended for HCI Emulation software.)
<M> HCI VHCI (Virtual HCI device) driver


(Move back three levels to Device Drives and then check if USB is
enabled. This is required if you use a Bluetooth dongle, which are mostly USB
based.)
USB support  --->


<*> Support for Host-side USB
--- USB Host Controller Drivers
<M> EHCI HCD (USB 2.0) support
[ ]   Full speed ISO transactions (EXPERIMENTAL)
[ ]   Root Hub Transaction Translators (EXPERIMENTAL)
<*> OHCI HCD support
<*> UHCI HCD (most Intel and VIA) support
< > SL811HS HCD support

Правда, PCMCIA я у себя отключил.

Итак, качаем последнюю версию модуля с sourceforge.net.

$ svn co https://omnibook.svn.sourceforge.net/svnroot/omnibook/trunk
...
$ mv trunk omnibook

Собираем модуль:

# cd omnibook
# make -C /lib/modules/$(uname -r)/build modules SUBDIRS=$(pwd)

или просто

# make; make install

:-) Теперь загружаем модуль с помощью modprobe omnibook.

В моём случае, правда, модуль не загрузился, т.к. моя модель не определилась как поддерживаемая. Модель определяется по данным из пула DMI (Desktop Management Interface - часть SMBIOS, хранящая данные о конфигурации платформы). Список официально поддерживаемых моделей можно найти здесь. Но если даже Ваша модель не поддерживается официально, можно выяснить, какая из официально поддерживаемых моделей наиболее близка Вашей и загрузить модуль принудительно с параметром ectype=x (ectype - embedded controller type - тип встроенного контроллера). В моём случае ectype равен 12 (Toshiba Satellite M70). Если всё прошло удачно, в директории /proc появится поддиректория omnibook. Каждый файл в этой директории соответствует одной функции контроллера, кроме файлов version и dmi (версия драйвера и информация, полученная из пула DMI соответственно):

f0x@devel0:~$ ls -la /proc/omnibook/
total 0
dr-xr-xr-x   2 root root 0 2007-10-23 23:50 .
dr-xr-xr-x 161 root root 0 2007-09-02 11:41 ..
-rw-r--r--   1 root root 0 2007-10-23 23:50 blank
-rw-r--r--   1 root root 0 2007-10-23 23:50 bluetooth
-rw-r--r--   1 root root 0 2007-10-23 23:50 display
-r--r--r--   1 root root 0 2007-10-23 23:50 dmi
-rw-r--r--   1 root root 0 2007-10-23 23:50 lcd
-r--r--r--   1 root root 0 2007-10-23 23:50 temperature
-rw-r--r--   1 root root 0 2007-10-23 23:50 throttling
-r--r--r--   1 root root 0 2007-10-23 23:50 version
-r--r--r--   1 root root 0 2007-10-23 23:50 wifi

За описанием функций контроллера Вы можете обратиться на http://omnibook.sourceforge.net/doku.php. Нас же здесь больше всего интересует файл bluetooth. Файл содержит фразу "Bluetooth adapter is present and disabled." Т.е., по умолчанию bluetooth-адаптер отключен. Включить его можно простой записью единицы в файл:

echo 1 > /proc/omnibook/bluetooth

Для выключения, аналогично, записываем в файл "0".

Далее предполагается, что все необходимые пакеты для работы с bluetooth (bluez-* или метапакет bluetooth, к-й потянет за собой по зависимостям всё, что нужно и что ненужно тоже) установлены. Таким образом, следующий шаг - настройка всего, что нужно для работы с bluetooth. Прежде всего следует сконфигурировать hcid - демон, предоставляющий интерфейс к HCI - интерфейсу хост-контроллера. Ниже приводится моя конфигурация с комментариями:

# /etc/bluetooth/hcid.conf
#
# 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";
}

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

 # Local device class
 class 0x3e0100;

 # Default packet type
 pkt_type DM1,DM3,DM5,DH1,DH3,DH5,HV1,HV2,HV3;

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

 # 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 accept;

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

Немного по опциям. Секция options - настройки демона:

1. autoinit - автоматически инициализировать подсоединённые устройства (bluetooth-адаптеры)
2. security - безопасность: none - не использовать PIN-код;
   auto - использовать для доступа к устройству, подсоединяемому через bluetooth локальный PIN по умолчанию, указанный в опции passkey;
   user - запрашивать PIN-код для установления соединения у пользователя.
3. pairing - опции соединения: multi - разрешать соединения с устройствами, которые уже соединены;
   none - запретить соединения;
   once - допускать только одно соединение с помощью данного адаптера и игнорировать все последующие попытки установить новое соединение.
4. passkey - PIN bluetooth-хоста по умолчанию. Он будет использоваться при добавлении Вашего компьютера другими bluetooth-устройствами в их списки устройств. Используйте любое число, которое Вам нравится.

Секция device - свойства контроллера:

1. name - имя Вашего bluetooth-устройства (хоста). В моём случае bluetooth-хосту присваивается то же имя, что и имя Unix-хоста.
2. class - класс устройства. Шестнадцатеричное число, определяющее класс bluetooth-устройства (хоста). С помощью битовой маски устанавливается тип хоста. За описанием битов обращайтесь к man hcid.conf или спецификации bluetooth. В моём случае средний байт 01 в 0x3e0100 обозначает, что мой хост - это компьютер, а не телефон, принтер или HID-устройство :-)
3. pkt_type - типы пакетов. За разъяснениями также советую обращаться к спецификации Bluetooth или просто оставьте, как есть.
4. iscan - разрешить другим bluetooth-устройствам обнаруживать Ваш хост при сканировании.
5. pscan - разрешить другим устройствам устанавливать соединения с Вашим хостом, используя канал "page channel".
6. discovto - время, на протяжении которого Ваш хост будет позволять обнаружить себя другому устройству. Устанавливается в секундах. 0 - устройство может быть обнаружено в любое время.
7. lm - режим установки соединения: none - не определено;
   accept - всегда принимать входящие запросы на соединение;
   master - принимать входящие соединения в роли ведущего и запретить изменение этой роли при исходящих соединениях.
8. lp - политика при установке соединения (касается пикосетей): none - не определено;
   rswitch - разрешить изменять роль (ведущий-ведомый);
   hold - эта политика необходима для синхронного обмена данными (нужно для беспроводной гарнитуры);
   sniff - позволить Вашему хосту пребывать в пикосети в определённые временные слоты. Когда устройство "отсутствует", оно может делать что-то другое, например, сканировать эфир, искать другие устройства;
   park - разрешить парковку хоста, т.е. позволять хосту переходить в энергосберегающий режим (сон). Устройство, входящее в пикосеть может "простаивать".

В принципе, то что здесь написано - это мой перевод информации из man hcid.conf, здесь я не буду разъяснять все принципы работы bluetooth-устройств и сетей, в которые такие устройства могут объединяться. Всем любопытным советую обратиться к первоисточнику - спецификации по Bluetooth.

Далее, нам необходимо отредактировать файл настройки подсистемы bluetooth - rfcomm для нашего хост-контроллера. rfcomm - Radio Frequency Communication - радиочастотная связь, это подсистема, которая эмулирует последовательную линию RS232 поверх протокола L2CAP. В принципе, настройка подсистемы rfcomm опциональна. Но для устройства, которое Вы хотите использовать, как модем, для сотового телефона, настроить её будет желательно, чтобы не делать этого каждый раз вручную. Ниже приведён пример конфигурационного файла:

# /etc/bluetooth/rfcomm.conf
#
# RFCOMM configuration file.
#

rfcomm0 {
# # Automatically bind the device at startup
 bind yes;
#
# # Bluetooth address of the device
 device 00:0A:0B:0C:0D:0E;
#
# # RFCOMM channel for the connection
# channel 1;
#
# # Description of the connection
 comment "SonyEricsson T630";
}

Пояснения:

1. rfcomm0 - первый последовательный интерфейс. Вообще-то, Вы можете сконфигурировать их столько, сколько захотите. Конфигурация каждого последовательного интерфейса начинается с его имени (rfcomm0, rfcomm1, rfcomm2, ...). Сами параметры интерфейса указываются в блоке между двумя фигурными скобками { и };
2. bind - автоматически привязывать сокет для нашего устройства при его обнаружении (yes или no, в случае, если Вы не хотите, чтобы сокет связывался автоматически;
3. device - MAC-адрес bluetooth-устройства (сотового телефона, например);
4. channel - канал bluetooth, который будет использоваться для связи с устройством;
5. comment - опциональный комментарий к интерфейсу.

При указании МАС-адреса Вашего устройства, его сначала надо узнать. Для этого поднимем устройство hci и просканируем эфир:

# hciconfig hci0 up
# hciconfig piscan
# hcitool scan
Scanning ...
        00:0E:0F:10:11:12       Red Quick Fox

Здесь мы просто запускаем устройство hci0 с помощью утилиты hciconfig и сканируем эфир с помощью hcitool с параметром scan. 00:0E:0F:10:11:12 - это и есть нужный нам MAC-адрес. Утилита hciconfig предназначена для конфигурирования хост-контроллера hci. Если контроллеров несколько, то они имеют имена hci0, hci1 и т.д.. hcitool позволяет совершать некие вменяемые действия с помощью нашего хост-контроллера. Иными словами, она позволяет им управлять. Для списка агрументов обеих утилит см. man hciconfig и man hcitool. Используя утилиту l2ping и МАС-адрес в качестве её аргумента, можно послать пинга телефону :-)

Следующая стадия конфигурирования bluetooth - редактирование ещё одного файла. В debian-based дистрибутивах linux это /etc/default/bluetooth. По существу, этот файл нужен только стартовому скрипту bluetooth из /etc/init.d. Сложного там ничего нет. Всё, что от Вас требуется, указать, должны ли сервисы bluetooth стартовать при загрузке системы и если да, то какие. Приведём пример файла /etc/default/bluetooth:

# Defaults for bluez-utils

# This file supersedes /etc/default/bluez-pan.  If
# that exists on your system, you should use this
# file instead and remove the old one.  Until you
# do so, the contents of this file will be ignored.

# start bluetooth on boot?
# compatibility note: If this variable is not found bluetooth will
# start
BLUETOOTH_ENABLED=1

############ DUND
#
# Run dund -- this allows ppp logins. 1 for enabled, 0 for disabled.
DUND_ENABLED=1

# Arguments to dund: defaults to acting as a server
DUND_OPTIONS="--listen --persist"

# Run dund --help to see the full array of options.
# Here are some examples:
#
# Connect to any nearby host offering access
# DUND_OPTIONS="--search"
#
# Connect to host 00:11:22:33:44:55
# DUND_OPTIONS="--connect 00:11:22:33:44:55"
#
# Listen on channel 3
# DUND_OPTIONS="--listen --channel 3"

# Special consideration is needed for certain devices. Microsoft
# users see the --msdun option.  Ericsson P800 users will need to
# listen on channel 3 and also run 'sdptool add --channel=3 SP'

############ SDPTOOL
# this variable controls the options passed to sdptool on boot, useful if you
# need to setup sdpd on boot.
# options are ;-separated, i.e. for every ; an sdptool instance will be
# launched
#
# examples:
# SDPTOOL_OPTIONS="add --channel=3 SP" # ericsson P800 serial profile
# SDPTOOL_OPTIONS="add --channel=8 OPUSH ; add --channel=9 FTRN" # motorola
#                                             # object push and file transfer
SDPTOOL_OPTIONS=""

Здесь переменная BLUETOOTH_ENABLED=1 определяет, что при загрузке системы должны стартовать и сервисы bluetooth. Если переменная установлена в 0, поддержка bluetooth не включается. Если переменная не найдена, то по умолчанию сервисы загружаются. DUND_ENABLED=1 определяет, что должен быть запущен демон Dial-up-доступа. Ну, вот практически и всё. В переменной SDPTOOL_OPTIONS определяется, какие сервисы должен предоставлять наш компьютер другим bluetooth-устройствам. Список сервисов можно пополнить и вне этого файла с помощью sdptool (см. man sdptool). В общем и в целом Unix-box теперь готов к работе с bluetooth-устройствами. Можете по bluetooth зайти на сотовый телефон, настроить пикосеть, работающую через BNEP или ещё что-нибудь. Про HID я не писал, ибо не имею таковых девайсов. Про настройку пикосети на bluetooth Вы сможете узнать сами.

Что касаемо телефонов, было замечено одно занятное обстоятельство: PIN, указанный в конфигурационном файле hcid.conf внаглую игнорируется с новыми телефонами (т.е., с теми, с которыми мы раньше не работали). В качестве противоядия можно использовать следующее: создать маленький скрипт, который просто выводит с помощью echo PIN-код - echo "PIN:XXXX", где ХХХХ - Ваш PIN. Допустим, этот скрипт будет называться helper. Далее, можно запустить passkey-agent --default ./helper. По идее, агент должен запускаться автоматически для каждой пользовательской сессии, но как показывает опыт, он этого почему-то не делает. Можно самостоятельно запихать passkey-agent в какой-нибудь скрипт. Ну, вот, собственно, и всё. Чтобы использовать сотовый телефон для Dial-up доступа в интернет в качестве GPRS-модема, укажите в качестве устройства модема /dev/rfcomm0 в конфиге Вашей звонилки, настройте доступ согласно информации Вашего оператора. А дальше - всё как всегда.

Toshiba Satellite A100-811: Bluetooth & suspend

Попутно ещё пара замечаний. В плане bluetooth в моём случае стоит ориентироваться на модуль toshiba_acpi. Отсюда можно почерпнуть косвенное подтверждение тому, что bluetooth активируется через ACPI. Очевидно, для моей модели нет поддержки. А может, здесь такой хитрый ACPI. В общем, я запасся последней спецификацией ACPI - попробую разобраться хоть частично, что к чему. Понять, по какой причине не грузится модуль сложно. Такой код ни к чему, в общем-то, не обязывает (drivers/acpi/toshiba_acpi.c):

static int __init toshiba_acpi_init(void)
{
 acpi_status status = AE_OK;
 u32 hci_result;
 int status2;

 if (acpi_disabled) {
  printk(MY_INFO"ACPI disabled, failed to initialize module\n");
  return -ENODEV;
 }

 if (!acpi_specific_hotkey_enabled) {
  printk(MY_INFO "Using generic hotkey driver\n");
  return -ENODEV;
 }
 /* simple device detection: look for HCI method */
 if (is_valid_acpi_path(METHOD_HCI_1))
  method_hci = METHOD_HCI_1;
 else if (is_valid_acpi_path(METHOD_HCI_2))
  method_hci = METHOD_HCI_2;
 else {
  printk(MY_INFO"device detection: no valid HCI method available\n");
  return -ENODEV;
 }
 ...

Так или иначе, но драйвер не очень многословен и максимум на что его хватает - возвратить ENODEV. Не знаю, насколько это удачная идея, но попробую поиграться с модулем. Для начала имеет смысл вставить в код формальные метки, чтобы было яснее, что может быть не так. Дальше, посмотрим по результатам изучения спецификации и наличного металлолома. К слову, в связи со всем этим, хотелось бы сказать своё "фи" в адрес конторы, носящей гордое название "Toshiba". Похоже, что фирме гораздо выгоднее "рекомендовать Windows Vista", чем поддерживать клиентов хотя бы более подробной технической информацией в интернет, я уж не говорю о том, что можно было собраться с силами и наваять-таки что-нибудь и для linux, хотя бы вот как Intel или nVidia. (Эмоции, однако).

В отношении suspend: как минимум два потока ядра (две подсистемы, два драйвера - называйте, в общем, как хотите) не дают перейти системе в suspend. А именно:

1. fs/xfs/linux-2.6/xfs_super.c::xfssyncd()
2. net/core/pktgen.c::pktgen_thread_worker()

1-й из них - поток ядра, создаваемый xfs для синхронизации файловой системы. Не совсем понятно, почему дизайн ФС именно такой, какой он есть, но здесь можно аргументировать отсутствие поддержки режима сна. Хотя, с другой стороны, вместе с тем, что нет вызова try_to_freeze(), нет и установки флага PF_NOFREEZE. Не уверен на все 100%, но вероятно, добавление строки current->flags |= PF_NOFREEZE; позволило бы обойти проблему. Правда, это по-своему рискованно. Должна быть гарантия, что поток не изменит уже сохранённый на свопе образ системы. Иными словами, нельзя, допустим, чтобы после выгрузки образа системы на устройство подкачки кто-то/что-то изменило данные на винчестере. Возникает несоответствие между актуальным состоянием файловой системы и тем, что было сохранено в дамп на свопе. Причина достаточно веская, чтобы не экспериментировать. Впрочем, мои предположения ещё нужно подтвердить. Проще всего это наверно сделать путём сбора статистики юзеров. Если всё же есть люди, у которых xfs уживаются в одном флаконе с suspend - то тем лучше, значит проблема лечится без лоботомии или ампутации.

По поводу 2-го, не совсем понятно, почему там нет поддержки спящего режима. pktgen_thread_worker() - он же наблюдаемый в ps ax, как kpktgend_[0|1] - не что иное, как генератор пакетов, предназначенный для тестирования сети. Совсем не понятно, почему генератор пакетов _не_должен_ замораживаться и что он будет делать, если сетевые интерфейсы будут отключены.

Строго говоря, список драйверов, не поддерживающих suspend этими двумя пунктами не исчерпывается. Кое-что по этому поводу написано здесь - http://suspend2.epfl.ch/status. Список довольно общего плана, но даёт некоторое представление о том, с чем suspend2 может не заработать (suspend это, кстати, касается тоже).

Toshiba Satellite A100-811: Hello world!

Итак, приступим. Запись за номером 1 не очень оптимистичная. Ноутбук Toshiba Satellite A100-811 оказалось не так-то легко окультурить. Легко было только ушатать установленную там по умолчанию Windows Home Edition. В общем, будем исходить из того, что это - своеобразный TODO.

Далее по списку для ОС Debian GNU/Linux 3.1 на ядре 2.6.20:

1. до сих пор нет ничего определённого на счёт встроенного bluetooth. Поддержка брендовых фич в ядре ничего не даёт. По правде, я уже запутался. Эти фичи должны обеспечиваться фирменным ACPI. Или...? По порядку (по опциям конфига ядра): TOSHIBA - поддержка доступа к режиму управления системой (Toshiba System Management Mode). Категорически не работает на тошибах с Phoenix BIOS'ом. Это очень прискорбно, так как нет возможности воспользоваться Dial-up доступом к интернет. ACPI_TOSHIBA тоже не помогает.


2. встоенный модем, работающий через самосборный slmodemd c поддержкой alsa как бы работает, но дозвониться по нему как бы не получается.


3. suspend - это вообще отдельная большая и больная тема. Проблема, собственно, сугубо ядерная в моём случае. На ванильное ядро был накачен патч suspend2-2.2.9.10-for-2.6.20.patch.bz2. И всё быть может было бы и ничего, если бы не ФС. Цикл засыпания прерывается из-за невозможности заморозить потоки ядра - xfssyncd и kpktgen. Второй можно безболезненно вышвырнуть из ядра. В принципе, мне этот генератор пакетов абсолютно нафиг нужен сейчас. Но с XFS получилось совсем не хорошо.


4. не работают функциональные клавиши (см. п.1 - суть проблемы та же).

Вот то основное, что хотелось бы исправить на данный момент. В отношении suspend придётся искать альтернативное решение или совсем отказаться от него. Было бы лучше, если бы удалось работать его. На случай форс-мажора, если допустим, Вы отлучились от лаптопа на некоторое время, а батарея почти иссякла. В подобной ситуации было бы неплохо, если бы за 5-10 минут до полной разрядки батарей система автоматически в превентивном порядке заснула и отключила питание.

По поводу bluetooth - при наличии подписки GPRS было бы крайне удобно работать с интернет через сотовый телефон (а подписка у меня есть). При том, что GPRS покрытие в Беларуси очень даже радует, а качество стало не впример лучше, это хорошая возможность - работать с электронной почтой в дороге/там, где нет локалки или обычных телефонных коммуникаций, либо доступ к ним затруднён.

В отношении всего остального: при инсталляции системы ядро (дистрибутивное 2.6.8) немного фыркало в сторону SATA. Это было устранено почти сразу, как только была установлена базовая система и заменено ядро. Со встроенным Ethernet-адаптером проблем по определению быть не должно было. Некоторые проблемы были с Wi-Fi. Но об этом немного попозже, тем более, что сейчас проблема устранена.

Не был протестирован кардридер. По объективным причинам - отсутствие объектов исследования - а.к.а. этих самых карт.

Особняком стоит поддержка встроенного видео 945GM. Точнее было бы сказать, что её нет вообще. Пока Х работает через VESA. Разрешение вполне приличное - 1280х800. Излишне, впрочем, говорить, что фильм в полноэкранном режиме в том же xine особо не посмотришь и в Q3A не поиграешь. Лекарство есть - Xorg 7.1 (vs Xorg 6.9, установленного из бэкпортов). Но... Нет релиза - нет Xorg 7.1. Так что, ждём.

Вообще, вот как выглядит всё хозяйство при более подробном рассмотрении:

0000:00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
0000:00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03)
0000:00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
0000:00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
0000:00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
0000:00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
0000:00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02)
0000:00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02)
0000:00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
0000:00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
0000:00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 02)
0000:00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
0000:05:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)
0000:07:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
0000:07:06.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
0000:07:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
0000:07:06.3 0805: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller
0000:07:08.0 Ethernet controller: Intel Corporation PRO/100 VE Network Connection (rev 02)

PS: по поводу suspend - наиболее приемлемым решением было бы вправить ядру мозги на предмет XFS. Но как? Подолжаем поиски решения.