A description of two methods for connecting a Palm Vx with a Red-M blade to your local network using PPP.
This version: $Revision: 1.4 $
This document describes how to:
Linux kernel: you should be running kernel 2.4.7 or better. I'm using 2.4.17.
GNOME pilot: you should have gnome-pilot 0.1.63 or better. I'm using 0.1.63, along with GNOME 1.4.
Hardware: as well as a Palm Vx with a Red-M blade, you'll need a USB adapter for your PC. I'm using the TDK USB dongle, I've also tested with the Xircom CreditCard Bluetooth adapter.
You: you should be happy compiling kernel modules, and be familiar with checking code out from CVS.
The most actively developed Bluetooth stack for Linux at the moment is BlueZ. At the time of writing, the latest release is 2.0pre6. Grab that or better from the BlueZ web site. Then follow these steps:
Ensure your kernel does not have any bluetooth support compiled-in already. If you compile your own kernel, you know how to do this. If you use your distributions stock kernel with modules, then remove the bluetooth modules. (If you don't know how to get past this stage, you might want to give up and wait a little while...)
Configure and compile BlueZ:
./configure --prefix=/usr make make install
(You should read the BlueZ documentation properly, this is just a
precis of what to do. However, note that the HOWTO currently on the BlueZ
site is for BlueZ 1.2, not the 2.0 series. The best way to get updated
documentation is to go check it out of the BlueZ CVS, it's in the doc
module. Especially, you'll want to make the suggested edits to
modules.conf. If you're running Debian 3.0, put them in a file
called /etc/modutils/bluez and then run
update-modules.)
If you use USB:
modprobe hci_usb modprobe bluez modprobe l2cap
If you have a PCMCIA (UART) adapter:
modprobe hci_uart modprobe bluez modprobe l2cap hciattach /dev/ttySN cardtype 115200 flow
For instance, with my Xircom card, I note that when I insert it, it
appears at /dev/ttyS2, so I type: hciattach /dev/ttyS2 xircom
115200 flow. Read the BlueZ documentation for more information on
tuning this, the instructions here are intended to get you started.
Use the hciconfig command to see the Bluetooth interfaces.
hciconfig works a bit like ifconfig. If your Bluetooth
interface isn't up, then bring it up with hciconfig hci0 up.
Here's what I see when I type hciconfig after the link's been running a while:
hci0: Type: USB
BD Address: 00:80:98:24:15:6D ACL MTU: 128:8 SCO: MTU 64:8
UP RUNNING PSCAN ISCAN
RX bytes:461707 acl:10087 sco:0 events:8444 errors:0
TX bytes:267064 acl:8068 sco:0 commands:213 errors:0
Each Bluetooth device has an address, a bit like ethernet cards have a MAC address. You need this address to connect directly to other devices.
Now switch your Palm pilot on, after installing the Red-M blade. Go to the "Prefs" application, pick "Bluetooth" and from the "Devices" menu select "Discoverable." Then type:
hcitool inq
This should give you something like this:
Inquiring ...
00:02:81:24:07:8A clock offset: 0x7b5fclass: 0x000114
The address shown is that of your Red-M blade. Keep the Palm discoverable, and try this (remember to substitute the address of your Palm):
l2ping 00:02:81:24:07:8A
You should then see something like this:
Ping: 00:02:81:24:07:8A from 00:80:98:24:15:6D (data size 20) ... 20 bytes from 00:02:81:24:07:8A id 200 time 66.20ms 20 bytes from 00:02:81:24:07:8A id 201 time 35.00ms 20 bytes from 00:02:81:24:07:8A id 202 time 27.69ms
Terminate l2ping with Ctrl-C.
From the Bluetooth screen of your Palm prefs application, tap the "Discover" button. You should see something like "BlueZ (0)" appear on the list of Bluetooth devices. If you tap on the list entry, you'll see a more detailed information screen for the computer.
In particular, you'll see a list of supported services. Right now they're likely to have an "X" against them, indicating they're unavailable. This will be explained more in the "Method 1: PC acting as serial host" section below. You don't need to worry about it if you decide to pursue "Method 2: Red-M Blade acting as serial host."
Serial links in Bluetooth are achieved via the use of the RFCOMM protocol. This sets up a virtual serial connection over the wireless link, so applications that require a serial connection can work happily over the virtual connection. RFCOMM requires one end of the connection to be the serial host. This means there are two alternative setups. The first of these, and the most conventional, is to have the PC be the serial host, and the Palm Pilot initiate the connection. The second way is to have the Palm act as the host and the PC initiate the connection. I'll describe both ways.
In order to have the PC host the RFCOMM connection we'll have to do a bit more to set up BlueZ on our system. In particular, we'll need two applications that we haven't yet installed, sdpd and rfcommd. These are both daemons: that is, they run continually in the background performing a service. The sdpd program operates the Bluetooth Service Discovery Protocol (SDP). It is SDP that allows devices to advertise to each other which particular Bluetooth services they offer. You will recall when we discovered the computer from the Palm, there was a list of services in the detailed screen for the computer: if SDP was running some or all of those items would likely indicate the availability of a service. The second daemon, rfcommd, provides the RFCOMM service. It listens for RFCOMM requests and then establishes the serial connection and hands it to a program such as pppd.
Our first step will be to get sdpd up and running. Grab the
sdpd-0.1.tar.gz source from the BlueZ download page.
Unpack it, and compile and install it. (I compile it with the configure
option --prefix="", your mileage may vary depending on where you
want your files to go on your system.) For our purposes, the default
configuration will do. Invoke the daemon by typing sdpd. You
should see a startup message appear in your syslog. If in doubt, run
sdpd with the -n option, this stops it detaching
itself from the terminal and displays all messages to the standard output.
Try selecting the PC Bluetooth interface on your Palm Bluetooth preferences again, and hitting the "Update" button. You should now see that some services are now marked as supported. Tap "OK" to get back to the list of Bluetooth devices. You should be looking at the "All" category of devices. In order to make the Red-M Blade connect to your PC, you need to tell it that the PC is an access point. To do this, check the box to the left of the PC's interface name (should read "BlueZ (0)" or similar) and move it by tapping the "Move" button that appears. Recategorize the PC as an Access Point.
We'll also set up the PPP connection on the Palm side. Run the Prefs app and choose the "Network" screen. Create a new service and call it something like "Bluetooth PPP". Change the "Connection" drop-down to read "Bt Serial" Then enter the username and password combination you want to use to connect to your PC. These can be anything: you'll need them in the next section.
Now we need to set up rfcommd on the PC. This is a little more
tricky. At the time of writing, there is no official release of
rfcommd that fulfils our needs. Instead, we need to check out
rfcommd from BlueZ CVS and then add a patch. To do this, follow the
instructions on
SourceForge to log in for anonymous CVS. Where the SourceForge page says
modulename, use rfcommd.
Next, download the patch rfcomm.diff from Ilguiz
Latypov's site. Run patch <rfcomm.diff to bring your the
rfcommd files up to date. To make life simpler for you, I've
archived my a snapshot of a patched rfcommd. You may prefer to use
this instead of going the CVS and patch route: rfcommd-patched-2002-03-05.tar.gz.
Configure and install rfcommd.
Take a look at the rfcommd.conf file (this probably got installed to /etc/rfcommd.conf). Change it so the "na" session looks like this:
na {
channel 8;
up {
ppp "192.168.2.1:192.168.2.2 debug ms-dns n.n.n.n";
};
}
We're using the private 192.168.2.* network for our experiments. If this conflicts with one of your networks, then change the IP addresses to suitable values.
Replace the IP address n.n.n.n after ms-dns with
that of your local name server (if you don't know this, try looking in
/etc/resolv.conf).
Presuming you want to give the Palm full access to our network, so you could run a browser or IRC client on the Pilot for instance, we also need to make the Linux machine forward IP packets for us. Ensure that's switched on by doing:
echo 1 > /proc/sys/net/ipv4/ip_forward
On Debian 3.0, you can edit /etc/network/options and change the
value of ip_forward to yes to ensure this option is
switched on permanently. Other distributions should have similar setups, or
you can just put that above line in one of your boot-time scripts.
Then run rfcommd -s na to start the RFCOMM service. You
should see a startup message again in your system logs. You're almost set to
connect now. The final thing to do is to set up the authentication details
for the Palm. Edit /etc/ppp/pap-secrets and add a line that looks
like this:
username hostname "password" *
Remember to substitute the username and password you put into the Palm PPP link setup earlier, and your PC's hostname for hostname.
Now, go back to your Palm connection screen and tap the "Connect" button. If all goes well you'll see the Palm establishing the connection and signing you on. Take a look in your syslog to see pppd doing its work -- we specified the "debug" option earlier, so you'll see the mechanics of the PPP connection in your logs. Try pinging your Palm from the PC:
% ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2): 56 data bytes 64 bytes from 192.168.2.2: icmp_seq=0 ttl=255 time=77.8 ms 64 bytes from 192.168.2.2: icmp_seq=1 ttl=255 time=80.5 ms 64 bytes from 192.168.2.2: icmp_seq=2 ttl=255 time=78.3 ms
Your Palm Pilot should now be able to access network resources on your PC. To make it able to access resources elsewhere on your network, other machines need to know that your Bluetooth host is the place to go for the 192.168.2.* subnet (for instance.) One solution is to add a static route in, with a command like this:
route add -net 192.168.2.0 netmask 255.255.255.0 gw your-hostname
Obviously, adjust for your own values. (On my Debian machines I've added this command into /etc/network/interfaces as an "up" parameter for eth0 so the route gets added in when the network is brought up.)
A more sensible solution for a normal network is to configure the Linux PC to do network address translation (NAT). This makes all the Pilot's requests look like they're coming from the PC itself, so there's no need to add in extra routes or eat up network-wide IP addresses. The downside to this is that you can't run servers on your Palm Pilot. For more information on NAT check out the BlueZ HOWTO and also your Linux distribution's documentation for iptables and/or ipmasq.
If you get stuck on anything in this section, it's probably because I've rushed through the details of setting up a PPP connection. The best place to go for help is the Linux PPP HOWTO.
This method avoids some of the overhead connected with the first method, but is not really the "proper" way to do things. It's included in detail here because getting a working rfcommd, as used in Method 1, proved difficult for me for a long time, and so I put some time into getting this method working.
The first thing we'll do, then, is set up the Pilot connection. Run the Prefs app and choose the "Network" screen. Create a new service and call it something like "Bluetooth PPP". Change the "Connection" drop-down to read "Bt Serial Host" Then enter the username and password combination you want to use to connect to your PC. These can be anything: you'll need them in the next section.
Now it's time to get the software set up for the PC side of things. Grab Marcel Holtmann's rfcomm package from his web site, and follow his install procedure. If you're running a stock Debian kernel, which versions its modules, you may have the same problem compiling the ussp module that I did. If so, change the CFLAGS line in ussp/Makefile to this:
CFLAGS = -D__KERNEL__ -I$(INCLUDEDIR) -I. -DMODVERSIONS \
-DEXPORT_SYMTAB -DMODULE -include \
/usr/src/linux/include/linux/modversions.h -Wall \
-Wstrict-prototypes -O2
If all goes well, you now have the rfcomm program installed.
Test out connecting to your Palm by typing:
rfcomm 0 00:02:81:24:07:8A
Don't forget to substitute the Palm's address that you found out above. Ensure the Palm's on the "Network" screen of the "Prefs" application, and hit "Connect." All being well, rfcomm will give you a "Connected" message, showing that the RFCOMM connection has been made.
Eventually, the Palm Pilot will give you a PPP timeout: this is not
surprising, as the PC is not running PPP at this point. Hit Ctrl-C on the
terminal to terminate the rfcomm program.
The effect of the rfcomm program, as invoked above, is to
give you a serial connection to your Palm available on /dev/ttyU0.
The missing step to connect our two machines is to establish a PPP link over
the serial connection. Presuming you want to give the Palm full access to our
network, so you could run a browser or IRC client on the Pilot for instance,
we also need to make the Linux machine forward IP packets for us. Ensure
that's switched on by doing:
echo 1 > /proc/sys/net/ipv4/ip_forward
On Debian 3.0, you can edit /etc/network/options and change the
value of ip_forward to yes to ensure this option is
switched on permanently. Other distributions should have similar setups, or
you can just put that above line in one of your boot-time scripts.
Before we establish the PPP link, you need a username/password pair for the Pilot to use. You set this up earlier. Edit /etc/ppp/pap-secretsand add a line that looks like this:
username hostname "password" *
Substitute the username and password you chose earlier, and hostname for the hostname of your Linux machine.
You're now ready to establish the PPP connection between the two machines. Run rfcomm as illustrated above, hit "Connect" on the Palm, and immediately run the following command:
pppd /dev/ttyU0 nodetach debug local 192.168.2.1:192.168.2.2 \
ms-dns n.n.n.n
Substitute n.n.n.n for the IP address of your network's DNS
server (if you're uncertain, it should be in the file
/etc/resolv.conf). The above command sets up the interface on the
192.168.2.* subnet. You can adjust this to suit your local network. If all
has gone well, you should see the Palm Pilot telling you it is "signing in",
and pppd will show you a verbose transcription of what's going
on. Here's an example:
using channel 29 Using interface ppp0 Connect: ppp0 <--> /dev/ttyU0 sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x7514471d> <pcomp> <accomp>] rfcomm_send_data: DLCI 0 not connected Connected rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <pcomp> <accomp>] sent [LCP ConfAck id=0x1 <asyncmap 0x0> <pcomp> <accomp>] sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x7514471d> <pcomp> <accomp>] rcvd [LCP ConfRej id=0x1 <magic 0x7514471d>] sent [LCP ConfReq id=0x2 <asyncmap 0x0> <auth pap> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <auth pap> <pcomp> <accomp>] sent [LCP EchoReq id=0x0 magic=0x0] rcvd [PAP AuthReq id=0x1 user="edmundd" password=<hidden>] sent [PAP AuthAck id=0x1 "Login ok"] sent [IPCP ConfReq id=0x1 <addr 192.168.2.1> <compress VJ 0f 01>] sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [LCP EchoRep id=0x0 magic=0x0] rcvd [IPCP ConfReq id=0x1 <addr 192.168.2.2> <compress VJ 03 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] sent [IPCP ConfNak id=0x1 <ms-dns1 192.168.0.5> <ms-dns3 192.168.0.5>] rcvd [IPCP ConfNak id=0x1 <compress VJ 03 01>] sent [IPCP ConfReq id=0x2 <addr 192.168.2.1> <compress VJ 03 01>] rcvd [LCP ProtRej id=0x2 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f] rcvd [IPCP ConfReq id=0x2 <addr 192.168.2.2> <compress VJ 03 01> <ms-dns1 192.168.0.5> <ms-dns3 192.168.0.5>] sent [IPCP ConfAck id=0x2 <addr 192.168.2.2> <compress VJ 03 01> <ms-dns1 192.168.0.5> <ms-dns3 192.168.0.5>] rcvd [IPCP ConfAck id=0x2 <addr 192.168.2.1> <compress VJ 03 01>] Cannot determine ethernet address for proxy ARP local IP address 192.168.2.1 remote IP address 192.168.2.2
To test that a network connection is working OK between the two machines, trying using the ping command from your PC
% ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2): 56 data bytes 64 bytes from 192.168.2.2: icmp_seq=0 ttl=255 time=77.8 ms 64 bytes from 192.168.2.2: icmp_seq=1 ttl=255 time=80.5 ms 64 bytes from 192.168.2.2: icmp_seq=2 ttl=255 time=78.3 ms
Your Palm Pilot should now be able to access network resources on your PC. To make it able to access resources elsewhere on your network, other machines need to know that your Bluetooth host is the place to go for the 192.168.2.* subnet (for instance.) One solution is to add a static route in, with a command like this:
route add -net 192.168.2.0 netmask 255.255.255.0 gw your-hostname
Obviously, adjust for your own values. (On my Debian machines I've added this command into /etc/network/interfaces as an "up" parameter for eth0 so the route gets added in when the network is brought up.)
A more sensible solution for a normal network is to configure the Linux PC to do network address translation (NAT). This makes all the Pilot's requests look like they're coming from the PC itself, so there's no need to add in extra routes or eat up network-wide IP addresses. The downside to this is that you can't run servers on your Palm Pilot. For more information on NAT check out the BlueZ HOWTO and also your Linux distribution's documentation for iptables and/or ipmasq.
If you get stuck on anything in this section, it's probably because I've rushed through the details of setting up a PPP connection. The best place to go for help is the Linux PPP HOWTO.
It won't have escaped your notice that the routine of hitting a button on the Palm then enter on the keyboard is a bit hit-and-miss. It would be better if the Palm could access the computer link whenever it wanted. I hacked together this bash script, which I have running permanently. This is not an elegant solution, but it's the best that can be done with the current software.
PALM_BD=00:02:81:24:07:8A
DNS_SERVER=192.168.0.5
LOCAL_IP=192.168.2.1
REMOTE_IP=192.168.2.2
while :; do \
rfcomm 0 $PALM_BD & \
rfcommpid=$! ; \
pppd /dev/ttyU0 nodetach debug local $LOCAL_IP:$REMOTE_IP \
ms-dns $DNS_SERVER ; \
kill $rfcommpid ; \
done
Once your Palm is network enabled, you'll likely want to synchronize it over the network. This is (mostly) easy, but can require a little tweaking. As with Bluetooth, some of the GNOME Palm Pilot interfacing software is early stage. On the PC side, you need to do the following (disclaimer, this is what I did to make it work, you may need to do more or less work):
Add a name record into your DNS for the PC Bluetooth network interface. I have something like this in my file for the 192 network:
1.2.168 IN PTR bt-pc.heddley.com.
Restart your DNS. Now it's time to configure the GNOME pilot daemon,
gpilotd. I'm presuming you were synchronizing your Pilot with GNOME
via the cradle before you came to this. If not, it might be best to go
familiarize yourself with that before proceeding. Make sure
gpilotd isn't running and then edit your
~/.gnome/gnome-pilot.d/gpilotd file. Amend the Device0
entry (or whichever one corresponds to the Pilot you wish to move to network
sync) to read:
[Device0] type=4 name=MyPilot ip=192.168.2.2 host=pilot netmask=255.255.255.0 timeout=2
Make sure you use your corresponding values for the ip and netmask parameters. As far as I can tell, the value of the host field is unimportant if the ip parameter is set correctly.
You can restart gpilotd now. Note that due to a bug in the
GNOME 1.4 Palm configuration software these preferences will not be preserved
if you try and configure the Palm via the GNOME Control Center. In fact, it's
easy to make gpilotd crash that way.
Now you have to configure the Palm side. Start the HotSync application. Ensure the "Modem" method of synchronizing is highlighted. From the "Modem Sync Prefs" menu item, ensure "Network" is highlighted. In the Primary PC Setup menu item, type in the hostname of your PC (bt-pc.heddley.com in my case), its IP address (e.g. 192.168.2.1), and the netmask. And from the "Connection Setup" menu item, ensure that the "Bluetooth PPP" connection you prepared earlier is selected.
All should be ready then for you to hit the HotSync icon, and a network synchronization should start.
Running Bluetooth on Linux right now definitely counts as a "cutting edge" activity, but it is possible with a little patience.
I've not touched on security or authentication of the Bluetooth connection here, and I've only presented the most straightforward approach to networking your Palm. Playing around with BlueZ and reading up on Linux networking should benefit you if you want to try more robust configurations.
I'd welcome all comments and suggestions on how to improve this document. Please send them to me at the email address below. Unfortunately I don't have the time to take on everyone's problems individually: the bluez-users and gnome-pilot mailing lists would probably be the best place to ask for help.
Thanks to Ilguiz Latypov for his help, and to Maksim Krasnyanskiy, Marcel Holtmann and the rest of the BlueZ developers.
-- Edd Dumbill
This document was written by and is copyright 2002 Edd Dumbill. Contact me by sending email to edd at usefulinc dot com.
$Log: linuxBlade-howto.html,v $Revision 1.4 2002/09/18 10:36:01 edmundd*** empty log message ***Revision 1.3 2002/03/06 00:48:17 edmundd Added in documentation to cover rfcommd now that it works. Revision 1.2 2002/03/04 23:53:35 edmundd First public version. Revision 1.1 2002/03/04 13:08:07 edmundd Initial version