Trouble Pairing my N770 to the T-Mobile Blackberry 8100 Pearl

[thunderttu]

I've tried everything and can not get the Nokia 770 to pair with the Blackberry 8100.
THe 770 says that "selected phone does not have services that can be used. Select another phone."
I've tried going in as root and typing "sdpd" then trying again, and that had no effect. But im not sure how to know that you have the dameon running. Any help would be great.

[Wireless]

I've tried everything and can not get the Nokia 770 to pair with the Blackberry 8100.
THe 770 says that "selected phone does not have services that can be used. Select another phone."
I've tried going in as root and typing "sdpd" then trying again, and that had no effect. But im not sure how to know that you have the dameon running. Any help would be great.

Unfortunately the Blackberry (all Blackberries) have a very limted Bluetooth Stack for security purposes. because the Blackberry is marketed so heavily to Governement and Large corporations, RIM has always been very tight with their Bluetooth access and what it is capable of. Most Blackberries are only capable of a Bluetooth Headset and limited Serial Port profiles. Their serial port profile is very, VERY clamped down and exceopt for some GPS modules and BarCode scanners, you will not be able to Pair it with most items.

Sorry to be the bearer of bad news.

[thunderttu]

I thought this was the problem also. I'm positive that it is the 770 itself. The blackberry pairs with the 770. but the 770 refuses to complete the pair because it thinks that there are no services it can use in the future. People on other forums are able to get pocket pc's to pair via bluetooth. So I think i need a way to force the 770 pair. any ideas anyone??? I really need this to work.

[markd]

Wireless is correct- it's a RIM restriction, not a t-mobile one (trust me, I work for one of these two companies and have carried the Pearl for going on 2 mos now). Since this is the first backberry marketed towards the average consumer, it's possible that it will gain this "tethering" ability through a future software upgrade.

For now, the Pearl is not the phone to pair with your n770- sorry.

[thunderttu]

Man, that stinks, the web on a 770 just can't be beat. Thanks for the post guys. now i have to decide if i want to keep the Pearl

[Kesey]

I don't agree. I don't think it's the blackberry. I can pair my pearl with my powerbook and use it as a bluetooth EDGE modem just fine.

[SeRi@lDiE]

I don't agree. I don't think it's the blackberry. I can pair my pearl with my powerbook and use it as a bluetooth EDGE modem just fine.


You are wrong the PROBLEM IS the BLACKBERRY... Is a security feature on the BB... It wont let you pare with surten devices... It was implemented after the bluetooth hack "Bluejacking".

[ross12345]

I am on the same page.
I can connected to cingular internet through my laptop(XP). There must be some restriction in bb pearl.
any one got any connection on bb?

[ross12345]

Damn Blackberry, I hate it now

[Raptor]

The Pearl is RIM's big jump into consumer-level Blackberries. As such, it pairs just fine with ANY system running XP, on a handful of BT stacks. With a minor modem script tweak, it also tethers to any Mac OS X system.

Normally, I'd agree that it's the Blackberry. My old 7250, my 7130, and a coworker's 8703 have a snowball's chance in hell of pairing to a 770 for DUN.

The Pearl/8100 *has no such restriction.* A T-Mo/Cingular dealer *will* balk at selling it for pairing to a Mac, but that's because it's not officially supported, solely due to RIM's lack of development focus on the Mac side. How is a Mac any different from a 770, from that perspective?

[jahf]

You are wrong the PROBLEM IS the BLACKBERRY... Is a security feature on the BB... It wont let you pare with surten devices... It was implemented after the bluetooth hack "Bluejacking".

I don't believe this is correct.

The Pearl can pair with Macs, and apparently with Windows.

