bluetooth network PAN fails to connect to mobile phone

Bug #336012 reported by sanktnelson
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: bluez

I tried connecting to my mobile phone (Sony Ericsson w910) via bluetooth Network (PAN), and the phone reports that my computer is trying to use it as a modem and asks for permission twice in a row. After I grant permission the first time, pand says bnep0 connected, but dhclient fails to obtain an address. After a few seconds the second request for permission on the mobile phone screen times out and the interface ceases to exist (dhclient reports "no such device"). If I grant the second request the device disappears immediately. If I tell the phone to always allow connections without asking, pand reports "connection refused" right away.
The same happens if I try to use the new (dbus only) way of creating a network connection (I did so via some python script I found on the net).
This is really quite annoying, because it worked fine for quite a long time and was a great way to get online without the dial-up emulation crap. I'm not sure when it broke though, as I haven't needed it for about a year.
This is on up to date intrepid btw.

Revision history for this message
Håkon Enger (hakon-enger) wrote :

I have the same problem in Intrepid (fresh install with all updates applied). Everything worked fine in Hardy. In Intrepid, if I use the command `hcitool cc ##:##:##:##:##:##` (with my phones address), I see an icon on my phone (Sony Ericsson K610) indicating that a BT connection is established (I have set it to always allow connections). If I immediately issue the command `hcitool con`, I can see the connection: `< ACL ##:##:##:##:##:## handle 11 state 1 lm MASTER`, but after about 1-2 seconds, the icon on the phone disappears and the connection is not listed any more from `hcitool con`. Also, if I use a small python script to connect to the device: the `dev.Connect('NAP')` command returns `bnep0` and I can see the interface if I immediately issue the command `ifconfig bnep0` in a shell. However, after about one second, the interface is gone and ifconfig reports `device not found`. Using `pand` from `bluez-compat`, I get similar results. Very irritating regression.

Revision history for this message
Håkon Enger (hakon-enger) wrote :

I have now upgraded to Jaunty, and still see the same problem. Some more information: I am running kernel 2.6.28-11-generic on x86_64, bluez version 4.32-0ubuntu4. I have a Thinkpad T61p with a bluetooth device identified by lsusb as 'Bus 003 Device 014: ID 0a5c:2110 Broadcom Corp. Bluetooth Controller'. I am trying to connect to a PAN service on a Sony Ericsson K610i phone. I have attached a log from hcidump -V (anonymized bdaddrs) while attempting to connect with pand from bluez-compat.

The following is a shot in the dark, as I know nothing about bluetooth: I notice that there seems to be two connection requests in the attached log, with the same scid. It seems to me that the first one succeeds (after the second one is posted) and the second one fails due to 'no resources available'.

Revision history for this message
kervel (frank-dekervel) wrote :

same here..

see also
http://ubuntuforums.org/showthread.php?p=7173934#post7173934

the changelog of the upstream bluez package mentions "fixes for networking regressions", so maybe this bug is already fixed upstream ?

Revision history for this message
Håkon Enger (hakon-enger) wrote :

I have a workaround to the bug that makes the PAN connection disconnect immediately after connecting. Run the attached script in a shell like 'sudo sh connect_to_phone.sh ##:##:##:##:##:##' where you replace the #s with your phone's bluetooth address. This works for me, at least. If you haven't already, you need to install the bluez-compat package where the pand command is. If you don't know the address of your phone you can discover it by turning on bluetooth visibility on the phone and running the command 'hcitool scan' in the shell.

The reasoning behind the script is that a look at the code indicates (disclaimer: I know nothing about bluetooth networking, so this may be utterly wrong) that both the 'information response' and the 'encryption change' events trigger the bluetooth stack to send a connection request (while in the BT_CONNECT state). The hcidump output I attached before confirms this. Since my phone apparently requires encryption before creating a PAN connection, the encryption change event happens after the first request but before the connection is established, and results in another identical request being sent, which is rejected. The script enables encryption on the connection before pand attempts to connect to the PAN service.

Oh, and ignore my previous comment about dropping the (baseband) connection created by 'hcitool cc' after 1-2 seconds, this is apparently intended (when no other connection is created over the baseband). That the PAN connection is dropped, though, is (still) a bug.

Revision history for this message
sanktnelson (launchpad-maibaums) wrote :

Håkon, you're my savior. I would never have figured out that it depends on the encryption being done beforehand _and_ the timing. I tried all the commands by hand and it didn't work, due to the connection being dropped too quickly, the small script works however.

