Pairing Bluetooth device with PIN fails

Question

I'm trying to pair my old BlackBerry 8310 to my Linux desktop (up-to-date Debian Sid, 3.15-10.dmz.1-liquorix-amd64) by using blueman and its associated tools. Scanning for the device works equally well for both sides; however, I am unable to pair the two once it comes to entering the PIN.

If I scan from my PC, I have two options in blueman-manager regarding my phone: Directly selecting "pair", or selecting "setup".

• If I select "pair", nothing happens on my desktop, but the phone asks me to enter a PIN; if I do so, it reports that pairing has failed. During that, nothing is logged to the console.

• Selecting "setup" opens a configuration dialog that allows for entering or generating a PIN. Regardless, I get to a screen that tells me to enter the PIN on the phone, and at the same time, the phone pops up the equivalent dialog. This would be what one would expect to work; but whatever I enter (naturally, the same on both), both devices report that pairing has failed, and blueman-manager logs

  init_services (/usr/lib/python2.7/dist-packages/blueman/main/Device.py:73)  
  Loading services   
  org.bluez.Error.AuthenticationFailed: Authentication Failed
  

• If I instead try to pair from the phone, I cannot see any kind of reaction from my desktop - all I get is the equivalent "pairing failed" message from the BlackBerry after I entered a PIN in the dialog that pops up there.

hcitool scan and hciconfig -a work without complaints, but I cannot find a way to try the pairing as a whole on the console since bluez-simple-agent seems to have been discontinued and this recommendation is everywhere on Google. hcitool cc as root opens the PIN dialog on the phone, then fails with "Input/Output error" once I enter it. The user is not permitted to execute this command. I also tried creating /usr/lib/bluetooth/<MAC>/pincodes to manually define a persistent PIN, which seems to have had no effect. The same goes for running the different commands as root, though I'm really confused about the internal structure of the Bluetooth subsystem now: They usually and inconsistently failed with Python or DBUS errors or just showed the same results.

The only other Bluetooth device I have around are a pair of Creative speakers. Trying "setup" asks me to enter a key on them, which is impossible. If I try "pair", I'm asked for a PIN as I should, but no pairing takes place, and no errors appear on the console. (It just repeats their name a few times.) Interestingly, I tried that before writing my question, and nothing happened in terms of PIN questions, just like with the BlackBerry, which still shows no change. I don't think I actively changed anything since then. The BlackBerry can pair with and connect to the speakers, and everything goes as one would expect, so the problem is definitely with my desktop.

So thus my questions:

• What is that PIN window generated by, and why does it seem to appear randomly?

• How can I find out what, exactly, fails after trying to add the speakers, as this may give me a clue?

• Is there any kind of complete log that concerns itself with Bluetooth?

• What data can I provide to make this more solvable?

EDIT: Alright, I've given up. Further Progress was, maybe it'll help someone:

• Found buetoothctl. There, enter agent KeyboardOnly, then default-agent, then scan on, then pair <MAC> with being your scan result. Pairing works. Then connect from the phone - pairing from the desktop fails -, accept the attempt in bluetoothctl. This route failed because it only accepted the phone as a remote, nothing else. Maybe it'll work for something like the speakers...

• Tried obexftp. It's vital to specify the channel due to a bug in obexftp, otherwise it says "Connecting...failed: connect". For this, enter sdptool browse <MAC>, then look for the channel of the file service. Then do obexftp -b <MAC> -B <channel> -l. This fails with "Connecting..\failed: send UUID".

• Tried purging everything about bluetooth and reinstalling from stable and testing. Don't bother, they're all incompatible. I don't know how that's possible, but they look for outdated DBUS interfaces on other stable and testing versions. Same for the sid version.

• Tried sending files from the phone, which fails in sid because you can't even open the relevant dialog - outdated DBUS interface -, and in testing (likely) because there is no possibility to accept the BB's file transfer service as it's "only a remote". (With the relevant service enabled on the BB.)

Some other things as well that I can't remember any more...