Bug 52736

---- Reported by patrick.ohly@intel.com 2010-08-02 11:26:43 +0000 ----

This issue seems related to the kernel. SyncEvolution + N900 works on some host platforms and fails on others with:

# [2010-07-18 21:54:21.915] Connecting Bluetooth device with address  
 0C:DD:EF:9C:94:8B and channel 25
# [2010-07-18 21:54:22.191] OBEX progress
# [2010-07-18 21:54:22.246] Cancel disconncting process
# [2010-07-18 21:54:22.247] Server Alerted Sync init with SANFormat 12 failed, trying with legacy format
# [2010-07-18 21:54:22.288] Connecting Bluetooth device with address 0C:DD:EF:9C:94:8B and channel 25
# [2010-07-18 21:54:22.340] OBEX progress
# [2010-07-18 21:54:22.367] Cancel disconncting process
# [2010-07-18 21:54:22.370] TransportException thrown at  
> /work/runtests/head/syncevolution/src/syncevo/ObexTransportAgent.cpp:376
# [2010-07-18 21:54:22.371] ObexTransprotAgent: Underlying transport error

This issue is just a reminder that the problem exists. We (= the SyncEvolution developers) cannot do anything about it.



---- Additional Comments From yongsheng.zhu@intel.com 2010-08-02 17:35:49 +0000 ----

do you have some successful cases for some kernel versions?



---- Additional Comments From patrick.ohly@intel.com 2010-08-03 04:21:14 +0000 ----

