$Id: blueZ,v 1.7 2005/03/16 10:04:33 aleks Exp $ 

Bluetooth-Kram unter Linux mit Dlink DBT120 und Nokia 6310i
===========================================================

Flames und Rueckfragen: Alexander Stielau <aleks oerks.de>


--> Update: Dieser Text ist inzwischen baller alt - da ich aber in meinen
    Webstatistiken immer noch viele Treffer bekomme, bleibt dieser Text
    weiter bestehen. Aktuelleres findest Du u.U. (je nach dem, wonach Du
    gesucht hast) auch bei http://tuxmobil.org/phones_linux.html.

    2007-01-01, Aleks (Revisionsdatum bleibt; damit klar ist, WIE alt
    das hier ist)
<--


Diese Anleitung geht von grundsaetzlich vorhandenen Linux/Unix-Kenntnissen 
aus, sollte ich etwas sehr flapsig/unklar formuliert haben, lohnt sich 
eine Nachfrage.


Generell: 
=========
Es gibt sehr viel Dokumentation, das meiste ist aber leider ziemlich 
alt und teilweise ueberholt.


Die aktuellen Kernel der 2.4er und 2.6er Serie benoetigen fuer die
blueZ-Implementation (es gibt noch weitere Bluetooth-Implementationen) 
keine Patches oder aehnliches.

Doku-Sammlung:
==============
http://www.holtmann.org/linux/bluetooth/ (leider viel alter Kram dabei)

Unterstuetzte Hardware:
http://www.holtmann.org/linux/bluetooth/devices.html

Hilfreich an den einem oder anderen Punkt fuer mich waren davon:
* http://www.bluez.org (Ueberblick)
* http://www.luug-hn.org/artikel/bluetooth.html (alt, benutzt einen anderen
  	Dongle, aber der hci*-Teil ist brauchbar)
* http://www.van-schelve.de/edv-wissen/linux/bluetooth_0.htm (alt, letzter Teil
        hilfreich)
* http://www.van-schelve.de/edv-wissen/linux/bluetooth_1.htm (rfcomm erklaert)
* http://www.jochen-lillich.de/artikel/linuxbluetooth (PIN-Kram)
* http://www.teaparty.net/technotes/blue-gprs.html (GPRS via BT)
* http://www.linux-magazin.de/Artikel/ausgabe/2002/10/gprs/gprs.html
        (GPRS relativ ausfuehrlich erklaert, auch im Gegesatz zu HSCSD)
* http://www.vodafone.de/business/support_download/konfiguration/59330.htm 
  	(Vodafone GPRS Daten)l

Kernel:
=======

Ich verwende zur Zeit einen 2.4.27 (vanilla, also ohne Vendorpatches) und habe 
einfach alles unter dem Menupunkt Bluetooth als Modul angeschaltet.

-> Der Debian-Vendor-Kernel ab mindestens 2.6.8 hat alle passenden
   Module bereits eingeschaltet, das wird bei allen anderen
   Distributionen inzwischen auch so sein.

Ich gehe davon aus, das das usb-Subsystem an sich auf dem System bereits richtig 
arbeitet, und das hotplug (nicht usbmgr) verwendet wird.


Userland:
=========

Fuer die Userlandprogramme habe ich folgende Debian (SID) Packages
installiert, diese werden bei den anderen Distributionen aehnlich heissen:

ii  bluez-hcidump  1.10-1         Analyses Bluetooth HCI packets
ii  bluez-pcmcia-s 2.9-2          PCMCIA support files for BlueZ 2.0 Bluetooth
ii  bluez-pin      0.23-1         Bluetooth PIN helper with D-BUS support
ii  bluez-utils    2.9-2          Bluetooth tools and daemons

ii  libbluetooth1  2.9-1          Library to use the BlueZ Linux Bluetooth sta
ii  libbluetooth1- 2.9-1          Development files for using the BlueZ Linux 

Die letzten beiden benoetigt man, um gnocky (s.u.) zu bauen, sind also unnoetig.

-> Debian zieht bei einem 'apt-get install bluez-utils" alle notwendigen
   Abhaengigkeiten nach.

Nach der Installation von bluez-utils sollte der hcid (BT Hostcontroller
Interface Daemon) laufen:

invalid:~# ps ax|grep hcid
 2906 ?        Ss     0:00 hcid: processing events

Wenn nicht, stimmt etwas nicht mit der Konfigurationsdatei
/etc/bluetooth/hcid.conf.
Fuer erste Tests sollte diese auf jeden Fall unveraendert gelassen werden.

