After I was ‘inspired’ to try out Bluetooth Ethernet networking from Linux without any fancy GUI support I got into a longer odyssee. To spare others who want to use this on systems that are more ‘serverlike’ here is a quick summary on what I learnt:

Linux uses a package called Bluez for everything Bluetooth related. This goes along with the necessary kernel modules. Bluez currently comes in two versions in most distributions major version 4 and 5 that have some particular differences that will be detailed out later.

Bluetooth networking has different modes like WLAN. There are two ad-hoc kind modes and one mode where one box acts as an Access Point for Clients. That’s the mode that I will describe here. In Bluetooth lingo this is call ‘PAN’.

Earlier versions of Bluez containd a piece of software called pand and most online documentation for this whole configuration relates two that. However as of Bluez 4 this is no longer included.

Instead everything is handled by bluetoothd. Bluetoothd connects to the dbus system and the only way (I found) to get it to let a box work as pan-server or pan-client is to tell this to the dbus system.

If Bluez 4 is installed with the ‘test’ scripts there is a script called test-nap which makes the machine act as PAN Access Point. The script test-network is used to connect to a PAN AP.

What is hard coded into the bluetoothd is the way that the PAN Server accepts a connection: A bridge has to be created that can forward the packets on either the LAN or to the internet. The PAN-AP works by accepting the BNEP (that’s Bluetooth Lingo for Ethernet packets over Bluetooth) connection, bringing up the AP’s bnep interface and adding this to the bridge. Before this happens, all Bluetooth pairing and trusting must have happened. I found the simple-agent script included in Bluez 4 a good way to do this. Bluez 5 contains a tool called bluetoothctl that can do this in the same way.

The PAN Client needs to know, that the server it tries to connect to, actually offers the PAN service. Therefore when the client is paired it is wise to already have the service enabled (test-nap running) so that the discovery of the server leads to the necessary local entries in the database of bluetooth-partners contained in /var/lib/bluetooth/<MAC OF BLUETOOTH INTERFACE>.

If this entry exists, the DBUS hierarchy underneath org.bluez knows that there is a service ‘Network’ (or Network1 for Bluez 5) and allows a client to call the actual connect method.

So here is a step by step guide of what I did to get this working.

On the PAN-Server (Gentoo Linux with Bluez 4):

/etc/init.d/bluetooth start

Start the service and load the modules

hciconfig hci0 up piscan

Bring the interface up and make it discoverable

hciconfig hci0 lm master,accept

Make the interface master and let it accept connections then in one terminal

simple-agent hci0

To accept pairing requests and be able to enter a pin and in another terminal

brctl addbr br0

brctl addif br0 <interface to be bridged>

ifconfig br0 1.2.3.4 up

bluez-test-nap hci0 br0

With this the server side is done.

Now the client needs to be paired with the PAN-Server if we stay with Bluez 4 this goes something like this:

/etc/init.d/bluetooth start

hciconfig hci0 up

hcitool scan hci0

This starts the service and in the scan our PAN-Server should show up. Now let’s pair

simple-agent hci0 <bt-mac-addr-of-pan-server>

This should give us the opportunity to enter a pin code on bodes sides or authorize it.

Since the service is running on the pan-server a correct entry is made for the server so that the dbus system knows about the ability to offer PAN/NAP service. Now try

bluez-test-network <bt-mac-addr-of-pan-server>

If all goes well bnep0 is brought up. Now You can assign an address that matches in netmask the one on the server and a ping should be possible.

If You see a message like ‘input/output error’ it is likely that something is wrong in the bluetooth configuration below especially the whole pairing/trusting. I found it a useful tool for debugging to kill the bluetoothd on the PAN-Server and manually start it with -d -n for foreground mode and debugging. If You do this You need to restart the bluez-test-nap service as it does not automatically reregister itself. Then try the client again and the messages will give You an indication what is wrong.

Also have a look at /var/lib/bluetooth/<macaddr>/trusts that file contains a list of paired mac-addresses and how much the local bluetooth service trusts them. If the partner does not show up add it manually with [all] behind it (not good security advise but we want to get it working, don’t we). Then restart the bluetoothd so it rereads this file.

Between two bluetooth2 devices I got around 230kbyte/s of download speed. Sadly I only have one BT 4 device with linux at my hands at the moment so I do not know the upper limits. here.