On 20-09-25 11:23:07, Oswald Buddenhagen wrote: > On Fri, Sep 25, 2020 at 09:13:31AM +0100, doa379 wrote: > > On 20-09-25 01:39:23, Oswald Buddenhagen wrote: > > > On Thu, Sep 24, 2020 at 03:34:24PM +0100, doa379 wrote: > > > > How come I can access this same account using isync-1.3.1 right now? > > > > > > > dunno. paste the full logs of mbsync -l -Dn for both versions. > > > > > Log from 1.3.3: > > https://pastebin.com/KVUAFbZA > > > > > > Log from 1.3.1: > > https://pastebin.com/942Jr1fa > > > well, that's bizarre. > > firstly, there is no discussion - the server *is* broken: it sends "ok" > but acts as if the authentication had failed (subsequent commands that > require authentication fail; also, it sends a second identical "hello", > which seems a bit weird). > > the question is what triggers this bug ... > > the ip addresses are different in the logs, so you get routed to > different servers in the cluster. try multiple runs each with the same > version to rule out that the problem is actually a particular server. > > a more likely reason would be something that isn't visible in the log: > ssl negotiation. try playing with sslversions, and/or see whether > something sticks out of a wireshark log of the connection setup. > >
Good point. I tried the failing account with SSLVersions TLSv1.1 and this worked. Previously I had SSLVersions TLSv1.2. But on the working system previously I still have set SSLVersions TLSv1.2. Actually apart from isync version differences I'm also using two different systems. The SSL libraries are correspondingly at different versions. So on the working system I have: openssl-1.0.2u gnutls-3.6.15 On the new system that was failing I have these libraries: libssl48-3.1.4 libtls20-3.1.4 Both systems have this library: /usr/lib64/libgnutls.so.30.28.1 _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
