Quozl's BlueTooth RSSI Mapping & Debian Configuration

| quozl@us.netrek.org | up |

Quozl bought a couple of 100m USB BlueTooth dongles and tried them out. They each have a cool blue LED.

Here's how to use them as a poor man's wireless network link.

Server & Client setup sequence

Debian GNU/Linux was used.

Manual connection sequence

To make a manual connection between two hosts. The client is presumed to be a portable unit. The server is presumed to have an internet connection.

  1. server preparation:
  2. client connect:
  3. server packet forwarding:

Automatic connection configuration

Goal: one dongle attached permanently to a server, acting as a network gateway. The other dongle attached when needed to a client, which then configures a network connection automatically.

  1. on server, edit /etc/network/interfaces and add an entry:
  2. This sets the IP address and network mask for the bnep0 interface. Choose an IP address suitable for your network.

  3. on server, create a /etc/bluetooth/pan/ directory, like this:
  4. on server, create the file /etc/bluetooth/pan/dev-up to contain:
  5. This script is called by pand when the bnep0 interface is created, and serves to bring up the interface. If you wish anything else to happen at the same time, place the commands here.

  6. on server, make the dev-up script executable:
  7. on server, edit /etc/default/bluez-pan, changing these options as shown:
  8. This sets the command line options for pand and enables it so that future boots will start it running.

  9. after the above, on server, insert the dongle, and start pand using the initialisation script:
  10. This starts the pand process, which then listens for connections. When a connection is received, the bnep0 interface is created and the dev-up script above is run to configure it.

  11. on client, add to /etc/network/interfaces file an entry for bnep0, like this:
  12. This sets the IP address and network mask for the client's bnep0 interface. Choose an IP address suitable for your network, and within the network mask used on the server. The gateway option should contain the IP address used on the server bnep0 interface; it causes a default route to be added to the routing table.

  13. on client, (just like on the server), create a /etc/bluetooth/pan/ directory, like this:
  14. on client, create the file /etc/bluetooth/pan/dev-up to contain:
  15. This script is called by pand when the bnep0 interface is created, and serves to bring up the interface. If you wish anything else to happen at the same time, place the commands here.

  16. on client, make the dev-up script executable:
  17. on client, write /etc/hotplug.d/usb/bluetooth.hotplug according to the product and type values given by keventd for your particular dongle:
  18. This script is called by keventd when the dongle is inserted, and runs pand to connect to the server. It is also runs when the dongle is removed, and brings down the bnep0 interface.

    Note: keventd created three instances of the script, so code is present to lock out two instances. The lockfile-create program is used.

  19. on client, make the bluetooth.hotplug script executable:
  20. after this, an insertion of the dongle on the client causes the kernel to run the /sbin/hotplug script, which runs the bluetooth.hotplug script, which starts pand to make the connection, and pand runs /etc/bluetooth/pan/dev-up to bring up the network interface.

Diagnosis

Futures

It is not certain what will happen if a second client connects. Either a bnep1 interface will be created, or somehow pand will maintain bnep0 as an end point in a multi-point network. Send me a third adaptor and I'll find out for you!

Problems

After a few hours (not measured), both systems received an error and the bnep0 interface was destroyed.

Attempting to reconnect with pand worked silently, but the bnep0 interface was not created. Workaround was to remove and re-insert the dongles, then resume operations from the client step of pand, and the server ifconfig only.

One reader suggested removing the modules that are not required. See .config for the options used. Unfortunately, it still occurs, during periods of high traffic load.

Received Signal Strength Information

One unit was placed near a window of a house in a rural area. This unit was attached to the server.

A second unit was attached through a 3m USB cable, to a laptop, which had a script recording time, BlueTooth received signal strength, link quality and geographic coordinates from a GPS. It was a bad satellite day, so assume plus or minus ten metres error. The laptop was driven around in a car, with the dongle hanging from the rear view mirror, although for the run along the western road it was hanging out the window nearest the house.

The image to the right is the received signal strength on a 5m raster, with 100m grid. The colour code is for the RSSI value recorded. An aerial photo image has been overlaid; dark green sections are tree cover. Conclusion is that the device performs to specification with ample margin.

At the longest distance of almost 400m, near the south western edge of the map, line of sight was obscured by a creek crossing. The link may have been capable of a greater distance if there was better line of sight.

The low signal strength on the western road corresponded to trees obstructing line of sight.

Image made with GRASS, the GPL'd geographic information system, followed by manual perspective and shearing of the aerial photo with GIMP.


| quozl@us.netrek.org | up |