-> Bei Verwendung eines Nokia 6310 (ohne i) musz eine Veraenderung an der
   hcid.conf vorgenommen werden, weil es ansonsten keine Verbindung zum
   Handy gibt: class 0x100 ist durch class 0x020300 zu ersetzen.
   Der Tipp kommt von Guido, bei weiteren Fragen bitte an ihn wenden,
   Adresse folgt unten.

Einfach hcid -n starten (als r00t; -n verhindert das Loesen von der Konsole,
man kann dann besser sehen, was nicht geht).

Spaetestens beim Einsteckern sollte der hotplug-Agent den Rest erledigen, und 
die notwendigen Module ziehen (mein System macht das schon beim Starten von 
hotplug):

hci_usb
bluez
rfcomm
l2cap


Im Log steht dann sowas:
,--------
| Aug 20 10:51:17 invalid kernel: hub.c: new USB device 00:07.2-1, assigned address 3
| Aug 20 10:51:17 invalid kernel: usb.c: USB device 3 (vend/prod 0xa12/0x1) is not claimed by any active driver.
| Aug 20 10:51:20 invalid kernel: BlueZ HCI USB driver ver 2.7 Copyright (C) 2000,2001 Qualcomm Inc
| Aug 20 10:51:20 invalid kernel: Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
| Aug 20 10:51:20 invalid kernel: usb.c: registered new driver hci_usb
| Aug 20 10:51:20 invalid hcid[893]: HCI dev 0 registered
| Aug 20 10:51:20 invalid hcid[893]: HCI dev 0 up
| Aug 20 10:51:20 invalid hcid[893]: Starting security manager 0
| Aug 20 10:51:20 invalid usb.agent[1573]:      hci_usb: already loaded
| Aug 20 10:51:20 invalid usb.agent[1582]:      hci_usb: already loaded
| Aug 20 10:51:20 invalid usb.agent[1575]:      hci_usb: loaded successfully
`--------

In diesem Moment (wenns nicht geht - keine Ahnung) kann man die wunderbare, 
neue Welt des BlueZ erkunden.

Erstmal sehen, was der Dongle sagt:

,--------
| invalid:~# hciconfig -a
| hci0:   Type: USB
|         BD Address: 00:0D:88:BE:A4:7B ACL MTU: 192:8  SCO MTU: 64:8
|         UP RUNNING PSCAN ISCAN 
|         RX bytes:99 acl:0 sco:0 events:13 errors:0
|         TX bytes:296 acl:0 sco:0 commands:12 errors:0
|         Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
|         Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
|         Link policy: RSWITCH HOLD SNIFF PARK 
|         Link mode: SLAVE ACCEPT 
|         Name: 'invalid-0'
|         Class: 0x000100
|         Service Classes: Unspecified
|         Device Class: Computer, Uncategorized
|         HCI Ver: 1.1 (0x1) HCI Rev: 0x1bb LMP Ver: 1.1 (0x1) LMP Subver: 0x1bb
|         Manufacturer: Cambridge Silicon Radio (10)
`--------

Um andere Geraete zu finden, identifizieren, irgendwas mit ihnen zu
machen gibts hcitool (funktioniert auch als normaler User)

,--------
| aleks@invalid:~$ hcitool scan
| Scanning ...
| 	00:0D:93:03:63:9D	Frank Ronneburgs Computer
| 	00:0E:6D:3D:96:82	Aleks' Telefon
`--------

Da waeren also zwei Spielgefaehrten...

Man kann diese auch pingen:

,--------
| invalid:~# l2ping 00:0D:93:03:63:9D
| Ping: 00:0D:93:03:63:9D from 00:0D:88:BE:A4:7B (data size 20) ...
| 20 bytes from 00:0D:93:03:63:9D id 200 time 24.34ms
| 20 bytes from 00:0D:93:03:63:9D id 201 time 21.44ms
| 20 bytes from 00:0D:93:03:63:9D id 202 time 19.85ms
| 3 sent, 3 received, 0% loss
| invalid:~# l2ping 00:0E:6D:3D:96:82
| Ping: 00:0E:6D:3D:96:82 from 00:0D:88:BE:A4:7B (data size 20) ...
| 0 bytes from 00:0E:6D:3D:96:82 id 200 time 42.39ms
| 0 bytes from 00:0E:6D:3D:96:82 id 201 time 44.03ms
| 0 bytes from 00:0E:6D:3D:96:82 id 202 time 42.26ms
| 3 sent, 3 received, 0% loss
`--------

Oder nach DialUpNetworking suchen:

