same problem on 4.3rc1 ubuntu jaunty

4:4.2.95-0ubuntu1~jaunty1~ppa1

When a client replies with a feature-not-implemented, the server should stop sending requests (or ping here).

To keep the connection alive, kopete sends keep-alive blank packets. This packet is sent every 55 seconds (connections are often considered dead after 1 minute if no communication has been detected).

Does your connection times out before the 55 seconds keep alive packet is sent ?

Kopete sends these keepalive every 55 sec as you stated, but when the "unrecoverable protocol error" appears, the jabber server had just ack:ed one of the keepalive packages, then Kopete does a FIN ACK to port 5222, and the server prints:
session end 275 12 36 Kopete
10 seconds later I get a login again:
login ok 192.168.12.5 Kopete

Detlev, as far as I understand the tcp connection does not time out, but rather kopete tears it itself. The ping extension is described here http://xmpp.org/extensions/xep-0199.html
It does not say a server should stop pinging anywhere.

Maybe I read that somewhere, I don't remember. Anyway, I can't reproduce that bug here. I really don't know what could happen.

At which interval are sent the ping's ?

Maybee I should point out that I don't see the pings from the server, but as stated before I get the same error and that Kopete itself sends the FIN ACK, that leads or is an effect of the error.

Ping messages are sent every minute. This is what the server sends:
<iq from='[server hostname]' to='[my jid]/Kopete' id='ping_N' type='get'>
  <ping xmlns='urn:xmpp:ping'/>
</iq>

Where N is a number, changing from 0 to 8. Kopete responds with this:
<iq type="error" to="[server hostname]" id="ping_N" >
  <ping xmlns="urn:xmpp:ping"/>
  <error type="cancel" >
    <feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/>
  </error>
</iq>

When N=8, Kopete disconnects.

Using KDE 4.2.98 (KDE 4.3 RC3) on Ubuntu Jaunty, the bug is still here.

Thank you for the great job.

I'm seeing something similar, but without the ping messages. On an idle link, there seems to be a keep-alive with the client sending "\x0a" messages every ~55 seconds, and the server responding with "\x20\x0a". After maybe half an hour or an hour of idle time, the client will disconnect with an error message, and immediately reconnect. Wireshark shows nothing but that keep-alive exchange. 

Kopete version: 0.70.90
KDE version: 4.2.96 (KDE 4.2.96 (KDE 4.3 RC2))

Both from Debian "experimental" packages.

At least for me, it does not appear to be a "core" bug. I can connect to the same server from another installation of the same packages without the issue cropping up, so I guess it's either something in the user settings or something left-over from old versions in the system files.

I will play around with the user profile a bit, up to deleting the existing profile files and see if that helps.

KDE 4.3.0 - the bug is still there.

(In reply to comment #9)
> I'm seeing something similar, but without the ping messages.

I can confirm this is happening on KDE 4.3.0 on Gentoo.

No ping messages sent by the server, Kopete disconnects after half an hour. This is without any XML stanza exchanges between the client and the server, according to the Kopete XML console. I the XMPP server configured to send a white space character to the clients every 3 minutes. Removing this didn't change anything. Also, a quick look at iptraf shows that there is some exchange of packets between the client and the server, possibly the '\0x0a' sent by Kopete that you mention (I don't have time to study the traffic more now, cause I found no easy way to disable TLS in Kopete).

I tried to disable stream compression on the server, but it had no effect. So far the only thing I haven't changed is TLS, so IMHO this should be reproducible
on any recent jabberd2 installation with TLS enabled.

Kopete 0.70.90
KDE 4.3.00
Gentoo ebuilds, amd64 platform, and I have jingle compiled in. I don't know what else could be relevant.
The server is running jabberd2 2.2.8

I was connecting without SSL (just disable SSL in the "Connection" tab of the Jabber account settings) to find what I found, and all traffic was unencrypted; so SSL/TLS shouldn't be an issue.

I'm also having this issue with Gentoo GNU/Linux (amd64-arch on intel core i7).

Kopete 0.70.90
KDE 4.3.0
Server is OpenFire 3.6.4

I'm also having this issue with OpenSuse 11.1 32 bits

Kopete 0.70.90
KDE 4.3.0
Server is OpenFire 3.6.3

So, the bug started with "Kopete disconnects after 8 XMPP pings from the server" and now is "Kopete disconnects after a half an hour of idle state". What do you confirm to be still in 4.3.0 ?

Is the initial problem still present in 4.3.0 ?

For the disconnection after some idle time, could you check that your ISP doesn't disconnect and reconnect you to the network after some time ?

Also, how can I activate XMPP pings in jabberd2 ?

Detlev, I'm the bug reporter. I confirm this bug (in initial description) is still present in 4.3.0 and still very annoying because I found no way to turn off Kopete's error notifications (gray bar, appearing at random screen position).
Sorry, have no idea, how to turn pings on in jabberd2.