(In reply to comment #1)
> do you have some successful cases for some kernel versions?  

That's better discussed in the https://bugs.meego.com/show_bug.cgi?id=1371, but yes, I know that it works for example with Debian's 2.6.32-4-amd64. https://bugs.meego.com/show_bug.cgi?id=1371 contains other examples.



---- Additional Comments From vpivaini@cs.helsinki.fi 2010-10-08 05:45:28 +0000 ----

I'm not certain that the problem is in the kernel. I recently updated my laptop to Fedora 14 Beta and I'm having this problem now. My desktop is still otherwise Fedora 13, but I'm using the current Fedora 14 kernel on it and syncing the N900 works there. I think the problem is in some other part(s) of the stack.



---- Additional Comments From patrick.ohly@intel.com 2010-10-08 06:25:01 +0000 ----

(In reply to comment #3)
> I'm not certain that the problem is in the kernel.

We compared the system calls between a system which worked and one that didn't. The calls into the kernel were exactly the same, which seemed to rule out differences in user space (see https://bugs.meego.com/show_bug.cgi?id=1371).

> I recently updated my laptop
> to Fedora 14 Beta and I'm having this problem now. My desktop is still
> otherwise Fedora 13, but I'm using the current Fedora 14 kernel on it and
> syncing the N900 works there. I think the problem is in some other part(s) of
> the stack.  

Do you see a chance to nail down the root cause by updating incrementally? First glibc, then Bluez libs, ...



---- Additional Comments From vpivaini@cs.helsinki.fi 2010-10-08 14:21:28 +0000 ----

(In reply to comment #4
> Do you see a chance to nail down the root cause by updating incrementally?
> First glibc, then Bluez libs, ...  

It'd be a bit too much work and a bit risky as well.
Fedora 13 has glibc-2.12.1, Fedora 14 has 2.12.90.
Fedora 13 has bluez-libs-4.64, Fedora 14 has 4.71.
I'm not sure about the patches those packages carry. I guess I could try downgrading bluez to the Fedora 13 version or something like that.



---- Additional Comments From vpivaini@cs.helsinki.fi 2010-10-10 04:16:15 +0000 ----

I tried downgrading openobex and bluez to Fedora 13 versions. Downgrading openobex didn't help, downgrading bluez broke bluetooth in GNOME.



---- Additional Comments From patrick.ohly@intel.com 2010-10-27 02:31:34 +0000 ----

*** https://bugs.meego.com/show_bug.cgi?id=9041 has been marked as a duplicate of this bug. ***



---- Additional Comments From klas_hultqvist@hotmail.com 2011-01-12 13:21:50 +0000 ----

Does the assignment to syncevolution-bugs@meego.bugs make sense? Syncevolution runs on a different platform and communicates with the N900 standard firmware. If it's a problem in Nokia closed source it should be more general. (It used to work for me but doesn't with ubuntu 10.10 and PR1.3.)



---- Additional Comments From patrick.ohly@intel.com 2011-01-12 13:53:05 +0000 ----

(In reply to comment #8)
> Does the assignment to syncevolution-bugs@meego.bugs make sense?

It means that no-one in particular is working on this issue, which is correct.

My feeling is that something broke outside of the SyncEvolution project and thus the issue could be closed as "WONTFIX", but then users running into the problem wouldn't be able to find it, so I keep the bug open.

> Syncevolution
> runs on a different platform and communicates with the N900 standard firmware.
> If it's a problem in Nokia closed source it should be more general. (It used to
> work for me but doesn't with ubuntu 10.10 and PR1.3.)  

What distro and N900 firmware did you use when it still worked? More specifically, did a distro update or a N900 update break it?



---- Additional Comments From klas_hultqvist@hotmail.com 2011-01-13 00:33:16 +0000 ----

Thanks!

Seems it worked with PR1.3, ubuntu 10.04 and syncevolution 1.0, but not with ubuntu 10.10 and syncevolution 1.1.1. I shall try with the syncevolution 1.0 from the ubuntu 10.10 repository.



---- Additional Comments From patrick.ohly@intel.com 2011-01-13 01:30:49 +0000 ----

(In reply to comment #10)
> Thanks!
> 
> Seems it worked with PR1.3, ubuntu 10.04 and syncevolution 1.0, but not with
> ubuntu 10.10 and syncevolution 1.1.1. I shall try with the syncevolution 1.0
> from the ubuntu 10.10 repository.  

Yes, please try to isolate the change to one single component. In particular make sure that you use exactly the same SyncEvolution binary. The ones from syncevolution.org should work on Ubuntu 10.04 and 10.10.



---- Additional Comments From anon444@mailinator.com 2011-01-13 15:25:42 +0000 ----

I am trying to test some of the distros using LiveCDs and SyncEvolution "Christmas Edition" 1.1.1 but I am a newbie so it is taking me a while as I learn.

Using the latest updated N900 and:

Live CD of Ubuntu 8.10 for AMD64 syncs using SyncEvolution.

Live CD of Ubuntu 9.10 for AMD64 syncs using SyncEvolution.

Live CD of Ubuntu 10.04.1 for AMD64 would "pair up" but not sync using SyncEvolution.

Live CD of Ubuntu 10.10 for AMD64 would "pair up" but not sync using SyncEvolution.

Live CD of Kubuntu 10.10 for AMD64 would "pair up" but not sync using SyncEvolution.



---- Additional Comments From patrick.ohly@intel.com 2011-01-13 23:31:21 +0000 ----

(In reply to comment #12)
> I am trying to test some of the distros using LiveCDs and SyncEvolution
> "Christmas Edition" 1.1.1 but I am a newbie so it is taking me a while as I
> learn.
> 
> Using the latest updated N900 and:
> 
> Live CD of Ubuntu 8.10 for AMD64 syncs using SyncEvolution.
> 
> Live CD of Ubuntu 9.10 for AMD64 syncs using SyncEvolution.
> 
> Live CD of Ubuntu 10.04.1 for AMD64 would "pair up" but not sync using
> SyncEvolution.

That's useful, thanks for the though testing. When it fails, does it fail with "Underlying transport error"?

You mentioned https://bugzilla.redhat.com/show_bug.cgi?id=649984 but that one looks different: communication works in principle, it is just the content of the messages sent by the N900 which is problematic.

On the other hand it is interesting that the phone talks the PC on a recent distro.



---- Additional Comments From anon444@mailinator.com 2011-01-17 08:30:24 +0000 ----

I did double-check and the Live CD of Ubuntu 10.04.1 for AMD64 fails with that "Underlying transport error". I can check the other versions or in other ways if you think it would be helpful.



---- Additional Comments From klas_hultqvist@hotmail.com 2011-01-19 23:12:13 +0000 ----

I compiled syncevolution 1.0 and openobex 1.5 and ran with and without debugger. I'm using 64bit ubuntu 10.10. The problem is still there. I noticed that when sdp_close() is called in sdp_source_cb_impl() for G_IO_IN and SDP_REQ the icon on the phone goes from blue (connected) to white (disconnected). I also noticed that during the subsequent obex attempt the obex_data_indication() function, called from obex_transport_input(), sees msg->data_size=0 and tries to read 3 bytes which results in errno=104 (connection reset by peer, I think) and a return code of -1. Back in the syncevolution code, in ObexTransportAgent::obex_fd_source_cb_impl() this leads to the section of code with comments "transport error, no way to recovery, simply abort". 

I don't understand this at all, but it seems a bit surprising that the sdp session is closed and the phone disconnected before the obex transport starts. Maybe it's normal?

Anyway, I'm giving up on this for now. I installed funambol on a local server and sync my laptop and phone via that.



---- Additional Comments From anon444@mailinator.com 2011-01-23 20:38:57 +0000 ----

I installed Ubuntu 9.10 for AMD64 and updated it with all of the latest updates for 9.10 (without upgrading it to 10.04) and syncing using SyncEvolution still worked.

Is there anything else I help/try?



---- Additional Comments From patrick.ohly@intel.com 2011-01-23 22:53:42 +0000 ----

(In reply to comment #16)
> I installed Ubuntu 9.10 for AMD64 and updated it with all of the latest updates
> for 9.10 (without upgrading it to 10.04) and syncing using SyncEvolution still
> worked.
> 
> Is there anything else I help/try?  

No, thanks. You've nailed it pretty well to the transition between Ubuntu 9.10 and 10.04. Now someone who knows the OBEX+Bluetooth libraries needs to continue what klhul started and look really close at a working and a failing system to find the relevant difference.



---- Additional Comments From dbet1@gmx.net 2011-02-12 09:12:14 +0000 ----

(In reply to comment #17)
> No, thanks. You've nailed it pretty well to the transition between Ubuntu 9.10
> and 10.04. Now someone who knows the OBEX+Bluetooth libraries needs to continue
> what klhul started and look really close at a working and a failing system to
> find the relevant difference.  

I have the same problem on two different machines, both with the same software installed: Ubuntu Linux 10.04 (Lucid) with Syncevolution 1.1.1. This means the same kernel, bluez software and so on. But on one machine it works, on the other this bug occurs.

How can I help?



---- Additional Comments From linux@hschmitt.de 2011-08-08 14:04:43 +0000 ----

(In reply to comment #18)
> I have the same problem on two different machines, both with the same software
> installed: Ubuntu Linux 10.04 (Lucid) with Syncevolution 1.1.1. This means the
> same kernel, bluez software and so on. But on one machine it works, on the
> other this bug occurs.
> 
> How can I help?         
As I read the bug it could be due to a bug in openobex1.4 which is used in N900 PR1.3:
http://git.kernel.org/?p=bluetooth/openobex.git;a=blobdiff;f=lib/obex_object.c;h=60b14bf31015c012c6ce28f1d5f5331f6d13ba60;hp=1073c97570da8c8dbd19f444a8a4cbe7c8ca9b11;hb=52bf1445d2fa4b95dac4b98e1cb6e9dbb5d5ed7d;hpb=b3dcebe8b59f418740e96498052be877612df08e

Here you can find a openobex1.5 for Armel
http://talk.maemo.org/showthread.php?p=731941#post731941
The bug shows when the message is to big to transfer in one packet. So you can test it on systems which fail with very small address books.



---- Additional Comments From dbet1@gmx.net 2011-09-06 14:27:36 +0000 ----

(In reply to comment #19)
> (In reply to comment #18)
> > I have the same problem on two different machines, both with the same software
> > installed: Ubuntu Linux 10.04 (Lucid) with Syncevolution 1.1.1. This means the
> > same kernel, bluez software and so on. But on one machine it works, on the
> > other this bug occurs.
> > 
> > How can I help?         
> As I read the bug it could be due to a bug in openobex1.4 which is used in N900
> PR1.3:
> http://git.kernel.org/?p=bluetooth/openobex.git;a=blobdiff;f=lib/obex_object.c;h=60b14bf31015c012c6ce28f1d5f5331f6d13ba60;hp=1073c97570da8c8dbd19f444a8a4cbe7c8ca9b11;hb=52bf1445d2fa4b95dac4b98e1cb6e9dbb5d5ed7d;hpb=b3dcebe8b59f418740e96498052be877612df08e
> 
> Here you can find a openobex1.5 for Armel
> http://talk.maemo.org/showthread.php?p=731941#post731941
> The bug shows when the message is to big to transfer in one packet. So you can
> test it on systems which fail with very small address books.         

Openobex 1.4 does not help. As I said, on one machine it works out of the box. On the machine at which the sync does not work with the N900, I can sync a Nokia E7 without any problems.



---- Additional Comments From dbet1@gmx.net 2011-09-06 14:31:06 +0000 ----

(In reply to comment #19)
> (In reply to comment #18)
> > I have the same problem on two different machines, both with the same software
> > installed: Ubuntu Linux 10.04 (Lucid) with Syncevolution 1.1.1. This means the
> > same kernel, bluez software and so on. But on one machine it works, on the
> > other this bug occurs.
> > 
> > How can I help?         
> As I read the bug it could be due to a bug in openobex1.4 which is used in N900
> PR1.3:
> http://git.kernel.org/?p=bluetooth/openobex.git;a=blobdiff;f=lib/obex_object.c;h=60b14bf31015c012c6ce28f1d5f5331f6d13ba60;hp=1073c97570da8c8dbd19f444a8a4cbe7c8ca9b11;hb=52bf1445d2fa4b95dac4b98e1cb6e9dbb5d5ed7d;hpb=b3dcebe8b59f418740e96498052be877612df08e
> 
> Here you can find a openobex1.5 for Armel
> http://talk.maemo.org/showthread.php?p=731941#post731941
> The bug shows when the message is to big to transfer in one packet. So you can
> test it on systems which fail with very small address books.         

Openobex 1.5 does not help. As I said, on one machine it works out of the box. On the machine at which the sync does not work with the N900, I can sync a Nokia E7 without any problems.(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > I have the same problem on two different machines, both with the same software
> > > installed: Ubuntu Linux 10.04 (Lucid) with Syncevolution 1.1.1. This means the
> > > same kernel, bluez software and so on. But on one machine it works, on the
> > > other this bug occurs.
> > > 
> > > How can I help?         
> > As I read the bug it could be due to a bug in openobex1.4 which is used in N900
> > PR1.3:
> > http://git.kernel.org/?p=bluetooth/openobex.git;a=blobdiff;f=lib/obex_object.c;h=60b14bf31015c012c6ce28f1d5f5331f6d13ba60;hp=1073c97570da8c8dbd19f444a8a4cbe7c8ca9b11;hb=52bf1445d2fa4b95dac4b98e1cb6e9dbb5d5ed7d;hpb=b3dcebe8b59f418740e96498052be877612df08e
> > 
> > Here you can find a openobex1.5 for Armel
> > http://talk.maemo.org/showthread.php?p=731941#post731941
> > The bug shows when the message is to big to transfer in one packet. So you can
> > test it on systems which fail with very small address books.         
> 
> Openobex 1.4 does not help. As I said, on one machine it works out of the box.
> On the machine at which the sync does not work with the N900, I can sync a
> Nokia E7 without any problems.



---- Additional Comments From corsac@debian.org 2011-10-10 12:36:58 +0000 ----

Hmhm, seems I have the same issue with syncevolution (running on debian sid laptop) and n900 (running maemo pr1.3 + CSSU).

I've tried to upgrade obexd/libopenobex but that doesn't seem to work.

Note that using another bluetooth adapter on the same laptop doesn't help, but the same thing on another laptop (older, so with an older bt adapter) does work.



---- Additional Comments From corsac@debian.org 2011-10-10 13:17:52 +0000 ----

To be a little more specific, it works fine on my Thinkpad T61 which has a 2.0 integrated bluetooth adapter and it doesn't work on my Thinkpad X201s which has a 2.1 integrated bluetooth device.

I've tried an external adapter on the X201s and it doesn't work either, I'll try it on T61 and see if it changes anything.

Thrice adapters are from Broadcom.



---- Additional Comments From corsac@debian.org 2011-10-11 19:06:14 +0000 ----

As far I understand it, this bug is linked to some behavior in the n900 proprietary bits, which Nokia is not interested to fix nor open. So basically it seems that it won't be fixed on n900 side because of that (though I'm still a bit puzzled on what part is not open, since it seems that the problem lies in bluetooth or obex).

If it's not possible to fix it in n900, and considering it did work before (and it still work on some platforms), would it be possible to workaround it on the other end (so either syncevolution, obex libs, bluetooth stack or the kernel)?



---- Additional Comments From patrick.ohly@intel.com 2011-10-11 19:30:43 +0000 ----

(In reply to comment #24)
> As far I understand it, this bug is linked to some behavior in the n900
> proprietary bits, which Nokia is not interested to fix nor open.

I only know that Nokia was not interested in helping fix the issue. I don't know whether closed bits are involved - it might be possible for someone with enough time, skills and the device to fix it without Nokia's help.

> If it's not possible to fix it in n900, and considering it did work before (and
> it still work on some platforms), would it be possible to workaround it on the
> other end (so either syncevolution, obex libs, bluetooth stack or the kernel)?         

I have no idea what that workaround might be. Limiting the message size didn't work out.



---- Additional Comments From corsac@debian.org 2011-10-11 19:37:14 +0000 ----

Since I have a working and a non working config which are more or less at the
same software situation (Debian sid), it might be possible to investigate a bit
more if you have any idea and can drive me through this.



---- Additional Comments From patrick.ohly@intel.com 2011-10-11 19:45:03 +0000 ----

(In reply to comment #26)
> Since I have a working and a non working config which are more or less at the
> same software situation (Debian sid), it might be possible to investigate a bit
> more if you have any idea and can drive me through this.         

Sorry, I don't know enough about Bluez myself to be of any help.



---- Additional Comments From corsac@debian.org 2011-10-11 20:14:22 +0000 ----

Running hcidump on the two configs, it seems that it might be authentication related. On the failing box, I get:

[stuff before]
> ACL data: handle 12 flags 0x02 dlen 121
    L2CAP(d): cid 0x0041 len 117 [psm 1]
        SDP SSA Rsp: tid 0x0 len 0x70
          count 109
          record #0
              aid 0x0000 (SrvRecHndl)
                 uint 0x10005
              aid 0x0001 (SrvClassIDList)
                 < uuid-128 00000002-0000-1000-8000-0002ee000002 >
              aid 0x0004 (ProtocolDescList)
                 < < uuid-16 0x0100 (L2CAP) > <
                 uuid-16 0x0003 (RFCOMM) uint 0x19 > <
                 uuid-16 0x0008 (OBEX) > >
              aid 0x0005 (BrwGrpList)
                 < uuid-16 0x1002 (PubBrwsGrp) >
              aid 0x0009 (BTProfileDescList)
                 < < uuid-128 00000002-0000-1000-8000-0002ee000002 uint 0x100 > >
              aid 0x0100 (SrvName)
                 str "SyncML Client"
          cont 00
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
    handle 12
> HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Link Key Request (0x17) plen 6
    bdaddr 00:BD:3A:E5:92:07
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
    bdaddr 00:BD:3A:E5:92:07 key 2A0250DE3E30D135A02D47B1D79CE3B0
> HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Reply (0x01|0x000b) ncmd 1
    status 0x00 bdaddr 00:BD:3A:E5:92:07
> HCI Event: Auth Complete (0x06) plen 3
    status 0x00 handle 12
< ACL data: handle 12 flags 0x00 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0040 result 3 status 0
      Connection refused - security block
[stuff after]

though I have no idea why this happens while the pairing is ok. Will try to investigate that and report back. Not sure if this is the root cause of syncevolution issue though.



---- Additional Comments From corsac@debian.org 2011-10-11 20:35:44 +0000 ----

Ok, looking a bit more, I found http://www.spinics.net/lists/linux-bluetooth/msg10266.html which seems quite related to this issue.



---- Additional Comments From corsac@debian.org 2011-10-12 13:24:07 +0000 ----

I managed to fix the authentication issue (thanks to Johan Hedberg on #bluez@freenode) by forcing downgrade to bluetooth 2.0 pairing, using:

sudo hciconfig hci0 sspmode 0

and repairing laptop and n900.

Now I can browse files on n900, but syncevolution still fails:


corsac@scapa: syncevolution --run delirium calendar
[INFO] addressbook: inactive
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] calendar+todo: inactive
[WARNING] Cancel disconncting process
[WARNING] Cancel disconncting process
[ERROR] ObexTransprotAgent: Underlying transport error

Synchronization failed, see /home/corsac/.cache/syncevolution/delirium-2011-10-12-15-13/syncevolution-log.html for details.

Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
|               |         LOCAL         |        REMOTE         | FLI |
|        Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|      calendar |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|          start Wed Oct 12 15:13:30 2011, duration 0:01min           |
|          external transport failure (local, status 20043)           |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
First ERROR encountered: ObexTransprotAgent: Underlying transport error

[ERROR] command line execution failure


and in the relevant log file I can see:


[2011-10-12 15:13:30.915] starting SAN 12 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce SyncEvolution session 1 server scapa
[2011-10-12 15:13:30.915] SAN source calendar uri Calendar type 6 mode 206
[2011-10-12 15:13:30.949] Connecting Bluetooth device with address 00:bd:3a:e5:92:07 and channel 25
[2011-10-12 15:13:30.977] OBEX progress
[2011-10-12 15:13:30.994] Cancel disconncting process
[2011-10-12 15:13:30.994] Server Alerted Sync init with SANFormat 12 failed, trying with legacy format
[2011-10-12 15:13:30.994] starting SAN 11 auth 1B2M2Y8AsgTpgAmY7PhCfg== nonce SyncEvolution session 1 server scapa
[2011-10-12 15:13:30.995] SAN source calendar uri Calendar type text/x-vcalendar
[2011-10-12 15:13:30.995] SAN with overall sync mode 206
[2011-10-12 15:13:31.018] Connecting Bluetooth device with address 00:bd:3a:e5:92:07 and channel 25
[2011-10-12 15:13:31.030] OBEX progress
[2011-10-12 15:13:31.045] Cancel disconncting process
[2011-10-12 15:13:31.045] TransportException thrown at ObexTransportAgent.cpp:374
[2011-10-12 15:13:31.045] ObexTransprotAgent: Underlying transport error
[2011-10-12 15:13:31.046] ##### enginemodulebase (LNK): Disconnect

which pretty much looks like the original message. Any idea how to debug further?



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 4835 at https://bugs.meego.com/show_bug.cgi?id=4835
This bug depended on bug(s) 1371.