,--------
| invalid:/etc/bluetooth# sdptool search DUN
| Inquiring ...
| Searching for DUN on 00:0D:93:03:63:9D ...
| Searching for DUN on 00:0E:6D:3D:96:82 ...
| Service Name: Dial-up networking
| Service RecHandle: 0x10023
| Service Class ID List:
|   "Dialup Networking" (0x1103)
|   "Generic Networking" (0x1201)
| Protocol Descriptor List:
|   "L2CAP" (0x0100)
|   "RFCOMM" (0x0003)
|     Channel: 1
| Language Base Attr List:
|   code_ISO639: 0x656e
|   encoding:    0x6a
|   base_offset: 0x100
| Profile Descriptor List:
|   "Dialup Networking" (0x1103)
|     Version: 0x0100
|
`--------

Soweit, so gut.

Um sich mit einem anderen BT-System zu verbinden, gibts ein krasses
Security-Feature, genannt PIN.
Das ist ziemlich genau das, was man sich unter einer PIN vorstellt, eine
Nummer. Viele Telefone koennen auch wohl nur Nummern als PIN.

Das Programm, was vom hcid aufgerufen wird, um die PIN zu verwalten,
benoetigt X und ein DISPLAY fuer r00t (hcid laeuft als r00t). 
Sowas gibts im Zweifel aber eher nicht auf vernuenftig aufgesetzten 
Systemen, also macht es Sinn, dort ein wenig zu frickeln:

,--------[ /etc/bluetooth/hcid.conf ]
|         #pin_helper /usr/bin/bluez-pin;
|         pin_helper /usr/local/bin/bluepin;
`--------

,--------[ /usr/local/bin/bluepin ]
| #!/bin/bash
| cat /etc/bluetooth/pin
`--------

bluepin musz fuer root ausfuehrbar sein.

,--------[ /etc/bluetooth/pin ]
| PIN:0101
`--------

Die Pin/Verbindung wird nach der ersten erfolgreichen Verbindung binaer in 
der Datei /etc/bluetooth/link_key abgelegt.
Es mag sein, das dort auch weitere Verbindungen abgelegt werden - ich habe
hier derzeit nur eine Gegenstelle.


Verbindung aufnehmen:
=====================

Dazu wird rfcomm verwendet.
rfcomm benoetigt passende Devicefiles, bei Debian werden diese
automagisch angelegt. Ansonsten viel Spasz mit mknod...

'rfcomm bind interface BT-MAC channel' stellt eine Bindung her:

,--------
| invalid:~# rfcomm bind 0 00:0E:6D:3D:96:82 1
| invalid:~# rfcomm show
| rfcomm0: 00:0E:6D:3D:96:82 channel 1 clean 
`--------

Dieses Verhalten kann automatisiert werden, wenn man die Konfiguration
von rfcomm entsprechend anpasst:

,--------[ /etc/bluetooth/rfcomm.conf ]
|  rfcomm0 {
|   bind yes;
|         # Bluetooth address of the device
|         device 00:0E:6D:3D:96:82;
|         # RFCOMM channel for the connection
|         channel 1;
|         # Description of the connection
|         comment "Aleks Handy";
|         }
`--------

Damit wird immer bein Einsteckern des Dongles eine entsprechende
Verbindung vom BT-Stack an ein rfcomm-Interface gebunden.


Um diese Verbindung nutzen zu koennen, braucht man etwas Clientsoftware.
Zum Testen reicht erstmal cat.

Wie schon gesagt, ein 'killall hcid; hcid -n' zeigt, was schief laeuft.


Die erste Verbindung ist wegen der notwendigen Authentifizierung etwas 
zeitkritisch - wenn diese erstmal erledigt ist, braucht man sich darum 
nicht mehr zu kuemmern.

Am einfachsten geht es deshalb so:

,--------
| invalid:~# cat < /dev/rfcomm0
`--------

Dies fuehrt dazu, das das Telefon nach der PIN fragt. Diese ist auf dem
Telefon einzutippen. Der hcid meldet dazu:

,--------
| invalid:/etc/bluetooth# killall hcid
| invalid:/etc/bluetooth# hcid -n
| hcid[1840]: Bluetooth HCI daemon
| hcid[1840]: Starting security manager 0
| hcid[1840]: pin_code_request (sba=00:0D:88:BE:A4:7B, dba=00:0E:6D:3D:96:82)
| hcid[1840]: link_key_notify (sba=00:0D:88:BE:A4:7B)
| hcid[1840]: Saving link key 00:0D:88:BE:A4:7B 00:0E:6D:3D:96:82
`--------