(In reply to comment #16)
> So, the bug started with "Kopete disconnects after 8 XMPP pings from the
> server" and now is "Kopete disconnects after a half an hour of idle state".
Unless there is any evidence to the contrary, I would guess it is safe to assume that these are either the same problem, or are closely related. 

Though in the original report it is happening after 8 minutes (8 pings), and I'm experiencing a disconnect after a random period of about 30.

> Also, how can I activate XMPP pings in jabberd2 ?
I think you can't. They don't seem to be supported. You can configure it to send white space characters to the client, which is a different thing, though.

Milko, jabberd2 main wiki page claims the server supports XEP-0199 (xmpp ping).

(In reply to comment #19)
> Milko, jabberd2 main wiki page claims the server supports XEP-0199 (xmpp ping).

It does support replies to client-to-server if the iq-ping module is loaded. It doesn't seem to support sending server-to-client pings, or at least I can't find an option to enable them.

(In reply to comment #17)
> [..] I confirm this bug (in initial description) is
> still present in 4.3.0 and still very annoying because I found no way to turn
> off Kopete's error notifications (gray bar, appearing at random screen
> position).

I can confirm this. Working on Kubuntu Jaunty with KDE 4.3.0.

I can confirm this bug on Arch Linux running KDE 4.3.0, and Kopete version 0.70.90.

I am seeing the same thing on Fedora 11 KDE 4.3 Kopete version .70.90.

This bug is still happening with KDE 4.3.1 on Arch Linux, with Kopete version 0.70.90.  Which makes sense since there is not a version change with Kopete.

*** This bug has been confirmed by popular vote. ***

If you have the debug packages installed (kdenetwork-dbg or similar) and gdb, could you run this :
 $ gdb kopete
[...]
(gdb) break XMPP::Client::disconnected()
Function "XMPP::Client::disconnected()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (XMPP::Client::disconnected()) pending.
(gdb) run --nofork

Kopete should slowly start. Do the necessary so the bug occurs.
When the bug occurs, Kopete will hang. and the gdb prompt will come back. Type :
(gdb) bt

And post the output here.

When running kopete normally from a console, post also the last 30 lines printed in the console after the bug occurs.

Also, if you have any hint on how I can configure Openfire to send me an XMPP ping every minute, that would be great :-)

Thanks.

This is the version without ping but just "empty" keepalive packets:

[...]

QPainter::hasClipping: Painter not active
QPainter::setPen: Painter not active
QPainter::worldTransform: Painter not active
[New Thread 0xaf6ffb90 (LWP 1292)]
[Thread 0xaf6ffb90 (LWP 1292) exited]
Calling appendChild() on a null node does nothing.
Enchant dict for "en_US" 0x88a1830
[New Thread 0xaf6ffb90 (LWP 2632)]
[Thread 0xaf6ffb90 (LWP 2632) exited]

Breakpoint 1, XMPP::Client::disconnected (this=0x861c550) at moc_xmpp_client.cpp:164
164     moc_xmpp_client.cpp: No such file or directory.
        in moc_xmpp_client.cpp
(gdb) bt
#0  XMPP::Client::disconnected (this=0x861c550) at moc_xmpp_client.cpp:164
#1  0xb1ce1ec1 in XMPP::Client::close (this=0x861c550) at ../../../../../kopete/protocols/jabber/libiris/iris/xmpp/xmpp-im/client.cpp:429
#2  0xb1cc2d5f in JabberClient::disconnect (this=0x861c550) at ../../../../kopete/protocols/jabber/jabberclient.cpp:800
#3  0xb1c7921a in JabberAccount::disconnect (this=0x838f630, reason=Kopete::Account::Unknown) at ../../../../kopete/protocols/jabber/jabberaccount.cpp:685
#4  0xb1c7969b in JabberAccount::slotCSError (this=0x838f630, error=1) at ../../../../kopete/protocols/jabber/jabberaccount.cpp:1030
#5  0xb1c79b1c in JabberAccount::qt_metacall (this=0x838f630, _c=QMetaObject::InvokeMetaMethod, _id=16, _a=0xbfffe58c) at ./jabberaccount.moc:156
#6  0xb740cb33 in QMetaObject::activate (sender=0x858f928, from_signal_index=6, to_signal_index=6, argv=0xbfffe58c) at kernel/qobject.cpp:3112
#7  0xb740d782 in QMetaObject::activate (sender=0x858f928, m=0xb1e044a4, local_signal_index=2, argv=0xbfffe58c) at kernel/qobject.cpp:3186
#8  0xb1cc0a83 in JabberClient::csError (this=0x858f928, _t1=1) at ./jabberclient.moc:226
#9  0xb1cc17c5 in JabberClient::slotCSError (this=0x858f928, error=1) at ../../../../kopete/protocols/jabber/jabberclient.cpp:1095
#10 0xb1cc307e in JabberClient::qt_metacall (this=0x858f928, _c=QMetaObject::InvokeMetaMethod, _id=28, _a=0xbfffe6bc) at ./jabberclient.moc:183
#11 0xb740cb33 in QMetaObject::activate (sender=0xb2800e50, from_signal_index=5, to_signal_index=5, argv=0xbfffe6bc) at kernel/qobject.cpp:3112
#12 0xb740d782 in QMetaObject::activate (sender=0xb2800e50, m=0xb7f3e9cc, local_signal_index=1, argv=0xbfffe6bc) at kernel/qobject.cpp:3186
#13 0xb7f142f3 in Kopete::SocketTimeoutWatcher::errorInt (this=0xb2800e50, _t1=1) at ./kopetesockettimeoutwatcher.moc:96
#14 0xb7f15389 in Kopete::SocketTimeoutWatcher::ackTimeoutCheck (this=0xb2800e50) at ../../../kopete/libkopete/kopetesockettimeoutwatcher.cpp:99
#15 0xb7f157ad in Kopete::SocketTimeoutWatcher::qt_metacall (this=0xb2800e50, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0xbfffe848) at ./kopetesockettimeoutwatcher.moc:77
#16 0xb740cb33 in QMetaObject::activate (sender=0xb28258a0, from_signal_index=4, to_signal_index=4, argv=0x0) at kernel/qobject.cpp:3112
#17 0xb740d782 in QMetaObject::activate (sender=0xb28258a0, m=0xb74e8de4, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3186
#18 0xb7448177 in QTimer::timeout (this=0xb28258a0) at .moc/release-shared/moc_qtimer.cpp:128
#19 0xb7412e9e in QTimer::timerEvent (this=0xb28258a0, e=0xbfffeccc) at kernel/qtimer.cpp:261
#20 0xb7407bcf in QObject::event (this=0xb28258a0, e=0xbfffeccc) at kernel/qobject.cpp:1074
#21 0xb6a37814 in QApplicationPrivate::notify_helper (this=0x809d690, receiver=0xb28258a0, e=0xbfffeccc) at kernel/qapplication.cpp:4056
#22 0xb6a3f97e in QApplication::notify (this=0xbfffef5c, receiver=0xb28258a0, e=0xbfffeccc) at kernel/qapplication.cpp:3603
#23 0xb796c4ad in KApplication::notify (this=0xbfffef5c, receiver=0xb28258a0, event=0xbfffeccc) at ../../kdeui/kernel/kapplication.cpp:302
#24 0xb73f79cb in QCoreApplication::notifyInternal (this=0xbfffef5c, receiver=0xb28258a0, event=0xbfffeccc) at kernel/qcoreapplication.cpp:610
#25 0xb7426361 in QCoreApplication::sendEvent (this=0x809ff9c) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:213
#26 QTimerInfoList::activateTimers (this=0x809ff9c) at kernel/qeventdispatcher_unix.cpp:572
#27 0xb7422900 in timerSourceDispatch (source=0x809ff68) at kernel/qeventdispatcher_glib.cpp:165
#28 0xb5cfa4b8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#29 0xb5cfda13 in ?? () from /usr/lib/libglib-2.0.so.0
#30 0xb5cfdb98 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#31 0xb7422858 in QEventDispatcherGlib::processEvents (this=0x807d690, flags=...) at kernel/qeventdispatcher_glib.cpp:327
#32 0xb6ad6fd5 in QGuiEventDispatcherGlib::processEvents (this=0x807d690, flags=...) at kernel/qguieventdispatcher_glib.cpp:202
#33 0xb73f601a in QEventLoop::processEvents (this=0xbfffeef0, flags=...) at kernel/qeventloop.cpp:149
#34 0xb73f6462 in QEventLoop::exec (this=0xbfffeef0, flags=...) at kernel/qeventloop.cpp:201
#35 0xb73f88b9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#36 0xb6a37697 in QApplication::exec () at kernel/qapplication.cpp:3525
#37 0x08059653 in main (argc=2, argv=0xbffff364) at ../../../kopete/kopete/main.cpp:104
(gdb)

And anotehr one in the same session. I continued, logged back on (which triggered the breakpoint twice), and after only a few seconds, I got the following:

[...]

(gdb) c
Continuing.
Unknown signature value:  795

Breakpoint 1, XMPP::Client::disconnected (this=0x8d3f8d0) at moc_xmpp_client.cpp:164
164     in moc_xmpp_client.cpp
(gdb) bt
#0  XMPP::Client::disconnected (this=0x8d3f8d0) at moc_xmpp_client.cpp:164
#1  0xb1ce1e32 in XMPP::Client::streamError (this=0x8d3f8d0) at ../../../../../kopete/protocols/jabber/libiris/iris/xmpp/xmpp-im/client.cpp:461
#2  0xb1ccdb4f in XMPP::Client::qt_metacall (this=0x8d3f8d0, _c=QMetaObject::InvokeMetaMethod, _id=19, _a=0xbfffe4cc) at moc_xmpp_client.cpp:137
#3  0xb740cb33 in QMetaObject::activate (sender=0x87751c8, from_signal_index=8, to_signal_index=8, argv=0xbfffe4cc) at kernel/qobject.cpp:3112
#4  0xb740d782 in QMetaObject::activate (sender=0x87751c8, m=0xb1e046b4, local_signal_index=4, argv=0xbfffe4cc) at kernel/qobject.cpp:3186
#5  0xb1cc7023 in XMPP::Stream::error (this=0x87751c8, _t1=10) at moc_xmpp_stream.cpp:112
#6  0xb1d512ea in XMPP::ClientStream::cr_error (this=0x87751c8) at ../../../../../kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/stream.cpp:611
#7  0xb1ccd922 in XMPP::ClientStream::qt_metacall (this=0x87751c8, _c=QMetaObject::InvokeMetaMethod, _id=9, _a=0xbfffe598) at moc_xmpp_clientstream.cpp:117
#8  0xb740cb33 in QMetaObject::activate (sender=0x837d5d8, from_signal_index=5, to_signal_index=5, argv=0x0) at kernel/qobject.cpp:3112
#9  0xb740d782 in QMetaObject::activate (sender=0x837d5d8, m=0xb1e046e4, local_signal_index=1, argv=0x0) at kernel/qobject.cpp:3186
#10 0xb1cc6e87 in XMPP::Connector::error (this=0x837d5d8) at moc_xmpp.cpp:85
#11 0xb1d6edce in XMPP::AdvancedConnector::bs_error (this=0x837d5d8, x=0) at ../../../../../kopete/protocols/jabber/libiris/iris/xmpp/xmpp-core/connector.cpp:715
#12 0xb1ccdee4 in XMPP::AdvancedConnector::qt_metacall (this=0x837d5d8, _c=QMetaObject::InvokeMetaMethod, _id=7, _a=0xbfffe72c) at moc_xmpp.cpp:157
#13 0xb740cb33 in QMetaObject::activate (sender=0x8c41c90, from_signal_index=8, to_signal_index=8, argv=0xbfffe72c) at kernel/qobject.cpp:3112
#14 0xb740d782 in QMetaObject::activate (sender=0x8c41c90, m=0xb1e04934, local_signal_index=4, argv=0xbfffe72c) at kernel/qobject.cpp:3186
#15 0xb1cc5923 in ByteStream::error (this=0x8c41c90, _t1=0) at moc_bytestream.cpp:113
#16 0xb1cddc5a in BSocket::qs_error (this=0x8c41c90, x=QAbstractSocket::SocketTimeoutError) at ../../../../../kopete/protocols/jabber/libiris/iris/xmpp/cutestuff/bsocket.cpp:441
#17 0xb1cce094 in BSocket::qt_metacall (this=0x8c41c90, _c=QMetaObject::InvokeMetaMethod, _id=7, _a=0xbfffe84c) at moc_bsocket.cpp:89
#18 0xb740cb33 in QMetaObject::activate (sender=0x8770ca8, from_signal_index=9, to_signal_index=9, argv=0xbfffe84c) at kernel/qobject.cpp:3112
#19 0xb740d782 in QMetaObject::activate (sender=0x8770ca8, m=0xb1e06a0c, local_signal_index=5, argv=0xbfffe84c) at kernel/qobject.cpp:3186
#20 0xb1cdce53 in QTcpSocketSignalRelay::error (this=0x8770ca8, _t1=QAbstractSocket::SocketTimeoutError) at ./bsocket.moc:139
#21 0xb1cdd067 in QTcpSocketSignalRelay::sock_error (this=0x8770ca8, _c=QMetaObject::InvokeMetaMethod, _id=11, _a=0x8738e28) at ../../../../../kopete/protocols/jabber/libiris/iris/xmpp/cutestuff/bsocket.cpp:93
#22 QTcpSocketSignalRelay::qt_metacall (this=0x8770ca8, _c=QMetaObject::InvokeMetaMethod, _id=11, _a=0x8738e28) at ./bsocket.moc:96
#23 0xb740633b in QMetaCallEvent::placeMetaCall (this=0x878c4f8, object=0x8770ca8) at kernel/qobject.cpp:477
#24 0xb7407e10 in QObject::event (this=0x8770ca8, e=0x878c4f8) at kernel/qobject.cpp:1110
#25 0xb6a37814 in QApplicationPrivate::notify_helper (this=0x809d690, receiver=0x8770ca8, e=0x878c4f8) at kernel/qapplication.cpp:4056
#26 0xb6a3f97e in QApplication::notify (this=0xbfffef5c, receiver=0x8770ca8, e=0x878c4f8) at kernel/qapplication.cpp:3603
#27 0xb796c4ad in KApplication::notify (this=0xbfffef5c, receiver=0x8770ca8, event=0x878c4f8) at ../../kdeui/kernel/kapplication.cpp:302
#28 0xb73f79cb in QCoreApplication::notifyInternal (this=0xbfffef5c, receiver=0x8770ca8, event=0x878c4f8) at kernel/qcoreapplication.cpp:610
#29 0xb73f860e in QCoreApplication::sendEvent (receiver=0x0, event_type=0, data=0x807d940) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:213
#30 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x807d940) at kernel/qcoreapplication.cpp:1247
#31 0xb73f87ed in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1140
#32 0xb7422c0f in QCoreApplication::sendPostedEvents (s=0x809f900) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:218
#33 postEventSourceDispatch (s=0x809f900) at kernel/qeventdispatcher_glib.cpp:210
#34 0xb5cfa4b8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#35 0xb5cfda13 in ?? () from /usr/lib/libglib-2.0.so.0
#36 0xb5cfdb98 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#37 0xb7422858 in QEventDispatcherGlib::processEvents (this=0x807d690, flags=...) at kernel/qeventdispatcher_glib.cpp:327
#38 0xb6ad6fd5 in QGuiEventDispatcherGlib::processEvents (this=0x807d690, flags=...) at kernel/qguieventdispatcher_glib.cpp:202
#39 0xb73f601a in QEventLoop::processEvents (this=0xbfffeef0, flags=...) at kernel/qeventloop.cpp:149
#40 0xb73f6462 in QEventLoop::exec (this=0xbfffeef0, flags=...) at kernel/qeventloop.cpp:201
#41 0xb73f88b9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888
#42 0xb6a37697 in QApplication::exec () at kernel/qapplication.cpp:3525
#43 0x08059653 in main (argc=2, argv=0xbffff364) at ../../../kopete/kopete/main.cpp:104
(gdb) c
Continuing.

Breakpoint 1, XMPP::Client::disconnected (this=0x8d3f8d0) at moc_xmpp_client.cpp:164
164     in moc_xmpp_client.cpp
(gdb) c
Continuing.

Breakpoint 1, XMPP::Client::disconnected (this=0x8d3f8d0) at moc_xmpp_client.cpp:164
164     in moc_xmpp_client.cpp
(gdb) c
Continuing.
Unknown signature value:  795

Created attachment 36957 [details]
xep-0199 respond for kopete in KDE 4.3.1

Patch from http://machekku.uaznia.net/xmpp/psi/patches/?all#make_psi_pingable passed into Kopete.

Created attachment 36958 [details]
xep-0199 respond for kopete in KDE 3.5.10

I have debian packages for kopete in KDE 3.5.10 compiled with this patch and often disconnects are gone.
Patch for kopete in KDE 4.3.1 is not tested.

The patch looks OK for answering ping messages from the server. Could people try it please ?

The backtrace shows a problem with Kopete's SocketTimeoutWatcher. I did not find it yet :-(

The patch for KDE 4.3.1 is in my patch queue. We don't maintain the version 
for KDE 3.5.10 anymore. Thanks for the contribution!

I can confirm similar behavior in Fedora 11 with KDE 4.3.1 and Kopete 0.70.90

Problems still exists on KDE 4.3.2. 

Tested the patch "xep-0199 respond for kopete in KDE 4.3.1" which perfectly applies to kdenetwork-4.3.2, but the problem, although less often, still seems to be present?

(In reply to comment #35)
> the problem, although less often, still seems
> to be present?

Yep. Still disconnects from time to time. Maybe because of another bug this time :)

Confirmed, problem still exists in 4.3.2 

Gentoo Linux, KDE 4.3.2 Kopete 0.80.2
Jabberd2 server on same LAN

Tried 2 different servers, one without SSL support, jabberd2-2.1.19, the other with SSL, jabberd2-2.2.8. Same problem with Kopete on both servers.

Older clients (KDE 3.5.9 or Windows with Spark, Pidgin and Mac with Adium) have no problems with the same servers.

I have the same problem with Kopete 4.3.2 (0.80.2) on Kubuntu 9.10. Kopete disconnects from a jabber server every 15-20 minutes and reconnects. Wireshark shows that Kopete is just sending a FIN in the TCP connection.

There is no PING coming from the server.

Could someone attach a full network activity log from the time kopete is connected up to the time it disconnects ?
Wireshark is able to log only packets from/to a specific address I think.
If the problem also happens without encryption, use a clear connection so I cana see the content (feel free to remove messages stanzas but not presence stanzas from you to the server, it might be a possible problem).

I have the same problem, kopete keeps diconnecting after 4m45s of INACTIVITY - if I'm chatting with smeone on that account, everything goes well.

I have tried the patch and it did not help me (kopete 4.3.1).

I have a packet capture of a connection that ends with the error after only around 60 exchanged packets without any messaging activity. However, it's hard to anonymize those traces. I tried to create a trash account on the same server and captured for quite some time, but that connection never broke. I will keep capturing that account and see if I can upload a trace.

The whole thing is not terribly interesting as I said before. After the connection is established, the contact list and status are fetched from the server, and the client (IIRC) just sends a single space character as part of the XML stream, which is probably a keepalive.

The whole thing would be a lot easier if at least libiris did some visible print debugging in the error conditions.

Created attachment 38248 [details]
Packet capture from a broken connection

So here is a capture from a very basic connection that ends in an unrecoverable error...

I'm not sure this is directly related to this bug, but I had a segfault shortly after I was disconnected from the Jabber server. I can trigger the segfault by closing the Kopete main window during the "outtime" of the server I think.

I have attached some debug information to this bug.

Created attachment 38563 [details]
Stacktrace of Kopete segfault with Kubuntu debug packages

The problem seems to be still there in KDE 4.3.4

I can confirm that the problem continues in KDE 4.3.4 with Kopete 0.80.2 running on Fedora 12

I am experiencing this problem with the public jabber.org server. My corporate Jabber-Server (I think Openfire) does work fine, though.

Kopete disconnects after a few seconds (~5). 

Problem occurs on KDE 4.3.4 (Kubuntu Karmic Backports) as well as on KDE 4.3.95/Kopete 0.99.90, Kubuntu Lucid.

.. reproducible.

Problem is still there in KDE 4.3.5

I can reproduce it on 4.3.95
Kopete disconnects from my companys jabber server multiple times a day. And sometimes Kopete doesn´t reconnect automatically, which is very bad.

One thing I notice is that I can connect to the server from home without any issues, while it frequently disconnects me in the office. The server is on a local network then, so there's a very low RTT. Is it possible that there is a race between two asynchronous processes that somehow make a response visible too early, thus breaking a state machine?

Some more digging, and I'm quite uneasy about the whole Jabber support. It seems like Kopete is using the "iris" part of Psi, but in a version from March 2007 with some patches slapped on to it. Is that right so far, and are there any plans to resync with Psi, or use something different like gloox (http://camaya.net/gloox/)?

Iris has been synced in the mid-2009...

Gloox seems interresting.
As for the problem, Iris doesn't have any problem. The problem certainly comes from the KopeteSocketTimeOutWatcher which disconnects kopete when there doesn't seem to be a connection anymore.

A slow RTT could confirm that and the bug seems to have started to happen approximatively when the Watcher was commited.

I'll look into that.

Still persistent in Kopete 0.80.2, KDE 4.3.2 kubuntu packages.

Investigation brought to light: Kopete sends newlines every now and then. (\x0a), which ejabberd ignores (because this behaviour is not conform to standards anyway)

After that kopete closes the connection with a TCP fin, and ejabberd acknowledges it.

Kopete however says, it is a non resolvable networkproblem (which it isn't obviously).

Please at least add an option to disable this faulty ping behaviour.

I do not think that the newline (or any whitespace) on itself is breaking standards compliance. The protocol forbids a few XML features (see RFC  3920, section 11.1), but I can't find anything speaking against arbitrary whitespace in the XML stream, which itself does not carry any semantics, and should be a perfectly acceptable keepalive mechanism.

Also note that /the client/ is sending those newlines, and it is then /the client/ which breaks the connection. The server does not show any behaviour indicating an error state or provoking link termination.

Whatever you do, at least make it a high-priority item to use another notification method (e.g. the same one as for messages) for those errors. I can live with Kopete dropping the connection every 5 minutes, but the goddamn popup in random places is not only annoying, it also completely destroys XRender accelerated desktops with some applications like RDC, since it will blank out the whole screen.

Still persistent in Kopete 1.0.0, KDE 4.4.2 kubuntu karmic with kubuntu-ppa packages.

The same for me with Kopete 1.0.0, KDE 4.4.2 (Ubuntu Lucid). Kopete works fine on my desktop computer, but does not work on other installations. There, for one server (gmx.net) it works, for another, it doesn't. The first time the error occured was after the transition from Ubuntu Jaunty to Ubuntu Karmic.

This is the error message I get:

kopete(14467) Kopete::SocketTimeoutWatcher::ackTimeoutCheck: Connection timeout for   QHostAddress( "..." )  
Unknown signature value:  795

Why is there an artificial timeout watchdog anyway? You're dealing with a TCP connection, and get that kind of thing for free form the protocol.

(In reply to comment #56)
> Whatever you do, at least make it a high-priority item to use another
> notification method (e.g. the same one as for messages) for those errors. I can
> live with Kopete dropping the connection every 5 minutes, but the goddamn popup
> in random places is not only annoying, it also completely destroys XRender
> accelerated desktops with some applications like RDC, since it will blank out
> the whole screen.

It also makes it annoying to watch movies when you're online on Jabber, since you have popups over the movie once in a while, sometimes over the subtitles, which is pretty annoying. Also, if Kopete blocks, the popup is uncloseable until it unblocks (which is the case on my machine). I have found a way to disable all other popups (I can't fathom how one would consider popup for anything by default a good idea, let alone *everything*).

But that's not what's most annoying:
1. It loses messages. If you have typed 500 character messages, and press enter to send it, it sometimes happens to trigger a disconnect, which loses the message – it's not saved anywhere, it completely goes away, and I have to type again.
2. It litters the chat window history with connect-disconnect messages, so if you have friends using Kopete, the chat window history of slow chats becomes unusable. 
3. It plays bad with the statistics plugin – Kopete blocks for 10 seconds on Jabber disconnect for me, until it writes the statistics for the contacts, because going offline means it should write something, you know.

(In reply to comment #59)
> Why is there an artificial timeout watchdog anyway? You're dealing with a TCP
> connection, and get that kind of thing for free form the protocol.

That's not true, most of the operating systems will close the connection after some time if it is inactive. That's why a blank space is sent every some seconds.
The watchdog is supposed to be used for other protocols, not sure it's made for xmpp as Iris checks if the connection is still up.

The watchdog seems to wait for ACKs to arrive within 15 seconds by default. I haven't looked at it all too much, but from what I've seen, it adds little value. A TCP socket will detect a broken connection on system level and should raise an appropriate error.

I'm now running a build of 1.0.0 with the watchdog disabled for Jabber. Let's see how that works out.

And just while I'm writing this, the watchdog kicked me off MSN.

> That's not true, most of the operating systems will close the connection after
> some time if it is inactive.

No operating system ever closes a TCP connection if inactive.

NATs can remove the entry from the translation table after a period of inactivity, however the timeout is usually very long.

TCP has a slow keepalive mechanism that prevents that timeout to fire.

However, there are ISPs massively NAT-ing people that tuned their NATs to remove TCP connections from the translation table much earlier (Fastweb in Italy comes to mind), thus an application-level keepalive should still be present.

Anyway that souldn't trigger disconnection, so, this bug is still present for me (and quite annoying to me an my contacts since they continuously see me going online and offline).

I think the problem is still present in our internal company network. No NAT or large delays involved.

After sitting in a jabber group channel for a few minutes I got an error message ("Fatal error in the jabber contact pool"). When I press okay kopete reconnects to the jabber server.

Just to clear things, most protocols have they own ping packet so they can detect when the connection is broken because otherwise the detection would only occur when we (Kopete/protocol) send something. So if I simplify it without the ping packets and without user interaction the connection could be broken for hours and Kopete will not detect it.

The SocketTimeoutWatcher does this, when Kopete(protocol) sends something to server it check if the server got the packet, to be precise if we got the TCP acknowledge packet within 15 seconds, if not it closes the socket and Kopete reconnects the protocol.

SocketTimeoutWatcher is there for all protocols because on linux (maybe on other platforms too) when kernel doesn't get ACK packet it disconnects the connection after long time something like 10 or more minutes so with SocketTimeoutWatcher we can detect it within seconds.

I thing that we may mix to bugs here:
1. Unstable Internet connection => SocketTimeoutWatcher disconnects often.
2. Jabber protocol problem with ping.

Btw. I use jabber.cz and ICQ and I don't have any problems.

> SocketTimeoutWatcher is there for all protocols because on linux (maybe on
> other platforms too) when kernel doesn't get ACK packet it disconnects the
> connection after long time something like 10 or more minutes

That wouldn't be normal, the OS only drops a TCP connection when TCP keepalive is enabled and the peer is not responding to keepalive probes.

This would amount to 7200 seconds or so, and only if the other pear disappears.

I have ssh sessions with TCPkeepalive disabled and my box (with a stateful firewall in between) can hibernate for the whole night and the connections would be already working the day after.

Well maybe Qt detect the timeout and not kernel but something will disconnect the connection when it's broken but the problem is that it takes long time and this is problem for IM. 

I don't know exactly how ssh works buy I know you can't do this in IM protocols because the server will close the session automatically after some period of time and you have to relogin.

Well, I can only tell, that I have quite big problems with mobile (3G) connections, Kopete often disconnects out of nothing. That would speak for the watchdog problem. Is there any debug information I should look for?

Maybe 15 seconds is just not enough (3G connections tend to have ping's over 3 secs from time to time, which amounts to quite some time already!)

(In reply to comment #65)
> Just to clear things, most protocols have they own ping packet so they can
> detect when the connection is broken because otherwise the detection would only
> occur when we (Kopete/protocol) send something. So if I simplify it without the
> ping packets and without user interaction the connection could be broken for
> hours and Kopete will not detect it.

Definitely not. TCP will give you pretty decent feedback on broken connections on all but the most broken networking stacks.

> The SocketTimeoutWatcher does this, when Kopete(protocol) sends something to
> server it check if the server got the packet, to be precise if we got the TCP
> acknowledge packet within 15 seconds, if not it closes the socket and Kopete
> reconnects the protocol.

The watcher looks semantically wrong, and from how I read it, it's mostly luck that it works in the first place. What it does is raise a "RemoteHostClosedError", which is likely not what happened. What happens is that the local client decides to break the link. It is only lucky that the client then proceeds with a sane disconnection.

Effectively though, trying to disconnect in such a situation is making things worse, since if the mechanism is working correctly, it's trying to force a connection state change over an already bad link. If the underlying network doesn't manage to work around the cause, don't try to irritate the TCP/IP stacks on client and server! Let the protocol works its magic.

In short, a watchdog may be a good thing with protocols using an application-layer ACK, but when fiddling with TCP internals, that's likely not a good idea.

> I thing that we may mix to bugs here:
> 1. Unstable Internet connection => SocketTimeoutWatcher disconnects often.
> 2. Jabber protocol problem with ping.

I think it's really the same thing, just observed differently depending on whether the explicit ping is used or not.

> Btw. I use jabber.cz and ICQ and I don't have any problems.

I only have the problem at the office, where the Jabber server is in the local network. It works fine from home.

Hi everybody. As the bug submitter I must say that the bug is no longer present for me. I had not used Kopete for quite some time because it was too annoying but decided to give 4.4.3 a try. Again :). Like I said - Kopete does not disconnect from my office server anymore. Judging by the number of comments and votes for this bug, there must be another malfunction which causes random disconnections, but I guess the original one is vanished. It's a pity I can't tell when exactly it was fixed or was it caused by some changes in local jabber server configuration.

Just updated to KDE 4.3.3, Kopete 1.0.0, the bug is still here

The bug is still present. Only the error message is not longer showing, but you will still be disconnected every so often.

I think Bug 212585 is a duplicate of this bug. I posted a patch there that fixes the problem.

Created attachment 43471 [details]
Proposed patch

I just notices that I accidentially submitted a reverse patch on Bug 212585. So here is the corrected patch.

I just want to say that the proposed patch that goes with comment #73 seems to fix this issue for me on my company's internal eJabberd server.

I tested the patch (comment #73) with kopete 4.4.3 for 4 days now and it works really fine. Thank you!

> I tested the patch (comment #73) with kopete 4.4.3 for 4 days now and it works
> really fine. Thank you!

Is there anybody out there who could commit the patch to the current KDE sourcecode, or maybe even backport it to 4.4.4? Or is there some kind of further QA procedure that needs to happen beforehand?

The issue persists with version 1.0.0 from KDE 4.4.5.

(In reply to comment #77)
> The issue persists with version 1.0.0 from KDE 4.4.5.

Same here with Kopete 4:4.4.92-0ubuntu1~lucid1~ppa1
Version 1.0.80
Using KDE Development Platform 4.4.92 (KDE 4.4.92 (KDE 4.5 RC2))

No wonder, since the patch from comment#73 has not been incorporated into the codebase, as far as I understand.

Stephan Krause's patch in comment #73 works for me.  I'm running an eJabberd on my local network.

KDE 4.6, Gentoo, clean system. Bug still exist.
Over local network without NAT and aver interner bug exist.

Removing myself from Cc: on this bug. I quit using Kopete because of this bug. The patch to fix this has been sitting here for 9 months and none of the developers with commit access have taken any real action on this matter.

I'am sorry, but I have make mistake. :)
I have reach another bug that leads to disconnect/connect like this.

Bug apeeared as parse error, when handling incoming xml string like this:

<iq from='from@anywhere.com' id='aacfa' to='to@anywhere.com/Kopete' type='result'>
<query xmlns='jabber:iq:last'>some text some text<br>another text/query></iq>

Tag <br> is parsed as ill-formed element, and error occured.

<br> *is* an ill-formed element, having it there should cause disconnection of both the server and the client.

Can I commit the proposed patch to Kopete or do you want to debug it even further?

(I'm the submitter of the patch) Well, the patch is pretty straightforward, and the bug is pretty obvious: Instead of checking if the time between the last send data is bigger than the threshold, the code currently checks the time difference between the last received ack and the last send data (which is not meaningful). Also, due to the inaccuracy of the timestamps, on a fast network the ack can happen the same time as send data. The patch fixes both issues (which is also confirmed by several comments), and breaks nothing, so I don't see a reason not to commit the patch.

Wow, it was a matter of just a bit less then 2 years to fix the bug! Guys, will you please wait a bit more, till the 3rd of July - my bugreport wants to celebrate its second birthday so much :)

SVN commit 1225245 by lvsouza:

Fix for Kopete disconnects after several xmpp ping messages from jabber server

BUG: 198789
FIXED-IN: 4.6.2


 M  +1 -1      kopetesockettimeoutwatcher.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1225245

SVN commit 1225246 by lvsouza:

Backport r1225245: Fix for Kopete disconnects after several xmpp ping messages from jabber server

BUG: 198789
FIXED-IN: 4.6.2


 M  +1 -1      kopetesockettimeoutwatcher.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1225246