Tethering a Nokia 6165i to a Compaq nc4010 using Bluetooth (Kubuntu)

This was not that hard to do – for a sysadmin and geek – but not for a general user. One of the things I like about Kubuntu is its ease of use and preconfigured and debugged desktop, but here it fails. Setting up a dialup networking connection is sorely inadequate, and is completely unintuitive. Most of this problem stems from several problems:

  • The menu structure in KNetworkManager is very obtuse and non-obvious.
  • Configurations created by kppp and by KNetworkManager (running kppp) result in two different configurations in two different locations.
  • Configuration of the ppp0: network device is not available anywhere related to networking.

A lot of this problem stems from the way KNetworkManager is set up; however, the network configuration interface should also allow for the creation of a ppp0: device.

There also seems to be no way to create a tethered link to a bluetooth device without using the command line. Not a problem for me nor for many of you, but for a general user it would be a real stumbling block. (I guess I shouldn’t be surprised; from the project page comes this bit about dial-up support: The rudimentary dial-up support gives the user the ability to connect dial-up connections configured using YaST. There is much room for improvement. As of 16/11/2007 in Opensuse 10.3, this is broken.).

Most of the directions I took from this article titled Bluetooth DUN tethering – Linux and KDE (Might work with Gnome) from PinStack.com (a support site for Blackberry users).

In this case, I will assume that you know how to pair a cell phone device with your Linux laptop; it’s fairly easy (though not completely intuitive). I’ll also assume that all of the requisite bluetooth support is available and already installed.

You’ll need to get the MAC address for the bluetooth device. This could be done any number of ways; from the command line this will do:

$ hcitool scan
Scanning ...
00:12:D1:C9:DF:5E Nokia 6165i
$

After the MAC address is found, then the next step is to find the appropriate bluetooth channel for dial-up networking. This can be done using the sdptool command:

$ sdptool browse
Inquiring ...
Browsing 00:12:D1:C9:DF:5E ...
Service Name: Dial-up networking
Service RecHandle: 0x10000
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100

A lot of information spits out, but the relevant one for me was this entry. Now create the serial link that connects the “modem” to the operating system – in particular, a device /dev/rfcomm0 is created for communicating with the bluetooth modem (which is what the phone becomes). This is done thusly:

# rfcomm bind hci0 00:12:D1:C9:DF:5E 1

Once this is done, assuming the right channel was chosen, then kppp can be configured. Because of the conflict between kppp configuration and the KNetworkManager configuration, a setup step may be worth doing (as root):

# cd ~/.kde/share/config/
# rm -f kppprc
# ln -s ~me/.kde/share/config/kppprc

What this does, then, is make it so that your personal configuration for kppp is also used by root. Now kppp can be run from the command line (since it’s already open, right?) and you won’t have to go searching for the configuration in the menu tree:

$ kppp

After kppp is configured, you should be able to use your phone as a cellular modem. The configuration I used (for U.S. Cellular) worked, and has been described in these pages in the past.

SystemTap (and DTrace)

SystemTap is one amazing piece of work – it is a programmer-friendy and admin-friendly interface to KProbes (which are included in the Linux 2.6 kernel).  When you compare its capabilities to what has gone before, it is truly amazing.  Here are some of the things you can do:

  • Quantify disk accesses per disk per process (or per user)
  • Quantify the number of context switches that are a result of time outs
  • List all accesses to a particular file and the process that accessed it

This is only the tip of the iceberg. There is a wiki with more details, including “war stories.”  There is a language reference there as well.

There was an excellent article in Red Hat Magazine, “Instrumenting the Linux Kernel with SystemTap” by William Cohen.

One controversy that came up was that the initial impetus for creating SystemTap was to implement something like Sun’s DTrace for Solaris but under the GNU Public License.  Solaris and DTrace are licensed with Sun’s Common Development and Distribution License (CDDL), which many feel makes DTrace incompatible with the GPL-licensed Linux kernel.

Apparently, the CDDL is also incompatible with the BSD-licensed FreeBSD, as FreeBSD 7.0 will not have DTrace either.  There appears to be some licensing issues.

According to the Wikipedia entry on the CDDL, it was designed to be both GPL-incompatible and BSD-incompatible.  With regard to the GPL, the entry suggests that Sun never clarified why; as to the BSD, Sun did not want Solaris to wind up in proprietary products – which the BSD license allows.

On a brighter note, Eugene Teo was able to get the SystemTap tool to work on the Nokia N800.  The article seems to be behind a wall at LiveJournal; the article is still in Google’s cache.  However, it does requires some amazing convolutions:

  • A kprobes-enabled kernel must be installed on the N800
  • The SystemTap programs (like stap) must be installed on the N800
  • Any traces must be cross-compiled on another host
  • The kernel module thus created must be moved to the N800
  • Once the kernel module is in place, then the trace can be done.

So every desired trace requires precross-compilation on a desktop (sigh)…  Oh, well.

There is even a GUI for SystemTap in the works.