Dann ist alles gut[tm], und das cat kann abgebrochen werden.



Anwendungen
===========

Gnokki <http://www.gnokii.org>
------------------------------
Kann SMSses versenden, editieren, Adressbuch auslesen, editieren und
noch einen Arsch voll andere sinnlose Dinge tun.

Damit dies auch per USB geht, sind ein paar kleine Aenderungen an der
~/.gnokiirc notwendig:

,--------
| port = /dev/rfcomm0
| modell = AT
| connection = serial
`--------
Die in der gnokii-Doku vorgeschlagenen Einstellungen modell = 6510, 
connection = bluetooth, port = BT-MAC tun bei mir nicht.

Deutlich hypscher ist Gnocky <ftp://ftp.gnokii.org/pub/gnocky/>, musz
aber selbst gebaut werden (dafuer sind neben der ueblichen Entwicklungstoolchain
mit gcc und make die o.g. Bibliotheken notwendig (Devel-Version!).


minicom als Terminalprogramm
----------------------------
Als serieller Port wird entsprechend /dev/rfcomm0 eingetragen.

,--------
| atz
| OK
| ati
| Nokia
|
| OK
| ati1
| 352952007122910
|
| OK
| ati2
| V 5.52     
| 13-04-04
| NPL-1
| (c) NMP.  
|
| OK
| ati3
| Nokia 6310i
|
| OK
| ati4
| 2002_wk38
|
| OK
| atdt01723865865
| BUSY
| atz
| OK
`--------

Damit ist auch sicher, das ich gerade auf meinem Telefon bin, und nicht
auf dem Apple meines Kollegen.

Nun musz man wohl rausfinden, wie die AT-Inits des eigenen
Telefonieproviders sind.

google sagt:
at+cgdcont=1,"IP","web.vodafone.de","",0,0

,--------
| ATZ                                                           
| OK                                                            
| at+cgdcont=1,"IP","web.vodafone.de","",0,0                    
| OK                                                            
| atd*99#
| CONNECT
| ~ÿ}#.!}!} } }2}#}$.#}!}$}%Ü}"}&} }*} } g}%~~ÿ}#.!}!} }
| }2}#}$.#}!}$}%Ü}"}&} }*} } g}%~~ÿ}#.!}!} } ~
`--------

Sieht ja schon nicht schlecht aus, sondern fast schon wie ppp am anderen
Ende...

Nun noch das umsetzen, damit auch lokal der pppd verwendet wird...

Die nachfolgenden Dateien liegen je nach Distribution etwas anders.

Chatscript:

,--------[ /etc/chatscripts/gprs ]
| # Gebastelt von 
| # http://www.teaparty.net/technotes/blue-gprs.html
| # http://www.linux-magazin.de/Artikel/ausgabe/2002/10/gprs/gprs.html
| # fuer die Verwendung mit vodafone
|
| TIMEOUT         5
| 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              ATE1
| OK              'AT+CGDCONT=1,"IP","web.vodafone.de","",0,0'
| OK              ATD*99***1#
| CONNECT ""
`--------

pppd-Optionen:

