Of Linux, GPRS Phones, Serial Cable, Irda, Bluetooth and USB

2.2.1. Use with serial cable

Connect your phone with RS-232 serial cable to the serial port one (Linux /dev/ttyS0, Windows COM1). Start pppd with the GPRS scripts as root:

	# pppd call gprs
      

The pppd stays on the shell screen, so you can terminate the connection at any time by pressing CTRL-C.

Now, you should see the AT commands and pppd debug output on your terminal. If all goes well, your ifconfig on another terminal shows the GPRS connection as ppp0 and route -n shows the ppp0 IP address as the default gateway.

Here's an example log with Nokia 30, serial cable and Radiolinja:

# pppd call gprs
Press CTRL-C to close the connection at any stage!
defining PDP context...
~AT
OK
ATE1
OK
AT+CGDCONT=1,"IP","internet","",0,0
OK
waiting for connect...

ATD*99***1#
CONNECT
Connected.
If the following ppp negotiations fail,
try restarting the phone.

Serial connection established.
using channel 10
Using interface ppp0
Connect: ppp0 <--> /dev/ttyS1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x23e95889>]
rcvd [LCP ConfRej id=0x1 <magic 0x23e95889>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
sent [PAP AuthReq id=0x1 user="rlnet" password="internet"]
sent [PAP AuthReq id=0x2 user="rlnet" password="internet"]
rcvd [PAP AuthAck id=0x2 ""]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 
0.0.0.0>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfNak id=0x0 <addr 10.0.0.1>]
rcvd [LCP ProtRej id=0x0 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
rcvd [IPCP ConfNak id=0x1 <addr 10.68.0.64> <ms-dns1 213.161.33.200> 
<ms-dns3 212.226.226.1>]
sent [IPCP ConfReq id=0x2 <addr 10.68.0.64> <ms-dns1 213.161.33.200> 
<ms-dns3 212.226.226.1>]
rcvd [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfAck id=0x1 <addr 10.0.0.1>]
rcvd [IPCP ConfAck id=0x2 <addr 10.68.0.64> <ms-dns1 213.161.33.200> 
<ms-dns3 212.226.226.1>]
local  IP address 10.68.0.64
remote IP address 10.0.0.1
primary   DNS address 213.161.33.200
secondary DNS address 212.226.226.1
Script /etc/ppp/ip-up started (pid 2473)
Script /etc/ppp/ip-up finished (pid 2473), status = 0x0
        

You can also ping some Internet host to see if the connection is really set up properly, but some networks and hosts may not reply to ICMP echo requests because of security issues. At the time of writing at least www.ericsson.com ping's back through the Radiolinja network:

# ping www.ericsson.com
PING a1762.g.akamai.net (195.197.54.135) from 10.68.0.64 : 56(84) bytes of data.
64 bytes from a195-197-54-135.deploy.akamaitechnologies.net 
(195.197.54.135): icmp_seq=0 ttl=250 time=639.090 msec

--- a1762.g.akamai.net ping statistics ---
10 packets transmitted, 2 packets received, 80% packet loss
round-trip min/avg/max/mdev = 639.090/814.522/989.955/175.434 ms
      

Testing the network connecion may be a bit difficult, since some GPRS networks may only allow WWW access (TCP port 80) to the Internet, and even those connections may be behind a hidden WWW-proxy. Therefore, testing should be carried out with ping to see if just might work, traceroute -I to see where the packets get dropped and with a browser like lynx or links to see if you're behind a nasty proxy. If all of these fail, then perhaps the problem is in the name server configuration (try to resolve some name like host www.ericsson.com) or routing tables (what is the default route, see with route -n) or finally even in the GPRS phone or scripts (check the phone display for GPRS signs, reboot the phone, even take the battery out, double check the scripts and settings and see the system logs at /var/log/messages). A personal computer attached to a cellular phone connected to a large network can be a very unstable system as a whole, from an Internet users perspective.

2.3.1. Setup IrDA on the Linux machine

This part can be tricky, so see the relevant howto's and web pages. If all is setup up correctly /etc/rc.d/init.d/irda start would set irda up. With RedHat 7.1 on an HP OmniBook 4150 I got the IrDA port working manually like this:

• enable SIR (Serial IR) IrDA from bios, defaults to 0x2F8h and IRQ 3

• add following lines to /etc/modules.conf: alias char-major-161 ircomm-tty, alias tty-ldisk-11 irtty

• the kernel modules exist for the standard RedHat kernel so no compiling is needed, and also the /dev/ir* device files exist

• load the needed modules with insmod:

  # insmod irda
  # insmod irtty
  # insmod ircomm
              

• do the IrDA attachment to the new ttyS1 device (see dmesg before and after the IrDA bios enabling to get the correct serial device number)

  # irattach /dev/ttyS1 -s 1
              

• see from /var/log/messages that IrDA is ok

• enable the phones IrDA and check if you can see it with irdadump

• test the IrDA serial connection and AT commands with minicom, remember to set HW flow control off in settings:

  # minicom /dev/ircomm0
              

Now it should work. If not, RTFM and search the net.

2.3.2. IrDA setup for buggy SonyEricsson t68i, T300 etc. phones and buggy Linux kernel

While upgrading the Linux kernel from 2.4.18 to 2.4.20 (actually the corresponding RedHat versions), I suddenly got a non-working IrDA setup. The reasons behind this were two bugs in the SonyEricsson t68i and one little and quickly fixed bug in the Linux kernel IrDA stack. The Linux IrDA maintainer Jean Tourrilhes had a fix for these ready on his web site (search for "ericsson phones"), but I'm writing the short instructions here too:

• Use the latest kernel version possible, at least 2.4.22. If your distribution has an older base line, then compile your own from the latest vanilla tree.

• From the command line, the Linux IrDA stack can be adjusted for the buggy Ericsson's with these commands:

  # echo 1000 > /proc/sys/net/irda/min_tx_turn_time
  # echo 1 > /proc/sys/net/irda/max_tx_window

• Use sysctl to automate these parameters, man sysctl and man sysctl.conf will help.

The odd part with these bugs was that the IrDA connection worked (when worker, it was rather unstable) with very strange serial port settings: the parity check bit had to be set to Even instead of the usual None (8E1 instead of the usual 8N1).

2.3.3. GPRS settings with IrDA

Edit (mainly comment and uncomment) the /etc/ppp/peers/gprs file for IrDA. Here's a stripped example configuration:

...
#/dev/ttyS0     # serial port one
#/dev/ttyS1     # serial port two
/dev/ircomm0    # IrDA serial port one
#/dev/ttyUB0    # Bluetooth serial port one
...
#115200		# fast enough
57600		# perhaps usefull with IrDA
...
#crtscts  # serial cable and Bluetooth
nocrtscts # IrDA
...
          

2.4.1. Setup Bluetooth on the Linux machine

This part is tricky, but here's how I did it. I started of with RedHat Linux 7.3 with upgrades like the 2.4.18-10 kernel, but after enough trials and errors I went to the vanilla 2.4.19 kernel. My latest setups use Debian testing/unstable with the 2.6 kernel series.

There are many Bluetooth stacks availabel for Linux, but I desided to try Bluez, which is default Bluetooth stack in 2.6 kernel series. The Bluetooth device I use is a Racewood Bluetooth USB dongle.

# grep -i blue /usr/src/linux-2.4.19/.config
CONFIG_USB_BLUETOOTH=m # Don't use this option with Bluez Bluetooth!
# Bluetooth support
CONFIG_BLUEZ=m
CONFIG_BLUEZ_L2CAP=m
CONFIG_BLUEZ_SCO=m
# Bluetooth device drivers
CONFIG_BLUEZ_HCIUSB=m
# CONFIG_BLUEZ_USB_FW_LOAD is not set
# CONFIG_BLUEZ_USB_ZERO_PACKET is not set
# CONFIG_BLUEZ_HCIUART is not set
# CONFIG_BLUEZ_HCIDTL1 is not set
# CONFIG_BLUEZ_HCIVHCI is not set
          

---

2.4.1.2. Bluez modules, programs and some testing

Next I downloaded the Bluez sources from bluez.sourceforge.net

I did a ./configure && make && make install for all of these:

bluez-kernel-2.3.tar.gz create_dev script was not in this archive, but in Bluez CVS, see the README file
bluez-libs-2.2.tar.gz
bluez-utils-2.1.tar.gz
bluez-sdp-0.8.tar.gz
bluez-pan-1.1-pre1.tar.gz
bluez-hcidump-1.3.tar.gz
bluez-hciemu-1.0.tar.gz
bluez-bluefw-0.7.tar.gz
          

And now I have the hciconfig, hcitool and rfcomm programs and all the needed Bluez kernel modules installed. Take a look at the README's for each of the Bluez modules, since you may also need to create the device files (the create_dev script in bluez-kernel) and add the this kind of lines to /etc/modules.conf:

# For Bluez Bluetooth stack
alias net-pf-31 bluez
alias bt-proto-0 l2cap
alias bt-proto-2 sco
alias bt-proto-3 rfcomm
alias bt-proto-4 bnep

# for Bluetooth UARTs
alias tty-ldisc-15 hci_uart
          

Then do a depmod -a and plug in the Bluetooth dongle. At least mine lights a green led to tell [I've got power!]. Then I did a /etc/rc.d/init.d/bluetooth start and /var/log/messages shows these messages:

Nov  5 22:34:13 ransu hcid[5600]: HCI daemon ver 2.1 started
Nov  5 22:34:14 ransu bluetooth: hcid startup succeeded
Nov  5 22:34:14 ransu kernel: BlueZ Core ver 2.2 Copyright (C) 2000,2001 Qualcomm Inc
Nov  5 22:34:14 ransu kernel: Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
Nov  5 22:34:14 ransu bluetooth: sdpd startup succeeded
Nov  5 22:34:14 ransu kernel: BlueZ L2CAP ver 2.1 Copyright (C) 2000,2001 Qualcomm Inc
Nov  5 22:34:14 ransu kernel: Written 2000,2001 by Maxim Krasnyansky <maxk@qualcomm.com>
Nov  5 22:34:14 ransu sdpd[5606]: SDPd ver 0.8 started 
          

And with lsmod I can see that the basic Bluez modules have been loaded:

l2cap                  17408   1  (autoclean)
bluez                  35048   1  (autoclean) [l2cap]
usbcore                76992   1 
          

Then I manually load the USB Bluetooth drivers and try the hciconfig tool:

# modprobe hci_usb
# modprobe usb-uhci
# hciconfig 
hci0:   Type: USB 
        BD Address: 00:08:1B:00:1B:E7 ACL MTU: 192:8  SCO MTU: 64:8
        UP RUNNING PSCAN ISCAN 
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:0 acl:0 sco:0 commands:0 errors:0
          

For some reason the USB dongle does not work right after loading modules the hciconfig outputs a 00:00:00:00:00:00 address to the card. The dongle did wake up after I did a hciconfig hci0 down && hciconfig hci0 up.

Now the device should be up and running and /var/log/messages and dmesg also show a great deal of info about the USB Bluetooth device. With hcitool I can now see my phone, which has Bluetooth on, and I can even l2ping it:

# hcitool inq
Inquiring ...
        00:02:EE:69:E7:BD       clock offset: 0x13e4    class: 0x502204
# l2ping 00:02:EE:69:E7:BD
Ping: 00:02:EE:69:E7:BD from 00:08:1B:00:1B:E7 (data size 20) ...
0 bytes from 00:02:EE:69:E7:BD id 200 time 26.47ms
0 bytes from 00:02:EE:69:E7:BD id 201 time 40.73ms
0 bytes from 00:02:EE:69:E7:BD id 202 time 30.54ms
0 bytes from 00:02:EE:69:E7:BD id 203 time 38.35ms
4 sent, 4 received, 0% loss
          

sdptool (Service Discovery Protocol tool) can be used to find a GPRS modem offering Bluetooth Dial-Up Networking profile. The Bluetooth channel number is important for configuring the rfcomm Bluetooth serial port connection.

# sdptool search DUN
Inquiring ...
Searching for DUN on 00:0E:ED:0F:D2:DD ...
Service Name: Dial-Up Networking
Service RecHandle: 0x10005
Service Class ID List:
  "Dialup Networking" (0x1103)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 2
Language Base Attr List:
  code_ISO639: 0x454e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100
	  

---

2.4.1.3. Bluez configuration

Bluez installs the config files to /etc/bluetooth:

# ls -l /etc/bluetooth/
total 20
drwxr-xr-x    2 root     root         4096 Oct 30 00:27 firmware
-rw-r--r--    1 root     root         1371 Oct 29 19:24 hcid.conf
----------    1 root     root           36 Oct 30 00:43 link_key
-rw-------    1 root     root            7 Oct 30 00:07 pin
-rw-r--r--    1 root     root          329 Nov  5 17:44 rfcomm.conf
          

The default settings in hcid.conf were fine for me, but the phones address and DUN channel number need to be added to the rfcomm.conf. This how my rfcomm.conf looks like:

rfcomm0 {
        # Automatically bind the device at startup
        bind yes;

        # Bluetooth address of the device
        device 00:02:EE:69:E7:BD;

        # RFCOMM channel for the connection
        channel 1;

        # Description of the connection
        comment "Nokia 7650";
}
          

To automatically connect the to the phone with Bluetooth RFCOMM, put rfcomm bind all command to the end of the start function in /etc/rc.d/init.d/bluetooth and rfcomm release all command to the end of stop function. Here is a snippet of my /etc/rc.d/init.d/bluetooth file:

...
start()
{
        echo -n $"Starting $prog: "
        daemon /sbin/hcid

        if [ -x /usr/sbin/sdpd ]; then
                daemon /usr/sbin/sdpd
        fi

        start_uarts
        touch /var/lock/subsys/bluetooth
        # bind all rfcomm connectins from /etc/bluetooth/rfcomm.conf
        rfcomm bind all
        echo
}
stop()
{
        echo -n $"Shutting down $prog: "
        killproc hcid

        if [ -x /usr/sbin/sdpd ]; then
                killproc sdpd
        fi

        stop_uarts
        rm -f  /var/lock/subsys/bluetooth
        # release all rfcomm connections
        rfcomm release all
        echo
}
...
          

/etc/bluetooth/pin holds the pin code which you need to type on the phone when the two Bluetooth devices are paired. Change the value to something more unpredictable than 1234.

When the Bluetooth subsystem is now restarted with /etc/rc.d/init.d/bluetooth restart, the rfcomm connection should be binded automatically even if no Bluetooth devices are connected to the Linux machine:

# /etc/rc.d/init.d/bluetooth restart
Shutting down Bluetooth:                                   [  OK  ]
Starting Bluetooth:                                        [  OK  ]
# rfcomm
rfcomm0: 00:02:EE:69:E7:BD channel 1 clean
          

To automatically start the Bluetooth at boot time, add a symlink from the corresponding run level directory to the bluetoot startup script:

# ln -s /etc/rc.d/init.d/bluetooth /etc/rc5.d/K90bluetooth
          

At this point, when the bluetooth daemons are up and running, it may be wise to pair the phone and the Linux host. With Nokia 7650 it goes something like this: start Bluetooth from the phone, scan for other Bluetooth hosts, select the Linux host, insert the correct pin (the same is in /etc/bluetooth/pin) and set the host as 'Authorized'. The authorized part means, that the phone does not ask for a pin code anymore. This is insecure but handy when testing the Bluetooth connection.

---

2.4.1.3.1. Sending and receiving files with Nokia 7650

There are a few good documents in the net on how to use Bluetooth OBEX with mobile devices: http://www.frasunek.com/HOWTO-Nokia7650-Bluetooth.txt and http://www.iterationx.org/essays/2002/10/21/. At the time of writing this in 2003, the above HOWTO's do not show howto automatically setup the Bluetooth connections with OBEX, so I decided to write it down here.

So, to send and receive files with the OBEX protocol, the Linux host needs the OpenOBEX library and OpenOBEX applications from http://openobex.sourceforge.net/ and ussp-push application from http://www.unrooted.net/hacking/bluez-rfcomm-obex.html. Compile and install the OpenOBEX library and applications and the ussp-push tool, #./configure && make should do it.

On a resent (2004) Debian unstable/testing setup, the file transfer over Bluetooth is quite easy. Install Bluez and OpenOBEX libraries and the obexserver package. After that man obexserver will show howto receive data from a phone like the Nokia 7650. Other openobex applications like KDE Bluetooth might enable sending data from the computer to the phone too, I haven't tried those so much yet.

2.4.2. GPRS settings with Bluetooth

Edit (mainly comment and uncomment) the /etc/ppp/peers/gprs file for Bluetooth. Here's a stripped example configuration:

...
#/dev/ttyS0     # serial port one
#/dev/ttyS1     # serial port two
#/dev/ircomm0   # IrDA serial port one
/dev/rfcomm0    # Bluetooth serial port one
...
115200		# fast enough
#57600		# perhaps usefull with IrDA
...
crtscts  # serial cable and Bluetooth
#nocrtscts # IrDA
...
        

Now you should, fingers crossed, be able start the Bluetooth GPRS connection.

2.4.3. Use with Bluetooth

If the bluetooth daemons are not running yet, start them and try opening the connection:

# /etc/rc.d/init.d/bluetooth start
Starting Bluetooth:                                        [  OK  ]
# pppd call gprs
Press CTRL-C to close the connection at any stage!
defining PDP context...
rAT
OK
ATH
OK
ATE1
OK
AT+CGDCONT=1,"IP","internet","",0,0
OK
waiting for connect...

ATD*99***1#
CONNECT
Connected.
Connected.
If the following ppp negotiations fail,
try restarting the phone.

Serial connection established.
using channel 4
Using interface ppp0
Connect: ppp0 <--> /dev/rfcomm0
rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4df00a4b>]
sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
rcvd [LCP ConfRej id=0x1 <magic 0x4df00a4b>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
sent [PAP AuthReq id=0x1 user="rlnet" password="internet"]
rcvd [PAP AuthAck id=0x1 ""]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
sent [IPCP ConfNak id=0x0 <addr 10.0.0.1>]
rcvd [LCP ProtRej id=0x0 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 10.64.1.141> <ms-dns1 213.161.33.200> <ms-dns3 212.226.226.1>]
sent [IPCP ConfReq id=0x2 <addr 10.64.1.141> <ms-dns1 213.161.33.200> <ms-dns3 212.226.226.1>]
rcvd [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
sent [IPCP ConfAck id=0x1 <addr 10.0.0.1>]
rcvd [IPCP ConfAck id=0x2 <addr 10.64.1.141> <ms-dns1 213.161.33.200> <ms-dns3 212.226.226.1>]
local  IP address 10.64.1.141
remote IP address 10.0.0.1
primary   DNS address 213.161.33.200
secondary DNS address 212.226.226.1
Script /etc/ppp/ip-up started (pid 2119)
Script /etc/ppp/ip-up finished (pid 2119), status = 0x0
      

So the pppd scripts seem to work. Verify the connectin with ping:

# ping www.ericsson.com
PING a1762.g.akamai.net (195.197.54.137) from 10.68.0.29 : 56(84) bytes of data.
64 bytes from a195-197-54-137.deploy.akamaitechnologies.net 
(195.197.54.137): icmp_seq=0 ttl=250 time=832.947 msec
64 bytes from a195-197-54-137.deploy.akamaitechnologies.net 
(195.197.54.137): icmp_seq=1 ttl=250 time=627.201 msec

--- a1762.g.akamai.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/mdev = 627.201/798.043/933.983/127.655 ms
      

Everything is now setup. Just go surfing!

2.5.1. USB device configuration for Siemens C55

I have not had this C55 in my hands for testing, but Kaj Barck and numerous other people have told me that it works with the USB cable. The only real details here are to use the pl2303 driver with a command like # modprobe pl2303, create device files according to the fine kernel documentation at Documentation/usb/usb-serial.txt and use GPRS scripts with /dev/ttyUSB0 serial port.

This description may be distribution, kernel version etc. specific, so Linux USB site may be of help.

2.5.2. USB device configuration for Orange SPV

When I connected an Orange SPV to my RedHat 8.0 Linux box with the USB cable, /var/log/messages shows the manufacturer and device id's:

Apr 10 20:50:50 ransu kernel: hub.c: USB new device connect on bus2/2, assigned
device number 23
Apr 10 20:50:50 ransu kernel: usb.c: USB device 23 (vend/prod 0xbb4/0xce) is not claimed by any active driver.
Apr 10 20:50:53 ransu /etc/hotplug/usb.agent: ... no modules for USB product bb4/ce/0

So, the device id's are visible, but none of the hotplug scripts know which driver could use it. Not a surprise, but the id's are according to http://www.linux-usb.org/usb.ids identical to the O2's Xda:

0bb4  High Tech Computer Corp.
        00ce  mmO2 XDA GSM/GPRS Pocket PC
        

After reading about USB serial drivers from Linux kernel document Documentation/usb/usb-serial.txt, I tried usbserial driver with the vendor and product id's given by the USB logs:

# modprobe usbserial vendor=0x0bb4 product=0x00ce
        

Looking at /var/log/messages, the driver seems to have loaded well:

Apr 10 20:59:03 ransu kernel: usb.c: registered new driver serial
Apr 10 20:59:03 ransu kernel: usbserial.c: USB Serial support registered for Generic
Apr 10 20:59:03 ransu kernel: usbserial.c: Generic converter detected
Apr 10 20:59:03 ransu kernel: usbserial.c: Generic converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Apr 10 20:59:03 ransu kernel: usbserial.c: USB Serial Driver core v1.4
        

A trial with minicom on the device /dev/ttyUSB0 shows that the connection to the phone actually works, wow!

Note that the phones Modem Link must be activated from Programs-Accessories-Modem Link with USB before it answers to AT commands.

2.5.3. GPRS setup for USB

I chose to use wvdial with the SPV because chat didn't work for me at all. The reason might be my own manual and screwed up upgrade from RedHat 7.3 to 8.0. See the gprs-wvdial.conf for the initialisation commands. The pppd configuration is very similar to the other cases, since only the device file changes to /dev/ttyUSB0 and connect script changes to gprs-wvdial.conf. Here's a stripped down configuration for Orange SPV as a USB serial device:

...
# Connect script:
# scripts to initialize the GPRS modem and start the connection,
# wvdial command is for Orange SPV while other phones should work with chat
#connect /etc/ppp/peers/gprs-connect-chat
connect "/usr/bin/wvdial --chat --config /etc/ppp/peers/gprs-wvdial.conf radiolinja_usb_orange_spv"
...
# Serial device to which the GPRS phone is connected:
# /dev/ttyS0 for serial port (COM1 in Windows),
# /dev/ircomm0 for IrDA,
# /dev/ttyUB0 for Bluetooth (Bluez with rfcomm running) and
# /dev/ttyUSB0 for USB
#/dev/ttyS0     # serial port one
#/dev/ttyS1     # serial port two
#/dev/ircomm0   # IrDA serial port one
#/dev/rfcomm0   # Bluetooth serial port one
/dev/ttyUSB0    # USB serial device, for example Orange SPV
...

Here is dump of a successfull GPRS connection:

# pppd call gprs
--> WvDial: Internet dialer version 1.53
--> Initializing modem.
--> Sending: ATH
ATH
OK
--> Sending: ATE1
ATE1
OK
--> Sending: AT+CGDCONT=1,"IP","internet","",0,0
AT+CGDCONT=1,"IP","internet","",0,0
OK
--> Modem initialized.
--> Sending: ATD*99#
--> Waiting for carrier.
ATD*99#
CONNECT
--> Carrier detected.  Waiting for prompt.
~[7f]}#@!}!}.} }-}#}%B#}%}'}"}(}"[0f]J~
--> PPP negotiation detected.
Serial connection established.
using channel 7
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
--> PPP negotiation detected.
Serial connection established.
using channel 8
Using interface ppp0
Connect: ppp0 <--> /dev/ttyUSB0
rcvd [LCP ConfReq id=0x11 <auth chap MD5> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x9c88f8d9>]
sent [LCP ConfRej id=0x11 <pcomp> <accomp>]
rcvd [LCP ConfRej id=0x1 <magic 0x9c88f8d9>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
rcvd [LCP ConfReq id=0x12 <auth chap MD5>]
sent [LCP ConfAck id=0x12 <auth chap MD5>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
rcvd [CHAP Challenge id=0x6 <e87abfa4444519b38d3a0605b385c0af3456549a1326fba697c73b9bc933bdd4ab10edaa380654a120c1b55540c5e923e3f57a97>, name = ""]
sent [CHAP Response id=0x6 <ee090487bc5d8833e366b382c1e1323f>, name = "rlnet"]
rcvd [CHAP Success id=0x6 ""]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
rcvd [LCP ProtRej id=0x6 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
rcvd [IPCP ConfReq id=0x13]
sent [IPCP ConfNak id=0x13 <addr 10.0.0.1>]
rcvd [IPCP ConfReq id=0x14 <addr 10.0.0.1>]
sent [IPCP ConfAck id=0x14 <addr 10.0.0.1>]
rcvd [IPCP ConfReq id=0x15 <addr 10.0.0.1>]
sent [IPCP ConfAck id=0x15 <addr 10.0.0.1>]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 10.68.1.68> <ms-dns1 213.161.33.200> <ms-dns3 212.226.226.1>]
sent [IPCP ConfReq id=0x2 <addr 10.68.1.68> <ms-dns1 213.161.33.200> <ms-dns3 212.226.226.1>]
rcvd [IPCP ConfAck id=0x2 <addr 10.68.1.68> <ms-dns1 213.161.33.200> <ms-dns3 212.226.226.1>]
local  IP address 10.68.1.68
remote IP address 10.0.0.1
primary   DNS address 213.161.33.200
secondary DNS address 212.226.226.1
Script /etc/ppp/ip-up started (pid 3239)
Script /etc/ppp/ip-up finished (pid 3239), status = 0x0

And ping verifies that the connection is up and running:

# ping www.ericsson.com
PING a1762.g.akamai.net (195.197.54.137) from 10.68.1.68 : 56(84) bytes of data.
--- a1762.g.akamai.net ping statistics ---
1 packets transmitted, 0 received, 100% loss, time 0ms

[root@ransu peers]# ping www.ericsson.com
PING a1762.g.akamai.net (195.197.54.135) from 10.68.1.68 : 56(84) bytes of data.
64 bytes from a195-197-54-135.deploy.akamaitechnologies.net (195.197.54.135): icmp_seq=1 ttl=251 time=844 ms
64 bytes from a195-197-54-135.deploy.akamaitechnologies.net (195.197.54.135): icmp_seq=2 ttl=251 time=890 ms

--- a1762.g.akamai.net ping statistics ---
2 packets transmitted, 2 received, 0% loss, time 6756ms
rtt min/avg/max/mdev = 844.408/867.503/890.598/23.095 ms
# ping www.microsoft.fi
PING web01.microsoft.fi (212.209.134.48) from 10.68.1.68 : 56(84) bytes of data.
--- web01.microsoft.fi ping statistics ---
22 packets transmitted, 0 received, 100% loss, time 21012ms

So, the Orange SPV works via USB. Maybe other GPRS phones with USB support work too. At least adding a new USB device seems to be easy in Linux, if there is a working driver around.