Is Your Personal Area Network Giving You the BlueZ?

Bluetooth is a complex beast, and recent changes to the standard Linux implementation have bamboozled many users. Untangle your personal area network with this revealing article on setting up the Bluetooth PAN Profile in BlueZ v.4.

The Route of the Problem

For the routed solution, you need to create a separate network/subnet
for your PAN and route packets between this and the existing private
network/ISP-connected machine. In this configuration pan0 will
be the default gateway device and also provide the DHCP service for
the PAN. Thus, pan0 will require a static IP configuration and
its DHCP service will be separate from any other DHCP and dedicated
to the PAN. For clarity, let's use the 10.0.0.0/24 private IP network
range for this purpose. This time, there are four steps to get your routed
PAN up and running:

pan0 should be configured and up and running before you start the
DHCP service. The next step involves enabling IP forwarding so that
packets are routed between
pan0 and your existing interface (wlan0/eth0).

In older systems, IP forwarding is enabled by echoing a value of
“1” into
the appropriate system file:

echo 1 > /proc/sys/net/ipv4/ip_forward

In more recent systems, this is achieved by editing /etc/sysctl.conf:

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

The setting also may be available in your distribution's firewall
configuration GUI tool. If none of these methods work on your system,
consult your distribution's documentation.

Finally, you need to tell the kernel netfilter software
to “masquerade” (NAT) PAN packets through the wlan0/eth0
interface. You may be able to do this using your distribution's firewall
configuration GUI tool (the IP forwarding setting may be available
here too). If not, it can be achieved using the iptables command:

iptables -A POSTROUTING -t nat -o wlan0 -j MASQUERADE

Substitute eth0 for wlan0 if you are using the routing
option because your Linux box connects directly to your ISP and your eth0
interface has an ISP-assigned, routable IP address (Figure 2).

Figure 2. Routed NAP Solution

If all has gone well up to this point, your NAP service should be active
a few seconds after you connect/authenticate your remote BT device. You
should, for example, be able to ping the device from your Linux
box. If IP is not yet running, you can use l2ping
<MAC-ADDRESS>
to ping the remote device.

Oh, for the Simple Life

BlueZ v.4 does not appear to provide separate configurations for GN
and PANU modes of PAN operation, but this is of no consequence because, as
was noted above, these are subsumed by the NAP mode. If you only want to
connect remote BT devices to your Linux box, and do not require access to
the local network or Internet, you simply can omit step 1 from the
bridged solution and either employ the DHCP configuration from
the routed solution or manually set IP parameters for
pan0 and your BT devices.

In fact, Bluetooth is supposed to implement the draft
Link-local Autoconfiguration Protocol (variously known elsewhere as
Avahi, Bonjour, Rendezvouz and APIPA), so you could try using
this for IP configuration instead of running a DHCP service. However,
I had no joy with this approach under BlueZ v.4, so I leave it as
a potential solution for those of an experimental nature. I would be
happy to hear that this facility is alive and well in the BlueZ package
if anyone succeeds where I have failed.

Nostalgia Is Not What It Used to Be

For those who want to retain the old ways of configuring and running
the Bluetooth facilities, the development team has provided a legacy
implementation in the form of a package that contains the separate
dæmons as provided in BlueZ 3.x. This package is called
Bluez-compat and should satisfy the change-resistant among you. Michael
Schmidt (see Resources) has produced a useful how-to document covering
the legacy formats.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.