Patrick Ohly changed bug 91485
What Removed Added
Status NEW ASSIGNED
Assignee syncevolution-issues@syncevolution.org patrick.ohly@gmx.de

Comment # 1 on bug 91485 from
The developer who wrote that code is no longer around; I'm looking at this in
detail for the first time myself, so I also have some problems trying to
understand how the connection needs to be closed correctly.

The patch you sent just seems to ensure that the connection gets serviced
longer than usual, so the real problem must be some missing code that waits for
the proper termination of the connection.

In Wireshark, I see this at the end (copied one-by-one with context
menu->Copy->Summary (Text) - if there's a better way I'm all ears):

103    2.569266000    localhost ()    Nokia_1e:ad:30 (Nokia N97 mini)    L2CAP 
  17    Sent Disconnection Request (SCID: 0x0041, DCID: 0x0041)
104    2.573606000    controller    host    HCI_EVT    8    Rcvd Number of
Completed Packets
105    2.575667000    Nokia_1e:ad:30 (Nokia N97 mini)    localhost ()    L2CAP 
  17    Rcvd Disconnection Response (SCID: 0x0041, DCID: 0x0041)
106    4.579482000    host    controller    HCI_CMD    7    Sent Disconnect
107    4.580612000    controller    host    HCI_EVT    7    Rcvd Command Status
(Disconnect)
108    4.666611000    controller    host    HCI_EVT    7    Rcvd Disconnect
Complete

This looks normal to me. What's your corresponding trace?

When you say "the last message (acknowledgement) from SyncEvolution does not go
over the OBEX link" are you talking about the SyncML message or some
lower-level OBEX/RFCOMM/whatever message?


You are receiving this mail because: