ESessions aren't reestablished if remote end reconnects

[js]

ESessions are not reestablished anymore if the remote end reconnects. This definitely worked in the past. I myself added code that reset the internal variable whether to autonegotiate on typing when the remote signs off. bct? Did you change something?

[asterix]

Can you find a way to repro? If I restart Gajim other part is still able to send me message when I'm back online.

[js]

Start two clients. Start an ESession. Disconnect one client. Reconnect it. Type in the client that NOT reconnected. It doesn't negotiate a new ESession, but the old one is ended.

[bct]

I can't reproduce this either.

[asterix]

I am able to reproduce with private message:

user A and B are in the same room. user A sends a pm to user B

user B reads it, then quit Gajim and re-launch it and come back in the room

user A sends a new message to B: This one is not encrypted.

[bct]

I was able to reproduce this with a non-PM session, which I fixed in [10525].

The problem with PMs is related to caps. Autonegotiation is only done if the following returns true:

gajim.capscache.is_supported(self.contact, NS_ESESSION) \
and not gajim.capscache.is_supported(self.contact, 'notexistant')

A and B have a PM window open, that line returns True and the esession is autonegotiated. Then B goes offline, then reconnects and joins the chat room; that line returns False for A (because the second half returns True). Any idea why the second half is returning True after B reconnects?

[asterix]

(In [10528]) update Contact instance in privateChatControl. see #4292

[asterix]

the check to notexistant is now ok. but it still doesn't work because want_e2e is False because e2e_is_active is True because session.enable_encryption is True. This var is not reset when contact B leaves the room.

[steve-e]

Bct, can you fix that one?

[bct]

I'll look at it ASAP, probably Thursday. Midterms :(

[bct]

I've fixed renegotiation for when A reconnects and B initiates, but there seems to be the same caps issue when A reconnects and A tries to initiate.

[js]

Ah, yes, this might be a race condition :). Why not instead of auto-renegotiating re-enable autonegotiation on typing? ;) Would pretty much fix it, I guess.

[bct]

That's how it works right now, the caps issue is when A reconnects and starts typing she doesn't have caps for B.

[bct]

The problem was that A's gc_contact for B wasn't being set properly when A reconnected. Fixed by [10637].