Comment 4 for bug 336012

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.