Tom's attempts to get GPRS working over bluetooth with his laptop

From: http://www.teaparty.net/technotes/blue-gprs.html
Last updated: $Date: 2008/11/28 13:56:01 $
Dramatis apparatus:

Sony VAIO C1F picturebook with RH80 and 2.4.20 kernel (handbuilt)

3Com Bluetooth card 3CRWB6096

Nokia 6310i GSM 'phone subscribed to Orange (UK)

Note from later: I am still using this basic technique, with an Asus S6F laptop running Fedora Core 6 on a stock 2.6.18-1.2849.fc6 kernel, plus a Nokia 6230i 'phone. Most of this document still applies, but you can read FC6-specific notes here . I also no longer need to build the rfcomm module into the kernel, as it ships with the stock RH kernel.
Note from much later (20081128): I am now using an openmoko GSM phone. i still have connectivity working, but the mechanics are somewhat different as the 'moko is physically connected to my laptop via usb instead of wirelessly via bluetooth, and it is running linux in its own right, so is used as a router and NAT device as well as a serial wireless internet connectivity device. If this interests you, please see the relevant writeup here .
This joyous expedition comes in stages:

Getting Bluetooth support into the kernel

Talking to my 'phone

Bringing up GPRS service

Kernel
From bluez.sf.net , I downloaded and installed the following packages: bluez-libs-2.3-1 bluez-utils-2.2-1 bluez-sdp-1.0rc2-1 bluez-bluefw-0.9-1 The last being firmware loading code specific to the 3Com card (and others using the bt3c_cs driver). I added to /etc/modules.conf

# bluetooth stuff
alias net-pf-31 bluez
alias bt-proto-0 l2cap
alias bt-proto-2 sco
alias bt-proto-3 rfcomm

This is from the Bluez user HOWTO .
With this all in place, I start bluetooth services

# /etc/rc.d/init.d/bluetooth start

and insert the 3Com card. Syslog notes:

cardmgr[602]: socket 0: 3Com Bluetooth PC Card
cardmgr[602]: executing: 'modprobe bt3c_cs'
bluefw[3859]: Loading firmware to pccard device 0101:0040
hcid[3784]: HCI dev 0 registered
cardmgr[602]: executing: './bluetooth start hci0'
/sbin/hotplug: no runnable /etc/hotplug/bluetooth.agent is installed
hcid[3784]: HCI dev 0 up

I verify card operation with

# hciconfig
hci0:   Type: PCCARD
        BD Address: 00:04:76:C8:D3:E3 ACL MTU: 128:8  SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN 
        RX bytes:112 acl:0 sco:0 events:12 errors:0
        TX bytes:308 acl:0 sco:0 commands:12 errors:0

(this shows DOWN if the hcid daemon isn't running; it can be manually brought up with "hciconfig hci0 up".
I activate bluetooth on my 'phone (which has been configured to have the name "Tom's phone" under Bluetooth->Bluetooth settings->My phone's name), and can find it with

# hcitool scan
Scanning ...
        00:02:EE:60:97:6E       Tom's phone

Other options to verify functionality thus far include asking if there are any dialup networking devices out there (there had bloody better be, it's a 'phone). Incidentally, i hate "dialup networking". What's wrong with "modem"?

# sdptool search DUN
Inquiring ...
Searching for DUN on 00:02:EE:60:97:6E ...
Service Name: Dial-up networking
Service RecHandle: 0x10031
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

I can even bluetooth-ping the 'phone to verify connectivity

# l2ping 00:02:EE:60:97:6E
Ping: 00:02:EE:60:97:6E from 00:04:76:C8:D3:E3 (data size 20) ...
0 bytes from 00:02:EE:60:97:6E id 200 time 39.76ms
0 bytes from 00:02:EE:60:97:6E id 201 time 35.67ms
0 bytes from 00:02:EE:60:97:6E id 202 time 32.21ms
3 sent, 3 received, 0% loss

Here, I gave a ^C after 3 packets.
Talking to the 'phone
Now, we have to talk to the 'phone's onboard modem. I tried

# rfcomm bind 0 00:02:EE:60:97:6E 1

and got this error at the prompt

Can't open RFCOMM control socket: No such file or directory

and syslog immediately complained

modprobe: Can't locate module bt-proto-3

Digging on the net found www.holtmann.org/linux/kernel/ , which outlined how 2.4.20 (stock) kernel doesn't contain the rfcomm code. Downloaded thence the latest Marcel Holtmann rfcomm patch, being 2.4.20-mh4. Applied to kernel source

# cd /usr/src
# patch -p0 < /tmp/patch-2.4.20-mh4

went to kernel source dir, menuconfig'ged, and lo, the RFCOMM options appeared. Turned on RFCOMM and BNEP, and all associated checkboxes, did

# make dep
# make bzImage && make modules && make modules_install

Booted from new kernel (2.4.20-mh4), did

# rfcomm bind  0 00:02:EE:60:97:6E 1

got nothing at prompt, but syslog shows

kernel: BlueZ RFCOMM ver 0.4
kernel: Copyright (C) 2002 Maxim Krasnyansky 
kernel: Copyright (C) 2002 Marcel Holtmann 

as the driver is force-loaded, and i can also do

# rfcomm show
rfcomm0: 00:02:EE:60:97:6E channel 1 clean 

But I could find no device to attach minicom to, for testing. Digging revealed that the device special files are major number 216, so after I did

mknod /dev/rfcomm0 c 216 0

I was able to use minicom to initiate a connection to the phone on device /dev/rfcomm0, at 9600 baud, with software flow control. My 'phone immediately asked me if I wanted to pair with my laptop (I said yes), and then asked me for a PIN before immediately giving me a disconnect message.
Examining the /etc/bluetooth/hcid.conf file revealed a line of code defining a "pin helper", which when i ran it gave a GTK error. Assuming this might be breaking things, I replaced it with a small script /etc/bluetooth/bluepin (and declared that in hcid.conf, restarting hcid), which said simply

#!/bin/bash
echo "PIN:00"

Yes, this is a pathetic PIN, but I found i only had a second or so to type it in before the 'phone dropped the connection on me. Maik Musall kindly suggests an elegant alternative:

> In the page, you mention your "00" pin that you took because you
> had just a second to enter a pin. I have a solution: do not use
> minicom for the first connect but a simple
>
> cat < /dev/ttyUB0
> 
> or whatever the device is in your case. This ensures that a connect
> takes place without sending any characters before the pin is 
> confirmed. With that, I had any time to enter a longer pin on
> my 6310i. Then, in the phone, go to the trusted devices and disable
> the pin enforcement, and you can connect easily from then on.

I have not tried this (yet), and at the time it did not occur to me, so I settled for a lame PIN. Once I got it typed in, the 'phone seemed happy to accept the connection and establish the pairing (syslog reported

Jan  5 19:51:30 tirith hcid[20134]: Saving link key 00:04:76:C8:D3:E3 00:02:EE:60:97:6E 

which looks good). Minicom was now able to talk to the onboard modem and get simple AT-OK responses. I told it ATDT01223999999 (substituting my home telephone number for 01223 999999), and my home 'phone rang. So, I'm definitely able to talk to the 'phone.
Using the GPRS
I sent it some GPRS-type messages, cargo-culted from here , which went like:

