Bluetooth

Bluetooth

Summary

Insert device and issue /etc/init.d/bluez-utils start (soon /etc/init.d/bluetooth start)
The bluetooth USB dongles work fine, even without the cables (designed to lower interference) and even through double concrete walls -- they are far more powerful than most bluetooth devices

Overview

Introduction

Software and guides
Commands
Terminology

Setting up

Kernel components
Diagnostics
The hcid configuration file

Tasks

Accessing files on the phone
Copying files to a phone
Host-to-host
GPRS
Radio frequency communication
Shared internet

Installation history

testing host-to-host
testing RFCOMM
testing GPRS

Software and guides

Bluez -- Linux bluetooth protocol, in the kernel (but not always up to date)

protocols

bluez-pin (needed for connecting to other bluetooth devices)
bluez-utils

libbluetooth1

bluez-cups (not installed)
bluez-hcidump (debugging)

kdebluetooth -- Debian and Ubuntu

kaddressbook

gnokii

libgnokii2

gnokii-smsd

multisync

libmultisync-plugin-irmc-bluetooth (installed)

libmultisync-plugin-all

libmultisync-plugin-backup (installed)

libmultisync-plugin-opie

and others

scmxx (for Siemens phones)

Obex

kio slave -- instructions and screenshots
openobex-apps
obexftp
ussp-push (an OBEX push client)
qobex
obexserver

Documentation hubs

Configuration files and instructions

/etc/bluetooth/hcid.conf
Host-to-host Bluetooth (this is the one to use)
HOWTO Setup Common PAN Scenarios with BlueZ

HOWTO Linux iptables

Bluetooth accesspoint with Debian GNU/Linux (good)
Installing Bluetooth (dated guide -- pre-2.6)
GPRS over bluetooth (guide)
Using your cell phone as a remote

Detectors

btscanner

Integrators

KDE bluetooth

Devices (those with HCI work with Linux)

Linksys Bluetooth USB adapter, USBBT100

Scripts