This thread on the Blackberryforums site (http://www.blackberryforums.com/linux-users-corner/65690-secret-pearl-handshake-developer-info.html) seems to give a hint that the Pearl has multiple responses, and only the last one exposes the data profile. I'm unsure if that is BT or USB only though.

There are also reports on these forums of the Pearl working with the Nokia N800 (http://www.internettablettalk.com/forums/showthread.php?t=3976) tablet, which is the successor to the 770, and possible a 770.

So it seems definitely possible.

In my case, I have the devices paired fine, but I can't get the 770 to see a data connection on the Pearl. I'm on T-Mobile, and using the latest Pearl OS along with OS2006 on my 770.

[jahf]

I'm going to post my braindump on the status of this.

... Summary:
I have my 770 using the Pearl as a GPRS modem now. Its not pretty, requires a fair amount of mucking around, and the system is so unbearably slow its not worth using for Maemo-Mapper at the moment (which was my only real need).


... Details and notes:

* I'll included all my configuration files and commands to execute at the bottom of this.

* The first definite help I found was this post (http://www.blackberryforums.com/linux-users-corner/53091-8100-bluetooth-modem-2.html) combined with this blog (http://people.iola.dk/arj/2006/12/21/getting-samsung-sgh-e900-dun-working-with-nokia-770-and-linux/). Most of the stuff below is a compilation of those 2 threads.

* I don't claim to know much about pppd ... I hadn't had to mess with it before this week (been lucky with having broadband for a decade+).

* I've found the launcher screen applet "IpHome" to be essential ... it dynamically lets you cycle through your currently active interfaces and see how much data they've transferred.

* I can get the connection up and running fairly solidly. It will stay connected for hours. But after the first minute the transfer rate crawls to 1-2K/minute, and many xfers seem to simply stall out after 30-50K. This means that Maemo-Mapper will timeout on pretty much -any- image (I think out of 20+ attempts I've successfully downloaded a map twice, both times within the first minute of the connection).

* Its possible that tuning the pppd parameters could fix this. I don't think so though. I tried nearly every parameter I could find, including playing with lots of compression settings. I also made sure to run it without debugging mode nor verbose mode to make sure I wasn't bogging down the local system.

* I think the core problem is the "wap.voicestream.com" gateway. Its congested and does everything in its power to throttle long connections. I'm betting if I had access to the "internet2" or "internet3" gateways, much of these problems would disappear. However I can't access them (I tried quite a few combinations). I very much hope to be proven wrong.

* The file names below aren't critical. I've made them descriptive for my brain, but you can change them (you'll need to modify things accordingly). The locations are key however.

* The commands are just the bare minimum to get the link up and running. I've not made anything more grandiose than this and won't until I find a way to make the connection worthy. I'm pretty sure that either the ip-up/ip-down scripts or some hook into the DBUS messages could help automate the connection process.

* I do wonder if this could be mitigated some by having maemo-mapper only download 1 map at a time (I'm not sure, it may already do this, but if it opens multiple downloads as threads then its definitely not helping, as many gprs services limit the number of connections) as well as saving partial downloads and using curl's "resume" feature. I'm not blaming Maemo-Mapper here, just pondering if it could help the gimpy gprs connection along.

* The following is based on a T-Mobile USA configuration. Your mileage may vary even on T-Mobile, especially with the DNS configuration. While you have gprs running you can look in /tmp for an alternate resolv.conf file to see if that helps you. Other locations and providers will need to have things edited for sure.


... Configuration files to create:

<file=/etc/bluetooth/rfcomm.conf>
rfcomm0
{
device 00:11:22:33:44:55;
channel 1;
}
</file>

<file=/etc/chatscripts/rim8100-gprs-chat>
ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED
# modeminit
'' ATZ
'' AT&F&C1S0=0+IFC=3,1
# T-Mobile in Germany
#OK 'AT+CGDCONT=1,"IP","internet.t-d1.de"'
# Cingular, maybe, in the U.S. using WAP plans (limited)
#OK 'AT+CGDCONT=1,"IP","proxy"'
# T-Mobile in the U.S. using WAP plans (limited)
OK 'AT+CGDCONT=1,"IP","wap.voicestream.com"'
# T-Mobile in the U.S. using unlimited Internet
#OK 'AT+CGDCONT=1,"IP","internet2.voicestream.com"'
# T-Mobile in the U.S. using unlimited Internet
#OK 'AT+CGDCONT=1,"IP","internet3.voicestream.com"'
# ispnumber
# OK-AT-OK "ATDT*99#"
OK 'ATDT*99***1#'
# ispconnect
CONNECT \d\c
</file>

<file=/etc/ppp/peers/rim8100-gprs-ppp4>
# see http://www.die.net/doc/linux/man/man8/pppd.8.html to explain most of these parameters
# uncomment the next 2 lines if trying to diagnose the connection from a command-line
#debug
#nodetach
/dev/rfcomm0
460800
#230400
#115200
#57600
# following is the name of the script we use to connect,
# you may need to edit it to connect to T-Mobile outside of the U.S.
# and will definitely need to change it for other carriers
connect "/usr/sbin/chat -f /etc/chatscripts/rim8100-gprs-chat"
defaultroute
ipcp-restart 10
ipparam bt
lcp-echo-interval 0
lcp-echo-failure 0
local
mtu 16384
noaccomp
noauth
#bsdcomp 15
#nobsdcomp
#nocrtscts
noipdefault
#nomagic
#nopcomp
novj
novjccomp
remotename bt
# usepeerdns doesn't seem to work, so we'll also copy a resolv.conf file
usepeerdns
user "guest"
</file>

<file=/etc/ppp/pap-secrets>
#
# /etc/ppp/pap-secrets
#
# This is a pap-secrets file to be used with the AUTO_PPP function of
# mgetty. mgetty-0.99 is preconfigured to startup pppd with the login option
# which will cause pppd to consult /etc/passwd (and /etc/shadow in turn)
# after a user has passed this file. Don't be disturbed therfore by the fact
# that this file defines logins with any password for users. /etc/passwd
# (again, /etc/shadow, too) will catch passwd mismatches.
#
# This file should block ALL users that should not be able to do AUTO_PPP.
# AUTO_PPP bypasses the usual login program so its necessary to list all
# system userids with regular passwords here.
#
# ATTENTION: The definitions here can allow users to login without a
# password if you don't use the login option of pppd! The mgetty Debian
# package already provides this option; make sure you don't change that.

# INBOUND connections

# Every regular user can use PPP and has to use passwords from /etc/passwd
* hostname "" *

# UserIDs that cannot use PPP at all. Check your /etc/passwd and add any
# other accounts that should not be able to use pppd!
guest hostname "*" -
master hostname "*" -
root hostname "*" -
support hostname "*" -
stats hostname "*" -

# OUTBOUND connections

# Here you should add your userid password to connect to your providers via
# PAP. The * means that the password is to be used for ANY host you connect
# to. Thus you do not have to worry about the foreign machine name. Just
# replace password with your password.
# If you have different providers with different passwords then you better
# remove the following line.

# * password

# for internet.t-d1.de
"t-d1" bt "t-d1"
# for wap.voicestream.com
"guest" bt "guest"
</file>

<file=/root/start-gprs>
#!/bin/sh
# uncomment the following to play with your kernel's tcp options,
# but nothing here seemed to help me
#echo 0 > /proc/sys/net/ipv4/tcp_timestamps
#echo 1 > /proc/sys/net/ipv4/tcp_sack
#echo 1 > /proc/sys/net/ipv4/tcp_window_scaling
#echo 256960 > /proc/sys/net/core/rmem_max
#echo 256960 > /proc/sys/net/core/rmem_default
#echo 256960 > /proc/sys/net/core/wmem_max
#echo 256960 > /proc/sys/net/core/wmem_default

cp /etc/resolv.conf.ppp0 /etc/resolv.conf

/usr/bin/rfcomm release rfcomm0
/usr/bin/rfcomm bind rfcomm0
pon rim8100-gprs-ppp4
</file>

<file=/root/stop-gprs>
#!/bin/sh
poff
rfcomm release rfcomm0
cp /etc/resolv.conf.it2006 /etc/resolv.conf
</file>

<file=/etc/resolv.conf.ppp0>
nameserver 66.94.9.120
nameserver 66.94.25.120
</file>

<file=/etc/resolv.conf.it2006>
nameserver 127.0.0.1
</file>

... Commands to execute:

# become root
`sudo gainroot` # will need this every time

# you only need to do this once:
`hcitool scan`
# place the MAC of your Pearl after "device" in rfcomm.conf above

# you only need to do this once:
`gconftool -s -t string /system/osso/connectivity/IAP/DEFAULT/type DUMMY`
# that will create a network connection called DUMMY.
# use that whenever prompted to connect to a network while gprs is on.
# don't use a different connection (like 802.11) while working with this.

# move to our home directory, where the start/stop scripts are
`cd`
# from now on you should be able to use the start-gprs and stop-gprs scripts
# as well as dissect them for further steps.
`./start-gprs`
`./stop-gprs`

# other commands that may be helpful
`/etc/init.d/bluez-utils stop` # stop the bluetooth subsystem
`/etc/init.d/bluez-utils start` # start the bluetooth subsystem
`/etc/init.d/bluez-utils stop` # restart (stop+start) the bluetooth subsystem
`rfcomm release rfcomm0` # unbind the rfcomm0 device
`rfcomm bind rfcomm0` # bind the rfcomm0 device so we can use it as a modem
`ps aux | grep ppp` # make sure pppd is running and what its process # is


PS. I had hoped to test the gprs using another phone (a motorola Razr v3, with my SIM card inserted) but the 770 didn't want to connect to it (it created a profile, paired, but got errors while connecting) and I didn't feel like dealing with it anymore right now. It "felt" like a simple script thing but meh :)

PS2. I don't have cellular access at my house, so I only get to work on this when I'm away. Post any significant ideas and I'll try to get the time to follow up on them as much as I can.

[iball]

RIM has built their own encrypted bluetooth stack for use with their smartcard bluetooth sled. They sent the whole thing off to get it "certified" for use by the U.S. government (read: military) and it passed. Pretty much every U.S. general you see on TV has one of these things, not that they actually use it themselves, their "assistant" uses it for them which is why you never see them with it.
I've used that sled before on another job and it's a pretty neat hack. It allows for PKI encryption/decryption of emails on-the-fly based upon certs stored on the chip on the smartcard. And since we were running our own CrackBerry Server, emails never passed through RIM's servers at all.
Folks in congress use CrackBerries all the time but they do NOT have access to the encrypted BT smartcard sled at all. Only the U.S. military can get that particular piece of gear at moment. I think RIM is going to push out an unencrypted version soon for the general public (read: large businesses) but don't quote me on that.
Don't know if that has anything to do with your problem, but there's the backstory on RIM and bluetooth. Also, there is an application out there that allows one ot load up almost any java-based app on their blackberry but that's locked down and stored at RIM. I was sent a copy of it years ago for testing and it worked great, but I deleted in accordance with the NDA once testing was done.

[bobkaron]

I dont think thats the problem either. I have a cingular 8525.
I use it to connect my laptop via bluetooth for internet access and it works fine. The 770 gives me the same error. I know its not locked down and it offers all the necessary services. Any suggestions?