,--------[ /etc/ppp/peers/gprs ]
| # Gebastelt von 
| # http://www.teaparty.net/technotes/blue-gprs.html
| # http://www.linux-magazin.de/Artikel/ausgabe/2002/10/gprs/gprs.html
| # fuer die Verwendung mit vodafone
| /dev/rfcomm0 57600
| connect '/usr/sbin/chat -v -f /etc/chatscripts/gprs'
| noauth
| defaultroute
| debug
|
| noipdefault
| local
| ipcp-accept-local
| novj
| novjccomp
| lcp-echo-failure 10000
| lcp-echo-interval 1000
`--------

Das debug kann raus, wenn es tut, ueber die anderen Optionen bin ich mir 
noch nicht im Detail klar, aber so geht es zumindest:

Auf 'pon gprs' sagt das Log:

,--------
| hcid[2433]: Bluetooth HCI daemon
| hcid[2433]: Starting security manager 0
| pppd[2498]: pppd 2.4.2 started by root, uid 0
| hcid[2433]: link_key_request (sba=00:0D:88:BE:A4:7B, dba=00:0E:6D:3D:96:82) 
| chat[2499]: timeout set to 5 seconds
| chat[2499]: abort on (\nBUSY\r)
| chat[2499]: abort on (\nERROR\r)
| chat[2499]: abort on (\nNO ANSWER\r)
| chat[2499]: abort on (\nNO CARRIER\r)
| chat[2499]: abort on (\nNO DIALTONE\r)
| chat[2499]: abort on (\nRINGING\r\n\r\nRINGING\r)
| chat[2499]: send (^MAT^M)
| chat[2499]: timeout set to 12 seconds
| chat[2499]: expect (OK)
| chat[2499]: ^MAT^M^M
| chat[2499]: OK
| chat[2499]:  -- got it 
| chat[2499]: send (ATE1^M)
| chat[2499]: expect (OK)
| chat[2499]: ^M
| chat[2499]: ATE1^M^M
| chat[2499]: OK
| chat[2499]:  -- got it 
| chat[2499]: send (AT+CGDCONT=1,"IP","web.vodafone.de","",0,0^M)
| chat[2499]: expect (OK)
| chat[2499]: ^M
| chat[2499]: AT+CGDCONT=1,"IP","web.vodafone.de","",0,0^M^M
| chat[2499]: OK
| chat[2499]:  -- got it 
| chat[2499]: send (ATD*99***1#^M)
| chat[2499]: expect (CONNECT)
| chat[2499]: ^M
| chat[2499]: ATD*99***1#^M^M
| chat[2499]: CONNECT
| chat[2499]:  -- got it 
| chat[2499]: send (^M)
| pppd[2498]: Serial connection established.
| pppd[2498]: using channel 2
| pppd[2498]: Using interface ppp0
| pppd[2498]: Connect: ppp0 <--> /dev/rfcomm0
| pppd[2498]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xd38de9b3> <pcomp> <accomp>]
| pppd[2498]: rcvd [LCP ConfRej id=0x1 <magic 0xd38de9b3> <pcomp> <accomp>]
| pppd[2498]: sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
| pppd[2498]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
| pppd[2498]: rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
| pppd[2498]: sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
| pppd[2498]: sent [LCP EchoReq id=0x0 magic=0x0]
| pppd[2498]: sent [PAP AuthReq id=0x1 user="invalid" password=<hidden>]
| pppd[2498]: rcvd [LCP EchoRep id=0x0 00]
| pppd[2498]: lcp: received short Echo-Reply, length 1
| pppd[2498]: rcvd [PAP AuthAck id=0x1 ""]
| pppd[2498]: PAP authentication succeeded
| pppd[2498]: kernel does not support PPP filtering
| pppd[2498]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
| pppd[2498]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
| pppd[2498]: rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
| pppd[2498]: sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
| pppd[2498]: rcvd [LCP ProtRej id=0x0 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
| pppd[2498]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
| pppd[2498]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
| pppd[2498]: rcvd [IPCP ConfNak id=0x1 <addr 10.226.63.147>]
| pppd[2498]: sent [IPCP ConfReq id=0x2 <addr 10.226.63.147>]
| pppd[2498]: rcvd [IPCP ConfAck id=0x2 <addr 10.226.63.147>]
| pppd[2498]: Cannot determine ethernet address for proxy ARP
| pppd[2498]: local  IP address 10.226.63.147
| pppd[2498]: remote IP address 10.6.6.6
| pppd[2498]: Script /etc/ppp/ip-up started (pid 2508)
`--------

Und surfen krasst voll ab.

Naja - es ist nicht gerade schnell und erheblich teuer, aber fuer 
ssh-Verbindungen ist es wirklich guenstig, ircen z.B. kostet auf Grund der 
geringen zu uebertragenen Datenmengen fast nix, ebenso surfen mit einem remote
laufenden Textbrowser wie elinks.
Man musz sich daran gewoehnen, langsam zu arbeiten: Die Zeit kostet nix, und man
macht weniger Fehler :-)
Hier setzt dann die sogenannte grosze Guckes'sche Toolchain (screen, vim, mutt, 
slrn, elinks) voll ein.


Und wie geht das mit Mac OSX?
=============================

Das steht hier:
http://faq.de-soc-mac.de/vernetzung/gprs_ueber_bluetooth.shtml
Stimmt aber nicht ganz, statt der " musz man \34 verwenden, sonst wird
das AT-Kommando am ersten " fuer beendet erklaert.

Siehe auch:
http://groups-beta.google.com/group/de.comp.sys.mac.internet/msg/a22c73ca3a38ce6e?dmode=source
und folgende.



TODO:
=====

* Rausfinden, welchen Tarif man will. GPRS-by-Call macht mich arm.
* tbc

HEROES:
=======
Guido Ackermann <ga phantomg.de>
	* Tipp mit dem Nokia 6310
	* Hinweis auf Debian-Vendor-Kernel 
	* Hinweis auf autmatische Abhaengigkeiten beim Installieren von
	  bluez-utils unter Debian