/usr/local/bin/blue-client, blue-off, blue-phone, blue-serve
spello:/mnt/vh/Tord/konfigurasjonsfiler/scripts (for Tord's sokrates)

Commands

pand --listen --role NAP --master --autozap (on the server)
pand --connect 00:0C:41:E2:7B:DF --service NAP --autozap (on the clients)
sigillo # ifconfig bnep0 192.168.2.1
gubbio # ifconfig bnep0 192.168.2.2

Cell phone

/etc/init.d/bluez-utils start (soon /etc/init.d/bluetooth start)
hcitool scan

enter bdaddr in /etc/bluetooth/rfcomm.conf
/etc/init.d/bluez-utils restart (you should get a receipt)
just restart bluez-utils (when changed)

sdptool search --bdaddr <phone bt addr> DUN

check which channel should be used (likely 1)

rfcomm bind 0 <phone bt addr> <channel>
rm /etc/modem && ln -s /dev/rfcomm0 /dev/modem
kppp

Diagnostics

hciconfig -a (check if you have bluetooth running)
hciconfig hci0 up (bring it up if you don't)
cat /proc/bus/usb/devices | grep -e^[TPD] | grep -e Cls=e0 -B1 -A1 (identify the hardware)
hcitool dev -- examine the address of a Bluetooth dongle
hcitool info <bt addr> -- show remote device
hcitool inq -- ask one dongle to look for another
hciconfig -- to display the hci0 network device,
ifconfig bnep0 -- display the state of the IP network device

Start the daemon

just start bluez-utils

/etc/init.d/bluez-utils start (soon /etc/init.d/bluetooth start)

ps -ae | grep hcid
ifconfig -a

Konqueror's kio slaves

fish://gra/usr/share/doc/bluez-utils/NEWS.Debian.gz (works great -- which means any KDE app)
sdp://gravettien/ (connects, but it's not clear what it finds)

sdp://[00:10:c6:63:9a:b4]/params?name=Gravettien
it sees, or imagines seeing, "Network access point", "Public Browse Group Root", and "SDP Server", but they don't have any content and may just be signs that the sdp browsing service hasn't been set up on Sokrates -- that there could be an SDP server that serves web pages!

bluetooth:// (doesn't work in KDE 3.3 for some reason)

Terminology

PAN -- Personal Area Network

pand -- PAN daemon, from the bluez-utils package
PAN uses the BNEP protocol

BNEP -- Bluetooth Network Encapsulation Protocol
NAP -- Network Access Point
GN -- Group ad-hoc Network

Kernel components

For PAN (host-to-host) or mobile phone:

Device Drivers  --->
  Networking Support  --->
    <*> Bluetooth subsystem support  --->
        <*> L2CAP protocol support
        <*> SCO links support
        <*> RFCOMM protocol support
            [*] RFCOMM TTY support
        <*> BNEP protocol support
            [*] Multicast filter support
            [*] Protocol filter support
              Bluetooth device drivers  --->
                <*> HCI USB driver
                    [*] SCO (voice) support
USB support  --->
   <*> Support for Host-side USB
   --- USB Host Controller Drivers
   <M> EHCI HCD (USB 2.0) support
   <M> OHCI HCD support
   <*> UHCI HCD (most Intel and VIA) support
   --- USB Device Class drivers
   <*> USB Audio support

For your mobile phone:

Doesn't look like you need anything else.

For the shared internet connection, you also need bridge support, which may require both of these:

Device drivers | Networking support | Networking options | Network packet filtering | Bridged IP/ARP packets filtering

CONFIG_BRIDGE_NETFILTER
Device drivers | Networking support | Networking options | 802.1d Ethernet Bridging

CONFIG_BRIDGE

Diagnostics

dmesg on insertion of my new Linksys Bluetooth USB adapter, the USBBT100:

usb 2-1: new full speed USB device using uhci_hcd and address 5
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.8
usbcore: registered new driver hci_usb

Hardware listed in proc for sigillo:

cat /proc/bus/usb/devices | grep -e^[TPD] | grep -e Cls=e0 -B1 -A1

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0a12 ProdID=0001 Rev= 5.25

Check the port (this is sigillo):

$ /usr/sbin/hciconfig -a
hci0:   Type: USB
        BD Address: 00:0C:41:E2:7B:DE ACL MTU: 192:8 SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN
        RX bytes:193 acl:0 sco:0 events:27 errors:0
        TX bytes:842 acl:0 sco:0 commands:24 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: 'Aurignacien'
        Class: 0x3e0100
        Service Classes: Networking, Rendering, Capturing
        Device Class: Computer, Uncategorized
        HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x20d
        Manufacturer: Cambridge Silicon Radio (10)

hci0:   Type: USB
        BD Address: 00:0C:41:E2:7B:DF ACL MTU: 192:8 SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN
        RX bytes:163 acl:0 sco:0 events:22 errors:0
        TX bytes:575 acl:0 sco:0 commands:19 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: 'Gravettien'
        Class: 0x000100
        Service Classes: Unspecified
        Device Class: Computer, Uncategorized
        HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x20d
        Manufacturer: Cambridge Silicon Radio (10)

Bluetooth addresses:

$ hcitool dev

Sigillo: hci0 00:0C:41:E2:7B:DE
Gubbio: hci0 00:0C:41:E2:7B:DF

Then ask one to look for the other:

gubbio:/etc/network# hcitool inq
Inquiring ...
00:0C:41:E2:7B:DE clock offset: 0x5bc5 class: 0x3e0100

Gubbio sees Sigillo! And the other way:

sigillo:/usr/src/linux# hcitool inq
Inquiring ...
00:0C:41:E2:7B:DF clock offset: 0x2439 class: 0x000100

I take it class is wrong -- after all, it's the exact same device.

Again, scanning from Sigillo:

# hcitool scan
Scanning ...
00:0C:41:E2:7B:DF Gravettien

And from Gubbio:

# hcitool scan
Scanning ...
00:0C:41:E2:7B:DE Aurignacien

Show remote device (from sigillo, showing gubbio):

# hcitool info 00:0C:41:E2:7B:DF
Requesting information ...
        BD Address: 00:0C:41:E2:7B:DF
        Device Name: Gravettien
        LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
        Manufacturer: Cambridge Silicon Radio (10)
        Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
                <3-slot packets> <5-slot packets> <encryption> <slot offset>
                <timing accuracy> <role switch> <hold mode> <sniff mode>
                <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
                <HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
                <power control> <transparent SCO>

Check out the socket (if that's the word):

# hciconfig
hci0:   Type: USB
        BD Address: 00:0C:41:E2:7B:DE ACL MTU: 192:8 SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN
        RX bytes:163 acl:0 sco:0 events:22 errors:0
        TX bytes:575 acl:0 sco:0 commands:19 errors:0

Did the daemons start?

# just restart bluez-utils

Restarting bluez-utils: hcid sdpd rfcomm.

# ps -ae | grep hcid

7597 ? 00:00:00 hcid

Try pinging from Gubbio:

# l2ping 00:0C:41:E2:7B:DE
Ping: 00:0C:41:E2:7B:DE from 00:0C:41:E2:7B:DF (data size 20) ...
20 bytes from 00:0C:41:E2:7B:DE id 200 time 95.47ms
20 bytes from 00:0C:41:E2:7B:DE id 201 time 38.91ms
20 bytes from 00:0C:41:E2:7B:DE id 202 time 46.90ms
20 bytes from 00:0C:41:E2:7B:DE id 203 time 27.88ms
4 sent, 4 received, 0% loss

From Sigillo:

# l2ping 00:0C:41:E2:7B:DF
Ping: 00:0C:41:E2:7B:DF from 00:0C:41:E2:7B:DE (data size 20) ...
20 bytes from 00:0C:41:E2:7B:DF id 0 time 99.87ms
20 bytes from 00:0C:41:E2:7B:DF id 1 time 38.65ms
20 bytes from 00:0C:41:E2:7B:DF id 2 time 42.76ms
20 bytes from 00:0C:41:E2:7B:DF id 3 time 36.88ms
4 sent, 4 received, 0% loss

Wow. That's all with zero configuration really -- I mean, no network stuff, just a name change (which doesn't matter anyway).

The hcid configuration file

The name and other parameters of your Bluetooth device are set in

/etc/bluetooth/hcid.conf

To customize the name, change the line

name "%h-%d";

to something else, such as this one for sigillo,

name "Aurignacien";

Change the Local device class to

class 0x300100;

according to advice given by the kdebluetooth program.

You can also define kdebluetooth's pin helper program here:

# PIN helper #pin_helper /usr/bin/bluez-pin; pin_helper /usr/lib/kdebluetooth/kbluepin;

Revert if this causes problems. In fact, I have to use the /etc/bluetooth/bluepin script to get sigillo to pair with the mobile; see details.

Then set up a PIN access code to your system -- use the same number for all devices. For example,

$ echo "1234" > /etc/bluetooth/pin
$ chmod 600 /etc/bluetooth/pin

Then restart the bluetooth service to re-confirm name and pin changes

$ just restart bluez-utils

Check syslog for errors.

Copying files to and from the phone

Copying files to and from the phone can be done with the obex kio-slave. The kbluetoothd needs to be running; then start konqueror and enter

bluetooth:/

Select the telephone and then OBEX File Server; it should connect automatically as the devices have been paired. For detailed installation history and brick wall see below -- this fails because of a firmware bug.

Copying files to the phone

First establish a connection between the phone and the pc:

On the phone, go to Connect in the main menu

turn on bluetooth
authorize the connection between your computer and the phone

On the pc, load the modules and turn on bluez-utils

verify the connection with hcitool info 00:60:57:4D:FD:1F

To copy files, you need the KDE (or other) OBEX client -- kbtobexclient

Madgalenian -- OBEX Object Push should appear in the left panel
Drag files from the to "Files to send" and click on send
Confirm on the phone you want to receive the files

To install files, just click on the message

Install to the memory card

Ogg files should be mono at 16,000 sampling rate

This is fast and easy.

You can also copy files to the memory card by mounting it in the card reader

issue sync before issuing umount
it's not clear it's that much faster -- the card seems to be slow

Setting up a PAN (host-to-host personal area network)

This is how to set up a PAN for a host-to-host connection using NAP (Network Access Point) -- cf. details.

On the server, issue

# pand --listen --role NAP --master --autozap

On the client, issue

# pand --connect 00:0C:41:E2:7B:DF --service NAP --autozap

The bnep0 device nodes get created the moment a connection is made.

Verify the connection from both sides:

# ifconfig -a

Assign IP addresses:

sigillo # ifconfig bnep0 192.168.2.1
gubbio # ifconfig bnep0 192.168.2.2

Verify the addresses from both sides:

# ifconfig

Add these lines to /etc/hosts on both systems:

# Bluetooth
192.168.2.1 Gravettien
192.168.2.2 Aurignacien

Test the connection:

gubbio # ping Aurignacien
sigillo # ping Gravettien

Log on to the remote machine over the bluetooth network:

sigillo # ssh Gravettien

Setting up an internet connection using GPRS on a cell phone (source)

This is a messy description that can be vastly improved on -- see for example GPRS over bluetooth., and the RFCOMM testing below.

Short version:

hcitool scan
sdptool search --bdaddr <phone bd addr> DUN

sdptool search --bdaddr 00:02:EE:60:97:6E DUN

rfcomm bind 0 <phone bt addr> <channel>
ln -s /dev/rfcomm0 /dev/modem
kppp

Long version:

activate bluetooth on the cell phone
Bluetooth->Bluetooth settings->My phone's name

On the laptop, scan to find the bluetooth address:

# hcitool scan
Scanning ...
        00:02:EE:60:97:6E       My phone

Probe for the dial-up networking device using this address:

# sdptool search --bdaddr 00:02:EE:60:97:6E DUN
Inquiring ...
Searching for DUN on 00:02:EE:60:97:6E ...
Service Name: Dial-up networking
Service RecHandle: 0x10031
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

l2ping the phone to verify connectivity

# l2ping 00:0C:41:E2:7B:DF
Ping: 00:0C:41:E2:7B:DF from 00:0C:41:E2:7B:DE (data size 20) ...
20 bytes from 00:0C:41:E2:7B:DF id 0 time 45.59ms
20 bytes from 00:0C:41:E2:7B:DF id 1 time 33.70ms
20 bytes from 00:0C:41:E2:7B:DF id 2 time 33.81ms

bind from the laptop to the phone's onboard modem:

# rfcomm bind 0 00:0C:41:E2:7B:DF 1

and verify:

# rfcomm show rfcomm0: 00:0C:41:E2:7B:DE channel 1 clean

The device node /dev/rfcomm0 is automatically created, but if not do this:

mknod /dev/rfcomm0 c 216 0

pair the devices:

cat /dev/rfcomm0

You'll be prompted for the pin -- type it in if you need to (the following automatic setup should work)

Set up an automatic pin response in /etc/bluetooth/hcid.conf:

# HCId options
options {
...
        # PIN helper
        pin_helper /etc/bluetooth/bluepin;
}

and the number itself in /etc/bluetooth/bluepin:

#!/bin/bash
echo "PIN:00"      ## 00 is the PIN you typed in

Make it executable:

chmod 755 /etc/bluetooth/bluepin

Verify it's working:

on the phone:

Look for a message about GPRS service being available or not
in syslog:

Jan  5 19:51:30 tirith hcid[20134]: Saving link key 00:04:76:C8:D3:E3 00:02:EE:60:97:6E

with minicom /dev/rfcomm0 (don't bother):

you should be able to talk to the onboard modem and get simple AT-OK responses:ATDT<sample phone number>

see if you can make a phone ring, and test the phone's modem (cf. commands):
at
OK
ate1
OK
at+cgdcont=1,"IP","orange.co.uk","",0,0
OK
atd*99***1#
NO CARRIER

Configuring the dialup

To use kppp, make a symlink:

rm -rf /dev/modem ln -s /dev/rfcomm0 /dev/modem

Use kppp, click on setup and device and make sure it is pointed at /dev/modem. I had to make sure control line termination is CR/LF for it to work.

To use wvdial

## BT->S55 GPRS Connection
[Dialer GPRS]
Modem=/dev/rfcomm0
Init1 = AT+CGDCONT=1,"IP","web";^sgauth=1;+CGQREQ=1,3,4,3,1,31
Phone = *99***1#
Dial command = ATD
#Stupid mode = 0
Auto Reconnect = off
Username = web@telering.at
Password = web

To use ppp, set up /etc/ppp/gprs:

/dev/rfcomm0 57600 
connect '/usr/sbin/chat -v -f /etc/ppp/chat-gprs'
noauth
defaultroute
debug

try this chat script (/etc/ppp/chat-gprs):

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","orangeinternet"'
OK              ATD*99***1#

Note the lack of authentication -- it seems that the phone itself is authenticated by the network. To make a connection, I use

rfcomm release 0; rfcomm bind 0 00:02:EE:60:97:6E 1

then type

pppd call gprs

The phone immediately wants to confirm a Bluetooth connection from my laptop, which I permit.

Others reports good results with the following script:

OK 'AT&F' OK 'ATV1E0S0=0&D2&C1' OK AT+CMEE=1 OK 'AT+cgdcont=10,"IP","orangeinternet"' OK-AT-OK ATD*99***10# CONNECT ""

After a short delay, pppd logs the following to syslog:

pppd[22167]: Serial connection established.
pppd[22167]: Using interface ppp0
pppd[22167]: Connect: ppp0 <--> /dev/rfcomm0
[...]
pppd[22167]: local  IP address 172.23.201.2
pppd[22167]: remote IP address 10.6.6.6

a small G appears at the top left-hand corner of the phone display, which I understand shows that a GPRS conection has been made, and I can route to the outside world. My provider seems to be filtering pings, but I can (for example) make a TCP connection to port 22 on an ssh server I use, and I can use DNS to resolve off my favourite server outside, so I conclude that it works.

For anyone who's curious about numbers, I am on orange's cheapest plan, which is GBP4 (about 6 Euros) a month for 0.5MB. orange say (7.1.2003) that traffic over the plan limit is charged by the kB, pro rata the main plan rate. We'll see how much traffic I use: my main usage is ssh, which isn't all that big; 0.5MB would vanish in a heartbeat with web browsing, though.

Automate the connection (source):


#!/usr/bin/perl -w

use strict;

## your mobile phone MAC
my $MAC = '00:01:E3:00:00:00';


##############################
my $check;
my $rmmod     = '/sbin/rmmod';
my $hciconfig = '/usr/sbin/hciconfig';
my $rfcomm    = '/usr/bin/rfcomm';
my $hcid      = '/usr/sbin/hcid -f /etc/bluetooth/hcid.conf';
my $pppd      = '/usr/sbin/pppd';
my $killall   = '/bin/killall';

print "Starting hotplug serveice: /etc/rc.d/rc.hotplug start\n";
$check = `/etc/rc.d/rc.hotplug start &`;

print "Turn on your bluetooth device and press Enter\n"; 
<>;

print "Starting hci0: $hciconfig hci0 up\n";
$check = `$hciconfig hci0 up`;
print $check;

print "Releasing device hci0 ($MAC): $rfcomm release $MAC\n";
$check = `$rfcomm release $MAC`;
print $check;

print "Binding device hci0 ($MAC): $rfcomm  bind 0 $MAC 1\n";
$check = `$rfcomm bind 0 $MAC 1`;
print $check;

print "Starting HCI daemon: $hcid\n";
$check = `$killall hcid; $hcid`;
print $check;

print "Running wvdial: /usr/bin/wvdial GPRS\n";
$check = `/usr/bin/wvdial GPRS`;

Run this perl script to connect to your GPRS provider and ifconfig -a to see the ppp0 connection.

Setting up an internet sharing network

To allow connected bluetooth devices to share a common internet connection, you need a bridge. Here are Fedora instructions or Debian instructions (they're quite different):

A working bridge utility. Refer to the respective HOWTO for instructions, or see bridge-utils. Check that you have the bridge utility:
```
$ /usr/sbin/brctl
```
if not then issue

$ just install bridge-utils

iptables has to be installed and loaded. Do the following the check that it is installed.
```
$ /sbin/iptables -V
$ /sbin/lsmod | grep ip_tables  (or modprobe -v ip_tables)
```

You have to create a bnep0 configuration file on the server side. Here is what to do in /etc/network/ifcfg-bnep0

DEVICE=bnep0
ONBOOT=no
BOOTPROTO=DHCP

On the Server Side Do:

$ /usr/sbin/brctl addbr pan0
$ /sbin/ifconfig pan0 10.0.0.1
$ /usr/sbin/brctl setfd pan0 0
$ /usr/sbin/brctl stp pan0 disable
$ /sbin/modprobe bnep
$ pand -s -M --role=NAP

On the Client Side Do:

$ /sbin/modprobe bnep
$ pand -c 00:10:EC:71:F9:D6
$ /sbin/ifconfig bnep0 10.0.0.2 netmask 255.255.255.0
$ /sbin/route add default gw 10.0.0.1

On the Server Side Do:

$ /usr/sbin/brctl addif pan0 bnep0
$ /sbin/ifconfig bnep0 0.0.0.0

enable IP forwarding on the Server Side

$ echo "1" > /proc/sys/net/ipv4/ip_forward
$ /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$ /sbin/iptables -A FORWARD -i pan0 -j ACCEPT
$ /sbin/iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

For Internet Sharing on Server Side do:

$ /sbin/iptables -t nat -A POSTROUTING -j MASQUERADE

Save your iptables setting so you don't have to re-do them again

$ /sbin/iptables-save

In addition, I also allow DHCP and DNS on the Server for total enjoyment. I have given my server and client both ethernet and bluetooth names. Bluetooth speed in sufficient for surfing the net but not for copying huge files for example. Here is a listing of what I got in my /etc/hosts file:

192.168.0.1     server.home.net server    localhost.localdomain   localhost
192.168.0.2     laptop.home.net	laptop
10.0.0.1        btserver.home.net btserver
10.0.0.2        btclient.home.net btserver

Add the lines below to your /etc/named.conf . Note that you have to change ip_isp_dns1 and ip_isp_dns2 to your service provider DNS IP addresses. I use a dial-up connection to go online and this way, allows me to do DNS caching on my server side. Hence, it lowers DNS traffic from my side to my ISP.

forwarders { ip_isp_dns1; ip_isp_dns2; 192.168.0.1 };
allow-query { 192.168.0.0/24; 127.0.0.1/32; 10.0.0.2; 10.0.0.1 };

However, for DHCP, I have only allowed it for ethernet. This is what I have in my /etc/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name "home.net";
ddns-update-style ad-hoc;
option netbios-name-servers 192.168.0.1;
option netbios-dd-server 192.168.0.1;
option netbios-node-type 8;
option netbios-scope "";
 
subnet 192.168.0.0 netmask 255.255.255.0 {
   range 192.168.0.2 192.168.0.254;
}

You could do the same thing for your bluetooth network by creating another subnet. Check the output below to see how different it is when I ping over ethernet and bluetooth from the client side

$ ping -c 2 btserver
PING btserver.home.net (10.0.0.1) 56(84) bytes of data.
64 bytes from btserver.home.net (10.0.0.1): icmp_seq=0 ttl=64 time=36.3 ms
64 bytes from btserver.home.net (10.0.0.1): icmp_seq=1 ttl=64 time=23.9 ms
 
--- btserver.home.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 23.962/30.170/36.378/6.208 ms, pipe 2

$ ping -c 2 server
PING server.home.net (192.168.0.1) 56(84) bytes of data.
64 bytes from server.home.net (192.168.0.1): icmp_seq=0 ttl=64 time=0.236 ms
64 bytes from server.home.net (192.168.0.1): icmp_seq=1 ttl=64 time=0.269 ms
 
--- server.home.net ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1007ms
rtt min/avg/max/mdev = 0.236/0.252/0.269/0.022 ms, pipe 2

Setting up radio frequency communication (RFCOMM)

You can also use rfcomm to establish a connection to other bluetooth devices. Firstly we will have to edit /etc/bluetooth/rfcomm.conf.

NOTE: This part is not necessary unless you want to use radio frequency. If you want to set up a Personal Area Network, you can just skip this. See also my successful test of RFCOMM below.

rfcomm0 { # # RFCOMM configuration file. # # $Id: rfcomm.conf,v 1.1 2002/10/07 05:58:18 maxk Exp $ # # Automatically bind the device at startup bind yes; # Bluetooth address of the device device00:0C:41:E2:7B:DE; # RFCOMM channel for the connection channel 1; # Description of the connection comment "RFCOMM from Sigillo"; }

That will set up the radio frequency communications of our bluetooth device. After that, we can connect to any device using something like the following:

# hcitool inq Inquiring ... 00:10:60:A3:CB:41 clock offset: 0x5579 class: 0x72010c # rfcomm connect hci0 00:0C:41:E2:7B:DE 1

The first parameter after the connect command is the local device that will be used.
The second parameter is the MAC address of the remote device.
The third parameter is optional and specifies the channel to be used.

Please, note that in order to connect to a device, that device must be listening for incomming connections. In order to do that, we have to explicitly tell it to listen. We can cancel the communication at any moment by just hitting CTRL + C.

# rfcomm listen hci0 1 Waiting for connection on channel 1

In a similar way to the connect command, the listen command can receive two parameters. The first one explicits the local device that will be used to accept a connection, while the second is the channel that will be used.

Installation history

19 November 2005: OBEX file server

In KControl, under Internet & Network, I selected Bluetooth Services | Device Discovery. Under Job Settings, click Add Device. If the name is wrong, exit KDE first and edit the aliases manually:

pico ~/.kde/share/config/kbluetoothdrc

Here are the current values in the cache:

First dongle
00:0C:41:E2:7B:DE_name=Gravettien
Second dongle
00:0C:41:E2:7B:DF_name=Gravettien

Whichever of the two dongles is connected to Sigillo is seen by others as Aurignacien.

Tord's phone?
00:10:C6:63:9A:B4_name=Solutrean
My phone
00:60:57:4D:FD:1F_name=Magdalenien

I issue

kbluetoothd

which gives you a K bluetooth icon in the system tray -- default from now on. Right-click to see menu, including "Connection history".

Now start konqueror and enter this in the address field:

bluetooth:/

You should see "localhost" and "Magdalenian" -- the latter a phone icon. Rightclick on either and open in a new tab -- you'll see

sdp://localhost

with "Obex Push Server", "kBtSerialChat", and "KDE Bemused Server". For the phone, you'll see

sdp://magdalenien/

with "OBEX File Transfer", "OBEX Object Push", "Bluetooth Serial Port", "Dial-Up Networking", "Fax", "Handsfree Audio Gateway", and "IPHCore".

Sidebar: A command-line client does the same thing --

# kioclient ls bluetooth:/
localhost
00:60:57:4D:FD:1F
# kioclient ls "sdp://localhost"
Obex Push Server
KBtSerialChat
KDE Bemused Server
.More Services

Note the brackets needed around the MAC address:

# kioclient ls "sdp://[00:60:57:4D:FD:1F]"
Fax
Dial-up Networking
OBEX File Transfer
Bluetooth Serial Port
IPHCore
OBEX Object Push
Handsfree Audio Gateway
.More Services

This one may be the right syntax, but it fails to connect:

# kioclient ls "obex://[00:60:57:4d:fd:1f]:12/"
Could not connect to host 00:60:57:4d:fd:1f.

Click on "OBEX File Transfer" -- that's the OBEX ftp client:

obex://[00:60:57:4d:fd:1f]:10/

This is where I had trouble -- the first time, the phone asked for a passcode; the second time, it asked thrice if you wanted to received a message, and answering yes resulted in the OBEX ftp client complaining the connection failed.

Second problem: pairing initiated by the phone fails. On the phone, under the Main Menu, select Connect | Bluetooth. Right arrow opens "Paired devices" -- find Aurignacian and pair. The passcode must be keyed the first time. However, it fails.

I then changed /etc/bluetooth/hcid.conf to use

pin_helper /etc/bluetooth/bluepin;

which is the file

#!/bin/bash
echo "PIN:xxxxxx"

and I got this:

# tail -f /var/log/syslog

Nov 19 13:26:04 sigillo hcid[16395]: Bluetooth HCI daemon
Nov 19 13:26:04 sigillo sdpd[16397]: Bluetooth SDP daemon
Nov 19 13:26:04 sigillo hcid[16395]: Starting security manager 0
Nov 19 13:26:30 sigillo hcid[16395]: pin_code_request (sba=00:0C:41:E2:7B:DE, dba=00:60:57:4D:FD:1F)
Nov 19 13:26:31 sigillo hcid[16395]: link_key_notify (sba=00:0C:41:E2:7B:DE, dba=00:60:57:4D:FD:1F)

On the phone, I confirmed the pairing and set it to authorized, so that it will happen automatically. This should work, and it looks like the OBEX client now connects, but it doesn't find any directories -- there's a firmware bug:

The NOKIA 3650 mobile has a firmware bug in some versions. Mobiles with this bug return invalid XML files for folder listings. This leads to empty directories. Thie bug is reported to be in at least firmware version 2.50. The firmware version 3.16 fixed this bug.

It looks like I need a firmware upgrade to get this to work -- and it's not clear anyone in LA can do it!

On 20 June 2005: testing the dongle

I tested my new Linksys Bluetooth USB adapter, the USBBT100. Plugging it in got me this:

usb 2-1: new full speed USB device using uhci_hcd and address 5
Bluetooth: Core ver 2.7
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: HCI USB driver ver 2.8
usbcore: registered new driver hci_usb

So it's detected, USB2.0, using the HCI socket layer. The Bluez site shows several recent updates.

Debian has a kernel patch that may be worth getting -- this one applies against 2.6.11, and there's one against 2.6.12 on the site:

kernel-patch-2.6-bluez 20050328-1

What do I need to do to configure the device?

Debian has these libraries and tools:

libbluetooth1
bluez-utils -- tools and system daemons
bluez-pin -- user interface for the PIN codes needed for connecting Bluetooth devices
bluez-cups -- printer driver for CUPS
bluez-hcidump -- for debugging
bluez-pcmcia-support -- for PCMCIA Bluetooth devices

I installed libbluetooth1 bluez-pin bluez-utils on sigillo and got this:

Checking and creating device nodes ...
Starting bluez-utils: hcid sdpd rfcomm

So these protocols are:

hcid - Bluetooth Host Controller Interface Daemon (see /etc/bluetooth/hcid.conf)
sdpd -- advertises Bluetooth services available
rfcomm -- configuration utility

In sysv-rc-conf, I now see

bluez-utils

And in dmesg:

Bluetooth: L2CAP ver 2.7
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM ver 1.5
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized

along with lots of "device not accepting address".

Not sure you want to be running this, but if bluetooth won't go through walls, there's no security risk.

[One guide says "You'll also need an extention lead as plugging it into the back of the computer causes the signal to be masked. Also, the bluetooth signal won't go through walls." However, my bluetooth goes through walls fine, and I'm not using an extension.]

Here's how I set up a host-to-host connection, following these very simple instructions.

Setting up a NAP (Network Access Point)

On the server, issue

# pand --listen --role NAP --master --autozap

On the client, issue

# pand --connect 00:0C:41:E2:7B:DF --service NAP --autozap

It's the pand command that creates the bnep0 device

Verify the connection from both sides:

sigillo # ifconfig -a
bnep0     Link encap:Ethernet HWaddr 00:0C:41:E2:7B:DE
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

gubbio # ifconfig -a
bnep0     Link encap:Ethernet HWaddr 00:0C:41:E2:7B:DF
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Assign IP addresses:

sigillo # ifconfig bnep0 192.168.2.1
gubbio # ifconfig bnep0 192.168.2.2

Verify the addresses from both sides:

sigillo # ifconfig -a
bnep0     Link encap:Ethernet HWaddr 00:0C:41:E2:7B:DF
          inet addr:192.168.2.2 Bcast:192.168.2.255 Mask:255.255.255.0
          inet6 addr: fe80::20c:41ff:fee2:7bdf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:92 (92.0 b) TX bytes:188 (188.0 b)

gubbio # ifconfig -a
bnep0     Link encap:Ethernet HWaddr 00:0C:41:E2:7B:DE
          inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:200 (200.0 b) TX bytes:72 (72.0 b)

Add these lines to /etc/hosts on both systems:

# Bluetooth
192.168.2.1 Aurignacien
192.168.2.2 Gravettien

Test the connection:

gubbio # ping Aurignacien
PING Aurignacien (192.168.2.1) 56(84) bytes of data.
64 bytes from Aurignacien (192.168.2.1): icmp_seq=1 ttl=64 time=43.4 ms
64 bytes from Aurignacien (192.168.2.1): icmp_seq=2 ttl=64 time=39.8 ms
64 bytes from Aurignacien (192.168.2.1): icmp_seq=3 ttl=64 time=43.9 ms

sigillo # ping Gravettien
PING 192.168.2.2 (192.168.2.2): 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=64 time=72.6 ms
64 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=37.0 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=26.1 ms

Log on to the remote machine over the bluetooth network:

sigillo # ssh Gravettien
The authenticity of host 'gravettien (192.168.2.2)' can't be established.
RSA key fingerprint is fd:6e:c4:7a:63:f3:fe:7d:7c:ab:8b:38:42:b9:bb:d5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gravettien,192.168.2.2' (RSA) to the list of known hosts.
Last login: Tue Jun 21 15:29:03 2005 from sigillo
Linux gubbio 2.6.10-5-386 #1 Tue Apr 5 12:12:40 UTC 2005 i686 GNU/Linux
root@gubbio:~#

Wow. That was incredibly simple.

Testing rfcomm

For the GPRS connection, I see I need rfcomm and test these:

# ls -l /dev/rfcomm0 crw-rw---- 1 root dialout 216, 0 Jun 20 23:40 /dev/rfcomm0

# sdptool sdptool - SDP tool v2.15 Usage: sdptool [options] <command> [command parameters] Options: --help Display help --source Specify source interface Commands: search Search for a service browse Browse all available services add Add local service del Delete local service get Get local service setattr Set/Add attribute to a SDP record setseq Set/Add attribute sequence to a SDP record Services: DID SP DUN LAN FAX OPUSH FTRN HS HF SAP NAP GN HID CIP CTP A2SRC A2SNK # rfcomm bind 0 00:0C:41:E2:7B:DE 1 # rfcomm show rfcomm0: 00:0C:41:E2:7B:DE channel 1 clean

So it looks like the pieces are in place. On gubbio this also seems to work:

# rfcomm bind 0 00:0C:41:E2:7B:DF 1 # rfcomm show rfcomm0: 00:0C:41:E2:7B:DF channel 1 clean

The bind command seems to just confirm the device is present, like a loop-back? To use it, you need to release both, or you'll get "Address already in use":

sigillo # rfcomm release 00:0C:41:E2:7B:DE
gubbio # rfcomm release 00:0C:41:E2:7B:DF

Then set one of the devices in listen mode:

gubbio # rfcomm listen hci0 1 Waiting for connection on channel 1

and connect using the other:

sigillo # rfcomm connect hci0 00:0C:41:E2:7B:DF 1

They will now both show the connection:

gubbio # Connection from 00:0C:41:E2:7B:DE to /dev/rfcomm0 Press CTRL-C for hangup sigillo # Connected /dev/rfcomm0 to 00:0C:41:E2:7B:DF on channel 1 Press CTRL-C for hangup

Check the connection, which identifies master and slave:

gubbio # hcitool con Connections: > ACL 00:0C:41:E2:7B:DE handle 41 state 1 lm MASTERsigillo # hcitool con Connections: < ACL 00:0C:41:E2:7B:DF handle 41 state 1 lm SLAVE

Through rfcomm:

gubbio:~# rfcomm rfcomm0: 00:0C:41:E2:7B:DF -> 00:0C:41:E2:7B:DE channel 1 connected [reuse-dlc release-on-hup tty-attached]sigillo # rfcomm rfcomm0: 00:0C:41:E2:7B:DE -> 00:0C:41:E2:7B:DF channel 1 connected [reuse-dlc release-on-hup tty-attached]

To create the internet connection using /dev/rfcomm0 as a modem you could use something like this (lightly and not sufficiently modified from spello:/root/ipaq):

gubbio # /usr/sbin/pppd /dev/rfcomm0 115200 128.97.221.31:128.97.221.34 nodetach local \ noauth nocrtscts lock user ppp connect "/usr/sbin/chat -v -t3 ogin--ogin: ppp"

However, this fails because the chat script is wrong for the connection -- sigillo doesn't support login, and may not have a ppp daemon to receive the connection either. You could make this work but it has no significance now.

You've determined that rfcomm works fine, which is what you needed to accomplish.

2005-06-26: Connecting to a GPRS phone

I tried with tim's phone:

# hcitool scan Scanning ... 00:60:57:4D:FD:1F TimPhone 00:0C:41:E2:7B:DF Gravettien # hcitool inq Inquiring ... 00:60:57:4D:FD:1F clock offset: 0x7a01 class: 0x500204 00:0C:41:E2:7B:DF clock offset: 0x64b7 class: 0x300100

# sdptool search --bdaddr 00:60:57:4D:FD:1F DUN Searching for DUN on 00:60:57:4D:FD:1F ... Service Name: Dial-up Networking Service RecHandle: 0x10001 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 # rfcomm bind 0 00:60:57:4D:FD:1F 1 # rm /dev/modem # ln -sf /dev/rfcomm0 /dev/modem

# l2ping 00:60:57:4D:FD:1F Ping: 00:60:57:4D:FD:1F from 00:0C:41:E2:7B:DE (data size 20) ... 0 bytes from 00:60:57:4D:FD:1F id 0 time 52.87ms 0 bytes from 00:60:57:4D:FD:1F id 1 time 15.37ms 0 bytes from 00:60:57:4D:FD:1F id 2 time 16.48ms

I then started kppp and tried querying the modem. The phone prompted for a PIN and I gave it; the laptop similarly prompted and I gave that (this shouldn't need to be done -- I had forgotten to set the automatic PIN file to executable). The connecton works! Here are the modem query results:

ATI:      Nokia
ATI 1:   351102502357857
ATI 2:   V 2.54 02-03-2003 NHL-8 (c)NMP
ATI 3:   Nokia 3650
ATI 4:   2002_wk38

I didn't try actually dialing up, but this clearly works. You may need a special dialtone.

Using kbluetooth, I found that the phone appeared as a paired device!

top