On Thu, 2017-11-02 at 22:27 +0100, deloptes wrote: > Patrick Ohly wrote: > > > On Sat, 2017-10-07 at 19:31 +0200, deloptes wrote: > > > Patrick Ohly wrote: > > > > > > > Perhaps send it to me privately? I'm not sure whether I'll find > > > > anything either, though. > > > > > > Can't we add some debug code in syncevo or obex to get the type > > > of > > > event is causing the trouble? > > > The message I get after including libsynthesis in syncevo is a > > > bit > > > different (more complete) > > > > But the initial error is still the same "OBEX Request 3 got a > > failed > > response Unknown response". > > > > If you can't track down the "Unknown response" interactively in a > > debugger, then you can of course also add more debug output. > > > > > > Hi Patrick, > > rsp has value 83 (0x53 == OBEX_RSP_SERVICE_UNAVAILABLE) when it > complains "OBEX Request 3 got a failed response Unknown response"
obex_response_to_string(int rsp) in libopenobex lib/main.c is incomplete and lacks an entry for that code. > Interestingly it gets this twice. The first time when SANFormat12 > fails and it goes into legacy Looks like a generic issue, independent of the actual message content. > The second time when it dies in my case. > What can I do next? Can you file a bug about that against libopenobex? I suppose https://sourceforge.net/p/openobex/bugs/ is still the bug tracker of the project. You haven't sent me the Wireshark traffic dumps, have you? The next step would be to do a side-by-side comparison of the packets of a successful sync and a failed sync and determine where they diverge. Alternatively, the OBEX transport could be re-written so that it uses obexd. libopenobex has been legacy code now for a long time. But I am not sure whether obexd really supports SyncML. Looking at https://git.k ernel.org/pub/scm/bluetooth/bluez.git/tree/doc/obex-api.txt seems to imply that it only supports certain well-known protocols (PBAP, for example) and not SyncML. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
