The Nokia 6680 is a fantastic phone, and as soon as I got it, I was very keen to make the most of it with my ThinkPad T41, running Debian unstable. I've had varying amounts of success, but some of it works fine, including accessing the Internet via 3G or bluetooth. Here, I describe what I did.
First, you need to get bluetooth working. I believe hat this is also possible using the USB lead that comes with the phone, but the Nokia 6680 doesn't have infrared (IR), so some of the guides that I found, which deal pretty exclusively with this, aren't much help. I used the bluez stack and utilities, which seem pretty good. On Debian, I took the following packages: bluez-pin, bluez-utils and bluez-hcidump (which I've not used so far).
Here are some lines from my sources.list which might be helpful:
deb http://debian.usefulinc.com/gnome ./ deb-src http://debian.usefulinc.com/gnome ./ deb http://debian.cihar.com/ unstable gammu
It was far from clear to me how rfcomm worked when I started out. I think I now understand it, so here you go... rfcomm acts as a "socket-like" channel to the different services on your phone. It will enable different /dev/rfcommx devices as required, and make them "live" when correctly set up. But these devices won't even exist if you're not running the bluez-utils daemons already. There are a number of steps that you'll need to go through before you can set these different services up via rfcomm, so I'll try to describe them.
So, you have a phone, and you want to connect to it. How do you do this? First, you need to find its bluetooth identifier - think of this as a MAC address, if that helps. Before you start, you'll need to put your phone into "discoverable mode". On the Nokia 6680, you need to go to the menu, then "Connectivity:Bluetooth:My phone's visibility" - make it "Visible to all" (for now, at least). Now, you need to find out the MAC address. You may be able to do this via the phone, but let's use the tools we have on the laptop. Make sure that the relevant bluez pieces are running. For me, this entails running the following as root:
/etc/init.d/bluez-utils restartgiving
Restarting bluez-utils: hcid sdpd rfcomm.You may get more output than this, showing devices being created, as well, depending on whether this daemon was started earlier or not. Now, let's find the phone:
hcitool scanFor me, this gave something like:
Scanning ...
00:12:62:A1:BC:3F Mike Bursell
I've changed the device ID, but you get the idea. The "Mike Bursell" corresponds to the name you've given your phone (see "Connectivity:Bluetooth:My phone's name"). You now know the phone's ID, so you can go to the next stage.
Your phone offers various different ways to interact with it over bluetooth - different "services". Services on your phone are on different bluetooth "channels", and rfcomm will need to know about these, so it's time to find out what your phone offers. To do this, try:
sdptool browse <bluetooth ID> (e.g. 00:12:62:A1:BC:3F)This should, hopefully, give you a lot of information about your phone. I suggest saving this to a file, as you'll need to come back to it later. Here's mine, which I've called info.txt. There's lots and lots of output here, much of which doesn't concern us much, but there are snippets of information that we definitely will need, and certainly enough for us to start work on getting rfcomm working properly.
rfcomm uses a config file (/etc/bluetooth/rfcomm.conf for me) to make services available. I've chosen a set of services which I think I'm likely to need, and configured them. Here's my rfcomm.conf file:
rfcomm0 {
bind yes;
device 00:12:62:A1:BC:3F;
channel 12;
comment "Nokia OBEX PC Suite Services";
}
rfcomm1 {
bind yes;
device 00:12:62:A1:BC:3F;
channel 10;
comment "OBEX file transfer";
}
rfcomm2 {
bind yes;
device 00:12:62:A1:BC:3F;
channel 9;
comment "OBEX file push";
}
rfcomm3 {
bind yes;
device 00:12:62:A1:BC:3F;
channel 1;
comment "Dial-up networking";
}
Let's ignore all but the last one for now. If you go back to the output from the sdptool command, you'll see a section:
Service Name: Dial-Up Networking
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x454e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
This gave me enough information to set up the last (rfcomm3) section of the config file. It says that it's dial-up networking, and it gives us the relevant channel number, too. The rest should be fairly self-explanatory.
Now that you've edited the rfcomm.conf file (as root), you're ready to restart rfcomm, as before:
/etc/init.d/bluez-utils restartgiving
Restarting bluez-utils: hcid sdpd rfcomm.
There seem to be several different states that rfcomm sockets can be in, and I'm not sure how all of them work. So I suggest the following, which seems to work for me (and you shouldn't need to be root for these):
rfcomm release 3Note - the "3" here relates to the rfcomm device number that was set in rfcomm.conf. If you're using /dev/rfcomm2, for instance, you should use "2" instead. The same goes for the "connect" command below.
rfcomm connect 3At this point, your phone should display a prompt of some kind, saying something like "Passcode for debianbox" (where "debianbox" is the hostname of your machine). Type in a 4+ digit passcode, and then "OK". If you've installed bluez-pin, and you're in X, then a dialogue box should appear on your machine, prompting you for the same passcode. Enter it, and press "OK". Your phone will now prompt you to "Accept connection request from debianbox". Press "OK", and the shell where you entered the original connect command should now show:
Press CTRL-C for hangupCongratulations: you're connected!
At this point, I recommend making your machine a trusted pair for your phone. It's optional, and does mean that your machine can request services from your phone at any time without your specifically approving them on the phone, but it does mean that you can avoid the "Accept connection request" dialogue on your phone each time you want to do anything. To create this trusted pairing, go to your phone's menu, "Connectivity:Bluetooth", and choose the second menu (right arrow click), called "Paired devices". You should see "debianbox" (or equivalent). Select it, press "Options", and then choose "Set as authorised". You'll be prompted with "Connections will take place automatically without confirmation. Continue?". If you're happy, press "Yes", and a little icon will appear next to the machine's listing. You can always remove the pairing later if you want, via the same menu.
It's good to be able to send files to the phone. Unluckily, I've so far only been able to send files as messages (so that they appear in the phone's messages folder), rather than send them to specific locations on the phone. Maybe later...
To send files, I use the gnome-obex-server application. I start this up, and it then its in the Notification Area in gnome. Then, in Nautilus, if I right-click on a file, I get the option "Send via Bluetooth...".
I then get an option to choose the device to which I want to send the file. I choose it, and click OK. There's a little dialog which shows how far it's gone, which disappears when it's done. When it's finished, you get a message notification in your phone, and you're away.
The only problem with this is the fact that you can't send very big files, as there's no way to specify that they should go to the memory card. If there's not enough space in the phone memory, the send will fail.
Note - you can do some of this from the command line if you want to avoid nautilus:
gnome-obex-send <filename>You'll still end up answering graphical prompts, though.
As with sending files, I'm running the gnome-obex-server on my laptop. I also needed to edit the hcid.conf file (/etc/bluetooth/hcid.conf for me on Debian unstable). I needed to edit the class line (in the "device" section):
# Local device class
class 0x100100
Then, to select a file to send, I use the FileManager utility (FExplorer will do the same, and allows you to see more files - you'll need to download it, but it's fantastic!), select a file, choose "Send", then "via bluetooth", pick the device, and send it.
gnome-obex-server will first ask you if you want to receive the file, and then ask you want you want to do with it. It's that easy.
This is where the magic starts. Basically, I copied and pasted from a number of different sources on the Internet, and ran into a couple of problems that weren't explicitly mentioned. Here are the files that I ended up with. Again, the file names and paths may vary for your distribution: these work for me.
Before connecting to the Internet, you may want to disable all other connections. As well as taking out your ethernet cable, you may find that, even if it doesn't have an working connection to an 802.11* network, your wifi driver may interfere with the process. I have a Centrino-based system, and use ipw2100, so the very easiest thing to do that I've found so far is to remove the module, which you need to do as root:
rmmod ipw2100A bit drastic, but it seems to work.
To connect to the Internet, do the following (you may need to be root):
pon orangeThis just works for me. It's worth pointing out that, the way my Orange account and phone are set up, I get a 3G connection when I'm in a 3G area, but that it automatically drops down to a GPRS connection when I'm not: no extra configuration needed.
If you want some more debug output, you can do:
tail -f /var/log/messagesHere's what I got in /var/log/messages:
Jun 4 14:33:41 localhost pppd[4467]: pppd 2.4.3 started by root, uid 0 Jun 4 14:33:43 localhost chat[4469]: timeout set to 5 seconds Jun 4 14:33:43 localhost chat[4469]: abort on (\nBUSY\r) Jun 4 14:33:43 localhost chat[4469]: abort on (\nERROR\r) Jun 4 14:33:43 localhost chat[4469]: abort on (\nNO ANSWER\r) Jun 4 14:33:43 localhost chat[4469]: abort on (\nNO CARRIER\r) Jun 4 14:33:43 localhost chat[4469]: abort on (\nNO DIALTONE\r) Jun 4 14:33:43 localhost chat[4469]: abort on (\nRINGING\r\n\r\nRINGING\r) Jun 4 14:33:43 localhost chat[4469]: send (^MAT^M) Jun 4 14:33:43 localhost chat[4469]: timeout set to 12 seconds Jun 4 14:33:43 localhost chat[4469]: expect (OK) Jun 4 14:33:43 localhost chat[4469]: ^MAT^M^M Jun 4 14:33:43 localhost chat[4469]: OK Jun 4 14:33:43 localhost chat[4469]: -- got it Jun 4 14:33:43 localhost chat[4469]: send (ATE1^M) Jun 4 14:33:43 localhost chat[4469]: expect (OK) Jun 4 14:33:43 localhost chat[4469]: ^M Jun 4 14:33:43 localhost chat[4469]: ATE1^M^M Jun 4 14:33:43 localhost chat[4469]: OK Jun 4 14:33:43 localhost chat[4469]: -- got it Jun 4 14:33:43 localhost chat[4469]: send (AT+cgdcont=1,"IP","orangeinternet"^M) Jun 4 14:33:44 localhost chat[4469]: expect (OK) Jun 4 14:33:44 localhost chat[4469]: ^M Jun 4 14:33:44 localhost chat[4469]: AT+cgdcont=1,"IP","orangeinternet"^M^M Jun 4 14:33:44 localhost chat[4469]: OK Jun 4 14:33:44 localhost chat[4469]: -- got it Jun 4 14:33:44 localhost chat[4469]: send (ATD*99***1#^M) Jun 4 14:33:44 localhost pppd[4467]: Serial connection established. Jun 4 14:33:44 localhost pppd[4467]: Using interface ppp0 Jun 4 14:33:44 localhost pppd[4467]: Connect: ppp0 <--> /dev/rfcomm3 Jun 4 14:33:44 localhost ifplugd.hotplug[4479]: Invoking ifplugd for ppp0 Jun 4 14:33:47 localhost pppd[4467]: PAP authentication succeeded Jun 4 14:33:47 localhost pppd[4467]: kernel does not support PPP filtering Jun 4 14:33:48 localhost pppd[4467]: local IP address 10.34.6.206 Jun 4 14:33:48 localhost pppd[4467]: remote IP address 10.6.6.6 Jun 4 14:33:48 localhost pppd[4467]: primary DNS address 193.35.133.10 Jun 4 14:33:48 localhost pppd[4467]: secondary DNS address 193.35.134.10
To disconnect, do the following (you may need to be root):
poff orangeHere's what I get in /var/log/messages:
Jun 4 14:34:15 localhost pppd[4467]: Terminating on signal 15 Jun 4 14:34:15 localhost pppd[4467]: Connect time 0.5 minutes. Jun 4 14:34:15 localhost pppd[4467]: Sent 513 bytes, received 1015 bytes. Jun 4 14:34:15 localhost pppd[4467]: Connection terminated. Jun 4 14:34:15 localhost chat[4584]: abort on (BUSY) Jun 4 14:34:15 localhost chat[4584]: abort on (ERROR) Jun 4 14:34:15 localhost chat[4584]: abort on (NO DIALTONE) Jun 4 14:34:15 localhost chat[4584]: send (\K^M) Jun 4 14:34:15 localhost last message repeated 2 times Jun 4 14:34:15 localhost chat[4584]: send (+++ATH^M) Jun 4 14:34:15 localhost ifplugd.hotplug[4596]: Stopping ifplugd for ppp0 Jun 4 14:34:15 localhost chat[4584]: send (+++ATH^M) Jun 4 14:34:15 localhost chat[4584]: send (+++ATH^M) Jun 4 14:34:15 localhost pppd[4467]: Serial link disconnected. Jun 4 14:34:16 localhost pppd[4467]: Exit.
Here's a list of some of the sources for information that I've shamelessly ripped off. At least I'm admitting it.
If you have problems, I'm happy to see if I can help, though if it looks like it's to do with the chat-script settings, I'm not the person to ask. I worked all of this out by looking at stuff on the Internet: google is your friend.