Is Your Personal Area Network Giving You the BlueZ?

Bluetooth has been around for a while now (it originally was conceived in 1994 by Ericsson as a replacement for RS-232), and many of us have been enjoying the benefits of wirelessly connecting mice, keyboards, headphones, mobile phones, printers, PDAs and other devices over short distances.

Under Linux, these benefits are provided by one of two Bluetooth implementations: BlueZ and Affix. The former has become the accepted standard provided by most of the popular distributions and is the one I discuss here.

In BlueZ releases prior to version 4, the various Bluetooth services (called profiles) are implemented in separate dæmons, each with its own configuration. The PAN profile, providing personal area networking services, is implemented in the pand dæmon, dial-up networking in the dund dæmon, service discovery in the sdpd dæmon and so on. In BlueZ v.4, all of these are incorporated into one server process called bluetoothd. This change has led to a certain amount of confusion among users, so the aim of this article is to try to clarify the situation somewhat by looking at the way the PAN profile works in BlueZ v.4.

The PAN profile provides three ways of connecting Bluetooth devices in a network capable of carrying general-purpose protocols and services over TCP/IP. Such networks are known as piconets, because they are limited to a maximum of seven nodes and the short distances covered by Bluetooth transmissions (up to ten meters). These are PANU, Group Ad Hoc Network (GN) and Network Access Point (NAP) configurations. The PANU<--->PANU network is the wireless analogue of a Ethernet crossover cable between two computers. The PANU<--->GN network operates just like a Wi-Fi ad hoc setup where one node acts as the master node connecting up to six client nodes in an isolated private network and the PANU<--->NAP provides network infrastructure connectivity in the same way that a 802.11 Wi-Fi access point does for Wi-Fi clients. The NAP can serve six client nodes in the same manner as the GN master but also connects them to an existing network infrastructure. The NAP service is the most useful of the three connection patterns and subsumes the other two. So, if you can get NAP working, it is relatively straightforward to achieve the other configurations by omitting certain steps in the NAP setup.

The Bluetooth dæmon loads all the required kernel modules (the lsmod command should show bluetooth, rfcomm, btusb, llc, sco, bridge, bnep, stp and l2cap running) and creates a bridge-host interface called pan0. The bnep protocol provides Ethernet services over the Bluetooth l2cap connection and a separate bnep interface is created on demand for each remote device that connects (bnep0, bnep1...bnepN). bnep interfaces automatically are bridged to the pan0 interface that serves as an IP proxy for them. Thus, only the pan0 interface requires IP configuration. Once you have paired a remote Bluetooth device with the Linux box and discovered the BlueZ NAP service and connected/authenticated to it, all that remains is to provide IP configuration for the connected devices and the required infrastructure network connectivity. This is the part that has bamboozled many a keen BlueZman. Here, I consider two solutions: a bridged setup and a routed setup.

In many ways, the bridged solution is the simpler of the two. There are fewer steps involved, and it means that your NAP and your remote Bluetooth devices become part of your existing IP network/subnet. However, if you don't have an existing private network/subnet because your Linux box connects straight to your ISP (say via an Ethernet cable to an ADSL router) or your Linux box connects to your existing private network/subnet via an 802.11 Wi-Fi connection, the routed solution is the only way to go. You need a private IP subnet from which to allocate addresses to your remote BT devices, but you can't bridge to this via a wlan0 (802.11 Wi-Fi) interface because layer 2 of the wireless device is not available to the kernel bridging facilities. Without a bridge, you will require a separate IP network/subnet, routing and routing information, but luckily, this is not too hard to arrange.

Let's assume you have BlueZ 4 installed. If not, use your distribution's installation software to install it. You will need version 4 of the BlueZ and BlueZ-libs packages. The BlueZ kernel modules are incorporated into the 2.4 and 2.6 kernels. Another useful tool is provided by the gnome-bluetooth package in the form of a BT panel applet that allows control from the desktop, allowing you to pair devices and set service discovery. KDE provides a similar tool, kbluetooth. Start the Bluetooth dæmon in the normal way, and execute the bluetooth-applet from a shell. Enable Service Discovery in the bluetooth-applet, and introduce a remote BT device into range. You now should be able to discover the BlueZ-NAP service from the remote device. If you are not using the GNOME or KDE desktop, device pairing and service discovery are available through the hciconfig and hcitool utilities that are part of the BlueZ package.

If you are following this solution, I will assume you have a single ISP-assigned, routable IP address that provides your Internet connectivity (Figure 1). Your local private network (say 192.168.0.0/24) uses Network Address Translation (NAT) provided by your router to access the Internet through your ISP connection, and the Linux box on which you want the BT connectivity connects to the private network via an eth0 interface to an Ethernet switch. All that being true, you are only three steps away from your bridged NAP solution:

You can achieve step one by use of the brctl command:

brctl show (display any extant bridges - should show pan0)
brctl add pan0 eth0 (add the eth0 interface to the pan0 bridge)
brctl showmacs pan0 (show which interfaces are bridged)

You can use ifconfig to achieve step 1 temporarily:

ifconfig pan0 192.168.0.123 netmask 255.255.255.0 
 ↪broadcast 192.168.0.255 up

Use your distribution's network management tools to create a permanent configuration, and choose IP values to suit your own private network topology.

Figure 1. Bridged NAP Solution

The neatest solution for step three is to run a small DHCP service. If you already run DHCP for your own private network, you just have to make sure that the configuration covers any remote BT devices you might connect in addition to the clients already connected. The pan0 interface also can get its IP configuration in this way. If you don't already run DHCP, now could be a good time to start! It isn't difficult to set up a simple service, and it reduces the amount of general, routine manual configuration.

Below is a simple dhcpd.conf file sufficient to serve our PAN:

# small DHCP config for bluetooth PAN
ddns-update-style none;
authoritative;

subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.10 192.168.0.100;
option domain-name-servers 192.168.0.1;
option domain-name "bluetooth.net";
option routers 192.168.0.1;
option broadcast-address 192.168.0.255;
default-lease-time 600;
max-lease-time 7200;

host btmobile {
hardware ethernet 74:e7:71:ac:d0:34;
fixed-address 192.168.0.9;
}
}

The subnet declaration should correspond to your local private network topology. The range declaration specifies a pool of IP addresses that can be assigned dynamically. The options specify DNS servers (this could be your ISP's nameservers), default gateway (the NAT router) and other common IP parameters. The host declaration allows you to assign fixed IP addresses to known (by MAC address) devices. Place this file where your DHCP server expects to find it, and start the server by the method appropriate to your distribution.

Needless to say, your remote BT devices and the pan0 interface should be configured to get their IP configuration via DHCP. Once all this is in place, your NAP should be active a few seconds after you connect/authenticate your BT device to the Linux box.