| Summary: | Connections between kmail2 and courier-imap-ssl unstable | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Freek de Kruijf <freekdekruijf> |
| Component: | IMAP resource | Assignee: | Kevin Ottens <ervin> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | dvratil, kdepim-bugs, vkrause |
| Priority: | NOR | ||
| Version: | 4.10 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | compressed tar archive of courier-imap-ssl log file and wireshark capture file | ||
*** This bug has been marked as a duplicate of bug 316840 *** |
Created attachment 80721 [details] compressed tar archive of courier-imap-ssl log file and wireshark capture file Most likely since I installed 4.10.2 I see a runaway connection between kmail2 imap client and a remote server running on openSUSE with a courier-imap-ssl IMAP-server. I see this problem with two of these servers, one running on a server with openSUSE 11.4 courier-imap version 4.8.1-2.4 and the other on openSUSE 12.3 (armv5tel) courier-imap version 4.12.0-1.1. The first one uses an IPv4 connection and the second an IPv6 connection. At a certain moment the client or the server disconnects and after that the client starts new connections which are almost immediately disconnected at a rate of about 4 per second. This only stops after restarting the IMAP server of stopping Kontact. But at one occasion it looks as if after stopping Kontact the IMAP agent still went on and only after ending the KDE session the runaway process stopped. I have a wireshark capture file for a session between the client and the server on IPv6 which I will attach. The capture started at 18:14:16. At 18:44:23 the runaway processing started. I just send the first 500 packets. The second file shows the log of the courier-imap-ssl server starting at the same time. At that time I started Kontact. There are two IMAP-SSL connections for two different users on the server which are shown in this log all coming from the 1:37 system. Only one is reflected in the capture file because the server has two IPv6 addresses. I made a compressed tar archive with these tow files in it.