[SyncEvolution] libopenobex 1.7.2 regression (was: Re: Sync on Debian Stretch)

[Patrick Ohly]

On Tue, 2017-11-07 at 00:30 +0100, deloptes wrote:
> 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.
> > 
> 
> this is true, the implicit question was if I can dig further.

It would be interesting to find out where that rsp comes from. There's
nothing in the source code which sets it, so I suppose it comes
straight from the phone, which would imply that it is in the traffic
dump.

> > > 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.
> > 
> 
> yes not related but the fall back mechanism covers it. Not sure
> however if
> going to SAN 1.1 is desired. I thought always 1.2 is supported by
> both

It definitely shouldn't fall back.

> > 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.
> > 
> 
> I tried to your gmx account, if you still use it, from my other
> account. If I have to use the intel one let me know

I haven't seen that email, but perhaps I just missed it. Please send
again and let me know here what the subject is.

-- 
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.