Creating a Bluetooth Access point (NAP) in Ubuntu 11.10

A Bluetooth NAP is similar to a Wi-Fi access point. In this case, we will be using NAP to share an Internet connection to another computer with Bluetooth. It is supposed to be able to support 7 or 8 devices connected at once in this manner. Eventually my personal goal is to use this in conjunction with a Wi-Fi connection to get slightly more speed at once or for some redundancy to help achieve a more ubiquitous/pervasive connection.

It turns out what should be a simple process is a bit tricky in Ubuntu. You would expect to be able to create an IP access point fairly easily so that you can share your Internet connection to other devices using Bluetooth. (It turns out it may be possible with Blueman – http://blog.larsstrand.org/2009/04/sharing-internet-connection-over.html, but I’ve never had any luck with setting it up this way.) Here’s some of the steps and resources I used to get it to work. I am using one laptop with a generic usb dongle and another toshiba netbook with built-in Bluetooth for this.

Before anything is started, you need to make sure the devices are paired and trusted with one another. I found the easiest way to get this to work is with blueman (it is in the Ubuntu repos). Also it seems to work better if you initiate the pairing from the client (the computer not sharing the connection).

First, you need a bridge interface. This is easy enough in Ubuntu, by editing the /etc/network/interfaces file. If the interface you wish to share is eth0 (if you want to share a Wi-Fi connection instead, you could switch this with something like wlan0 or whatever your Wi-Fi interface is), you could add something like this:

auto br1
iface br1 inet dhcp
	bridge_ports eth0
	bridge_fd 9
	bridge_hello 2
	bridge_maxage 12
	bridge_stp off

Next you need to make sure both computers can see each other via Bluetooth. This requires enabling scanning and turning the NAP into a master and the client(s) into slaves. This can be done as follows:

sudo hciconfig hci0 piscan

and

sudo hciconfig hci0 lm MASTER,ACCEPT

or

sudo hciconfig hci0 lm SLAVE,ACCEPT

You can now check to see if each of the computers can see each other on bluetooth by running:

hcitool scan

where you should be able to see the opposite computer on each.

Next you want to start the NAP server on the computer you wish to share the connection from. (This is the computer with the bridge device). This script, which is available on the git repository will allow you to start up the NAP server. (it may also be possible to use pand, but I haven’t had any luck yet with it)
This script is called test-nap. It takes a single argument, which is the name of the bridge device. So in our case we would first need to chmod +x the file (to make it executable), then run it like this:

./test-nap br1
#!/usr/bin/python

import sys
import time
import dbus
from optparse import OptionParser, make_option

bus = dbus.SystemBus()

manager = dbus.Interface(bus.get_object("org.bluez", "/"),
"org.bluez.Manager")

option_list = [
make_option("-i", "--device", action="store",
type="string", dest="dev_id"),
]
parser = OptionParser(option_list=option_list)

(options, args) = parser.parse_args()

if options.dev_id:
adapter_path = manager.FindAdapter(options.dev_id)
else:
adapter_path = manager.DefaultAdapter()

server = dbus.Interface(bus.get_object("org.bluez", adapter_path),
"org.bluez.NetworkServer")

service = "nap"

if (len(args) < 1): bridge = "tether" else: bridge = args[0] server.Register(service, bridge) print "Server for %s registered for %s" % (service, bridge) print "Press CTRL-C to disconnect" try: time.sleep(1000) print "Terminating connection" except: pass server.Unregister(service)

After this, you can search from the client to see if the NAP service can be discovered with the command:

sdptool search NAP

You should be able to see the NAP service from your server machine at this point.

The last thing to do is edit the /etc/network/interfaces file on the client side (the device which will connect to the Internet via Bluetooth. When pand connects, it uses a bnep0 interface. You need to add the following to your file:

iface bnep0 inet dhcp

Now we are ready to connect. This is how you connect:

pand -c 
sudo ifup bnep0

Links:

Aircrack suite + Ubuntu 11.10 problems with monitor mode channel

Recently I have been playing around with the aircrack suite and in particular the aireplay-ng tool. This tool may be used for ARP replay attacks, however it requires that the monitor mode interface is able to switch channels to the channel of the target device / access point. For some reason my monitor interface was stuck in channel -1. So to fix this I found a forum post on Ubuntu Forums which solves this problem: http://ubuntuforums.org/showpost.php?p=10550806&postcount=6

You can apply this to the wlan interface to put it directly into monitor mode and avoid using the airmon-ng tool altogether if you wish. You may also be able to apply this to the mon0 interface created by the airmon-ng tool as well, however I have not tried it yet.

The bulk of the problem is just the order in which monitor mode and channel are enabled, it must follow the order as follows:
ifconfig $IFACE down
iwconfig $IFACE mode managed
ifconfig $IFACE up
iwconfig $IFACE channel $@
ifconfig $IFACE down
iwconfig $IFACE mode monitor
ifconfig $IFACE up

Hope this solves some problems…

Upcoming PhD QE Progress

So I’ve been doing my PhD for over two years now, and I haven’t posted a reflective “state of the thesis” post in quite some time, so here it is. I have maxed out my 50 pages (not included ToC and references) for some time now, it’s just been in the process of revision for the last month or so! I have more or less settled on what my research actually is now and am getting a clearer picture of it in my head all the time.

Officially the topic is “Radio Resource Management for Quality of Service in Heterogeneous Wireless Networks”. This is quite the mouthful, I know. Really what it boils down to is: Making various wireless technologies (Bluetooth, WiFi, WiMAX, 3G, 4G, … , etc) seamlessly work together. Many devices are capable of connecting to many of these radio access technologies (RATs), but often it is not seamless. What do I mean by this? Well suppose I am inside a university building, deep in the basement (where they tend to put CS students :P) where there is no mobile reception (3G, 4G etc.). I start downloading a large file, or call someone via wifi. Now I want to walk to my car because it’s time to go home for the day. Many networks now are not able to handle this, and it is interrupted after you change networks. Furthermore, you often have to manually tell the device you want to leave one network and join another. Seamless means this should all happen without you noticing. This is the focus of my research.

The biggest problem that I am concerned with is called handoff or handover. This is when the switch between RATs occurs. Traditionally, this also occurs when a mobile device switches from one tower to another, and it usually involved predicting the motion of the device along with some other factors for Quality of Service (QoS). For a vertical handover, we may or may not need to predict motion. If the heterogeneous wireless network (HWN) is densely covered, many RATs are available throughout the coverage region (as opposed to a sparsely covered where a given location may have access to one technology at once). In a dense HWN, the problem becomes a multi-criteria question.

  1. Which network is most economical for me to connect to?
  2. Which configuration of (network, client) pairs is most profitable for the operator?
  3. Which network is able to provide me with the required QoS?

More technical details to follow…

Why Blanket Wireless Coverage in Waterloo Failed, and Potential Solutions

Today the KW Record ran an article entitled “Blanket Wi-Fi plans unplugged in Waterloo Region and Guelph, but growing in Stratford”. I thought I’d throw in my two cents since this issue is very related to some of my research. Overall to me, the biggest factor that contributed to the failure of blanket wireless access in the Region of Waterloo was the cost of the service for users. From what I remember, it was on part with many high speed Internet plans. Why would someone pay the same price to have potentially slower, less secure service than competing wired services?

The Atria plan used large WiFi cells, with very expensive antennas (see the apartment building near University Plaza, which I believe was one of them).

Many other cities (much larger ones) have been very successful in providing blanket WiFi, using a completing different coverage model and cost model. The best example is San Francisco where a company named Meraki provides free wifi for over 100,000 people using their Mesh Router devices. These devices cost between $399 and $1500 each, which is still expensive, but likely much cheaper than anything used by Atria. These devices likely have much lower range and handle dense areas compared with the atria cells which seem to be designed for large areas, and require many people to subscribe to pay for their costs. The argument in the article that WiFi coverage in metropolitan areas is difficult seems like a terrible attitude to have for an area that has a reputation as a high tech leader. San Francisco likely has much greater challenges in this regard compared to our tiny city.


Example coverage map in San Francisco

Instead of using these expensive devices, much cheaper devices such as linksys wrt routers could be used. These routers support linux, and because of this much customization is possible such as mesh networking. While these devices are less reliable than the previous more expensive solutions, it may be a good way to at least get the network started cheaply. Additionally, areas which are not used by as many people could be covered with cheaper routers, while areas with more dense traffic may be covered by expensive ones.

The argument in the article that WiFi networks are unnecessary because of cellular networks is ludicrous! If that is the case, why are every smartphone and other device including WiFi radios in them? It’s because data on cellular networks is way to expensive. Any place where a device can get free or low cost WiFi should be used instead of the cellular network. One large problem with this at the moment, however is that it is not seamless to go from a cellular network to a wifi network. For example, it is often not possible to carry on a phone call while switching networks, or continue downloading or steaming without interruption. This will change with much of the research in heterogeneous networks.

One potential model that hasn’t been explored much is community wireless networks. In this case, devices could be provided to anyone willing to provide access to their own home network for the community. The incentive could be either donations from users, or a very small fee (2 – 5 dollars per month) which is distributed to providers. Additionally, anyone who provides a part of the network is able to get on free to other parts of the network. Of course, there’s nothing to stop the larger companies like Rogers and Bell from creating the same type of value added service. Since so many people already have wireless in their home using Rogers and Bell, they could create some type of login where you take your bandwidth quota with you and have access to anyone else’s network who is also participating. This way, you are not using their bandwidth cap (only their “speed” – which may introduce a whole other range of problems :P)