Still a really annoying bug, and no resource about it to be found on the web, except this bug report of course. bluez documentation sucks.

Changed in bluez (Ubuntu):
status: New → Confirmed
Revision history for this message
bob gray (sooner-inbox) wrote :

Above I can't get to work for me.

Aspire One, 160 gb, 1mb, 8.9

Revision history for this message
kervel (frank-dekervel) wrote :

this is how i got it working:

0. whenever i try to connect to my phone, i get a timeout

1. find some ppa offering bluez backports
(i used https://edge.launchpad.net/~cavedon/+archive/ppa)

2. whenever i try to connect to my phone, it connects and immediately disconnects.

3. use the script as suggested by Håkon Enger above (connect_to_phone.sh)

4. it works!

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :

Thanks Håkon!

The script does not work for me, but adding one more command makes it work on my Sony-Ericsson K850i.

"hcitool cc $addr; hcitool enc $addr" outputs this for me:

    HCI set encryption request failed: Input/output error

The trick, at least with my phone, is to add "hcitool auth $addr" between them:

    hcitool cc $addr
    hcitool auth $addr
    hcitool enc $addr
    pand -c "$addr"

I'm attaching the script which I use to connect to the internet over my phone now. To use the script, edit the phone_mac= line near the start, then run the script as 3g_connect or 3g_disconnect (I have one symlinked to the other).

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :

As if to demonstrate, I'm writing these comments over the 3g bluetooth connection to a Sony-Ericsson K850i, made with the script attached to the previous comment :-)

For anyone wanting to reproduce this, I'm running:

    - Ubuntu 9.04 + updates
    - That means kernel 2.6.28-13-generic (x86, 32-bit) right now.
    - Bluetooth packages updated to version 4.40-2 from Debian,
     as described in these comments:
        https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502/comments/232
        https://bugs.launchpad.net/ubuntu/+source/linux/+bug/268502/comments/239

I think the Bluetooth package updates are not important. That info is just in case someone needs to reproduce what I've done.

The only interesting difference between my script and Håkon's earlier script is mine adds a "hcitool auth $addr" line, because without it "hcitool enc $addr" just prints an error message.

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :

Fwiw,

I agree that the Bluez documentation is poor in this area. But Bluetooth is quite complicated; it would be difficult to write good documentation.

The D-Bus documentation of Bluez is poor for controlling PAN connections, which you are supposed to do now that "pand" is in "bluez-compat", meaning deprecated. The documentation is minimal, and doesn't really explain that the D-Bus calls have changed between Bluez versions, without backward compatibility. When I last looked, the sample script calling D-Bus didn't work with the current Bluez version. And D-Bus is too difficult to use from a shell script, when compound values are involved.

So hooray for still having "pand", which is simple and works :-)

Revision history for this message
Jamie Lokier (jamie-shareable) wrote :

I sent a debugging patch to bug #268502, which installs the bluetooth network protocol code from (Hardy's) 2.6.24 into a current Ubuntu kernel, which makes this problem go away. (The problem is not present in 2.6.24 - that kernel doesn't need any of the "hcitool" commands; "pand" is enough).

I also tried with various combinations of kernels, both USB bluetooth drivers, and different bluez package versions, and narrowed it down.

Altogether it strongly suggests the problem is caused by a change in the bluetooth network protocol code somehere between Hardy's 2.6.24 and Intrepid's 2.6.27, as opposed to any of the userspace packages or bluetooth hardware drivers.

It's possible that it's been fixed already in upstream kernels and hasn't yet made it's way into an Ubuntu package kernel. If so, that fix would be good to cherrypick. If not, some bisecting may find the cause.

Revision history for this message
Håkon Enger (hakon-enger) wrote :

To me this bug seems to be fixed in Karmic (kernel 2.6.31-14). I can connect to my phone using only pand -c $addr, without the need to turn on encryption first. Looking at the hcidump output, the extra connection request I mentioned above is gone.

Revision history for this message
sanktnelson (launchpad-maibaums) wrote :

same here, seems to work. There's also a nice gui now, called blueman.

Revision history for this message
Richie Ward (richies) wrote :

thanks for heads up on blueman

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

This is reported against an old version of Ubuntu and many things has changed since then. Because of that we won't fix this issue however if this behavior repeats on a modern version please fill a bug report against it and we will take it from there.

Changed in bluez (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.