at
OK
ate1
OK
at+cgdcont=1,"IP","orange.co.uk","",0,0
OK
atd*99***1#
NO CARRIER

The 'phone dutifully displayed a "no GPRS service available" message, so I suspect that I am correctly telling it to use GPRS, and it is correctly telling me that I haven't registered for GPRS service. Now, I have to talk to Orange to get them to turn on GPRS service for me.
Having spoken to my provider (Orange UK), and spoken to someone who was clueful enough to know what I was after when I asked for AT modem commands, and with the help of the page mentioned immediately above, I got it working.
Here's my pppd peers file (/etc/ppp/gprs ):

/dev/rfcomm0 57600 
connect '/usr/sbin/chat -v -f /etc/ppp/chat-gprs'
noauth
defaultroute
debug

and here's my chat script (/etc/ppp/chat-gprs ):

TIMEOUT         5
ECHO            ON
ABORT           '/nBUSY/r'
ABORT           '/nERROR/r'
ABORT           '/nNO ANSWER/r'
ABORT           '/nNO CARRIER/r'
ABORT           '/nNO DIALTONE/r'
ABORT           '/nRINGING/r/n/r/nRINGING/r'
''              /rAT
TIMEOUT         12
OK              ATE1
OK              'AT+cgdcont=1,"IP","orangeinternet"'
OK              ATD*99***1#

Note the lack of authentication. It seems that the 'phone itself is authenticated by the network, which is (I suppose) the point! To make a connection, I use rfcomm release 0; rfcomm bind 0 00:02:EE:60:97:6E 1 then type pppd call gprs . The 'phone immediately wants to confirm a Bluetooth connection from my laptop, which I permit.
Update, 2004 09 06: [email protected] reports good results with the following script, which I report verbatim:
OK 'AT&F'
OK 'ATV1E0S0=0&D2&C1'
OK AT+CMEE=1
OK 'AT+cgdcont=10,"IP","orangeinternet"'
OK-AT-OK ATD*99***10#
CONNECT ""
After a short delay, pppd logs the following to syslog:

pppd[22167]: Serial connection established.
pppd[22167]: Using interface ppp0
pppd[22167]: Connect: ppp0 <--> /dev/rfcomm0
[...]
pppd[22167]: local  IP address 172.23.201.2
pppd[22167]: remote IP address 10.6.6.6

a small G appears at the top left-hand corner of the 'phone display, which I understand shows that a GPRS conection has been made, and I can route to the outside world. My provider seems to be filtering pings, but I can (for example) make a TCP connection to port 22 on an ssh server I use, and I can use DNS to resolve off my favourite server outside, so I conclude that it works.
For anyone who's curious about numbers, I am on orange's cheapest plan, which is GBP4 (about 6 Euros) a month for 0.5MB. orange say (7.1.2003) that traffic over the plan limit is charged by the kB, pro rata the main plan rate. We'll see how much traffic I use: my main usage is ssh, which isn't all that big; 0.5MB would vanish in a heartbeat with web browsing, though.
And that's it. Unless anything stops working, that's the end of this technote.