Version: SVN (using KDE Devel) Installed from: Compiled sources Compiler: Gcc 4.2.2 OS: Linux I set up kopete from svn to connect to my gtalk account the same way as kopete in kde3, but it does not finish connecting. Here is the log: kopete(13396)/kopete (jabber) JabberAccount::connectWithPassword: Connectingto Jabber server "talk.google.com" : 5223 kopete(13396)/kopete (jabber) JabberAccount::setPresence: Status: "connecting" , Reason: "" kopete(13396)/kopete (jabber) JabberResourcePool::addResource: Adding new resource "Kopete" for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::addResource: Initial update of capabilities for JID: "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberBaseContact::reevaluateStatus: Determining new status for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::bestJabberResource: Determining best resource for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::lockedJabberResource: No lock available for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::bestJabberResource: Taking' "Kopete" ' as first available resource. kopete(13396)/libkopete Kopete::OnlineStatusManager::cacheLookupByObject: Missed "Connecting/jabber_protocol/#000000/jabber_connecting/16/a" in icon cache! kopete(13396)/kopete (jabber) JabberBaseContact::reevaluateStatus: New status for "tageorgiou@gmail.com" is "Connecting" kopete(13396) KopeteWindow::slotIdentityStatusIconChanged: QVariant(, ) kopete(13396)/kopete (jabber) JabberResourcePool::lockToResource: Locking "tageorgiou@gmail.com" to "Kopete" kopete(13396)/kopete (jabber) JabberResourcePool::removeLock: Removing resource lock for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::removeLock: No locks found. kopete(13396)/kopete (jabber) JabberConnector::JabberConnector: New Jabber connector. kopete(13396)/kopete (jabber) JabberByteStream::JabberByteStream: Instantiating new Jabber byte stream. kopete(13396)/kopete (jabber) JabberConnector::setOptSSL: Setting SSL to true kopete(13396)/kopete (jabber) JabberConnector::setOptHostPort: Manually specifying host "talk.google.com" and port 5223 kopete(13396)/kopete (jabber) JabberByteStream::close: Closing stream. kopete(13396)/kopete (jabber) JabberConnector::connectToServer: Initiating connection to "gmail.com" kopete(13396)/kopete (jabber) JabberByteStream::connect: Connecting to "talk.google.com" , service "5223" kopete(13396)/kdecore (KNetwork resolver) <unnamed>::ResInitUsage::shouldResInit: shouldResInit: /etc/resolv.conf updated kopete(13396)/kopete (jabber) JabberConnector::slotConnected: We are connected. About 30s wait kopete(13396)/kopete (jabber) JabberByteStream::slotError: Socket error ' "remote host closed connection" ' - Code : 17 kopete(13396)/kopete (jabber) JabberByteStream::slotConnectionClosed: Sockethas been closed. kopete(13396)/kopete (jabber) JabberByteStream::close: Closing stream. kopete(13396)/kopete (jabber) JabberByteStream::close: Closing stream. kopete(13396)/kopete (jabber - raw protocol) JabberAccount::slotClientDebugMessage: "Disconnected, freeing up file transfer port..." kopete(13396)/kopete (jabber) JabberAccount::slotCSDisconnected: Disconnected from Jabber server. kopete(13396)/kopete (jabber) JabberResourcePool::clear: Clearing the resource pool. kopete(13396)/kopete (jabber) JabberResourcePool::slotResourceDestroyed: Resource has been destroyed, collecting the pieces. kopete(13396)/kopete (jabber) JabberBaseContact::reevaluateStatus: Determining new status for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::bestJabberResource: Determining best resource for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberResourcePool::lockedJabberResource: No lock available for "tageorgiou@gmail.com" kopete(13396)/kopete (jabber) JabberBaseContact::reevaluateStatus: New status for "tageorgiou@gmail.com" is "Offline" kopete(13396) KopeteWindow::slotIdentityStatusIconChanged: QVariant(, ) I tried using qca from kdesupport and from my distro, both on a clean install of KDE4.
Did you install the qca2-openssl plugin?
Yes, i tried the openssl qca2 package from my distro (gentoo (overlay)) and compiling from svn should include it as well, no? Is there any way I can check qca and tls?
Exactly the same problem here... kdelibs and kdenetwork are upto date from SVN, kopete doesn't have any other accounts, and the whole thing is running on a fresh ~/.kde. The debug output seems to show a timeout, right after it's connected, which seems to indicate that it's waiting for something in there. I've been trying to trace exactly where this could be happening, but I haven't had any luck so far.
I have the same problem with kde 4.0.0 (gentoo overlay). Similar debug output, no connection to googletalk. The first time I tried to connect I got an error that an QCA plugin is missing (have not managed to reproduce this, even with deleting all Kopete config files), but qca-ossl is clearly installed: core2 libiris # qcatool2 plugins --debug Qt Library Paths: /usr/lib64/qt4/plugins /usr/bin plugin: checking in path: [/usr/lib64/qt4/plugins] plugin: checking file: [/usr/lib64/qt4/plugins/crypto/libqca-ossl.so] plugin: PluginInstance fromFile [/usr/lib64/qt4/plugins/crypto/libqca-ossl.so] plugin: loaded as [opensslPlugin] plugin: ProviderItem created: [qca-ossl] plugin: item added [qca-ossl] plugin: checking in path: [/usr/bin] Available Providers: qca-ossl This product includes cryptographic software written by Eric Young (eay@cryptsoft.com) plugin: PluginInstance deleted [opensslPlugin] Could it be that the Kopete jabber plugin is still searching for the qca-tls plugin (which doesn't exist anymore in qca2) ?
QCA says I have qca-ossl installed too. And now im using packages from official gentoo portage tree. Could someone write a simple program that tries to use qca-ossl? thomas@Apollo ~ $ qcatool2 plugins --debug Qt Library Paths: /usr/lib64/qt4/plugins /usr/bin /usr/kde/4.0/lib/kde4/plugins plugin: checking in path: [/usr/lib64/qt4/plugins] plugin: checking file: [/usr/lib64/qt4/plugins/crypto/libqca-ossl.so] plugin: PluginInstance fromFile [/usr/lib64/qt4/plugins/crypto/libqca-ossl.so] plugin: loaded as [opensslPlugin] plugin: ProviderItem created: [qca-ossl] plugin: item added [qca-ossl] plugin: checking in path: [/usr/bin] plugin: checking in path: [] plugin: checking in path: [/usr/kde/4.0/lib/kde4/plugins] Available Providers: qca-ossl This product includes cryptographic software written by Eric Young (eay@cryptsoft.com) plugin: PluginInstance deleted [opensslPlugin]
Confirming, same behavior here. Gentoo + KDE4 SVN overlay, updated to latest SVN. qca packages from official Gentoo tree. My qca2 output: Qt Library Paths: /usr/lib64/qt4/plugins /usr/bin /usr/kde/svn/lib64/kde4/plugins plugin: checking in path: [/usr/lib64/qt4/plugins] plugin: checking file: [/usr/lib64/qt4/plugins/crypto/libqca-ossl.so] plugin: PluginInstance fromFile [/usr/lib64/qt4/plugins/crypto/libqca-ossl.so] plugin: loaded as [opensslPlugin] plugin: ProviderItem created: [qca-ossl] plugin: item added [qca-ossl] plugin: checking in path: [/usr/bin] plugin: checking in path: [] plugin: checking in path: [/usr/kde/svn/lib64/kde4/plugins] Available Providers: qca-ossl This product includes cryptographic software written by Eric Young (eay@cryptsoft.com) plugin: PluginInstance deleted [opensslPlugin] Could this be related to the 64bit architecture? (we all have libraries under /usr/lib64, apparently...)
I've verified that the disconnect problem exists in Psi, which uses qca-ossl also. I suspect it's an upstream issue.
This is not a 64-bit issue, as I am experiencing the same with x86 (32 bit). Using Gentoo+KDE4 SVN overlay and having just updated to the latest revision. Compiled everything with GCC 4.1.2.
This problem only happens with gtalk. I did connect with ssl in jabber-hispano.org and the connection worked well. Comparing with kopete in kde 3.5, when I need enable the password in plain text option, maybe that option in kopete on kde 4.0 isn't working localhost ~ # qcatool2 plugins --debug Qt Library Paths: /usr/lib/qt4/plugins /usr/bin plugin: checking in path: [/usr/lib/qt4/plugins] plugin: checking file: [/usr/lib/qt4/plugins/crypto/libqca-cyrus-sasl.so] plugin: PluginInstance fromFile [/usr/lib/qt4/plugins/crypto/libqca-cyrus-sasl.so] plugin: loaded as [saslPlugin] plugin: ProviderItem created: [qca-cyrus-sasl] plugin: item added [qca-cyrus-sasl] plugin: checking file: [/usr/lib/qt4/plugins/crypto/libqca-gnupg.so] plugin: PluginInstance fromFile [/usr/lib/qt4/plugins/crypto/libqca-gnupg.so] plugin: loaded as [gnupgPlugin] plugin: ProviderItem created: [qca-gnupg] plugin: item added [qca-gnupg] plugin: checking file: [/usr/lib/qt4/plugins/crypto/libqca-logger.so] plugin: PluginInstance fromFile [/usr/lib/qt4/plugins/crypto/libqca-logger.so] plugin: loaded as [loggerPlugin] plugin: ProviderItem created: [qca-logger] plugin: item added [qca-logger] plugin: checking file: [/usr/lib/qt4/plugins/crypto/libqca-ossl.so] plugin: PluginInstance fromFile [/usr/lib/qt4/plugins/crypto/libqca-ossl.so] plugin: loaded as [opensslPlugin] plugin: ProviderItem created: [qca-ossl] plugin: item added [qca-ossl] plugin: checking file: [/usr/lib/qt4/plugins/crypto/libqca-pkcs11.so] plugin: PluginInstance fromFile [/usr/lib/qt4/plugins/crypto/libqca-pkcs11.so] plugin: loaded as [pkcs11Plugin] plugin: ProviderItem created: [qca-pkcs11] plugin: item added [qca-pkcs11] plugin: checking in path: [/usr/bin] Available Providers: qca-cyrus-sasl qca-gnupg qca-logger qca-ossl This product includes cryptographic software written by Eric Young (eay@cryptsoft.com) qca-pkcs11 plugin: PluginInstance deleted [saslPlugin] plugin: PluginInstance deleted [gnupgPlugin] plugin: PluginInstance deleted [loggerPlugin] plugin: PluginInstance deleted [opensslPlugin] plugin: PluginInstance deleted [pkcs11Plugin]
*** This bug has been confirmed by popular vote. ***
Cannot reproduce anymore with kopete 4.0.61. Thanks! :)
I had tried to use kopete 0.50.1 from kde 4.0.1 and the problem is still occurring with jabber plus ssl. This new kopete will came with kde 4.0.2?
No, it will be for KDE 4.1 only. We updated the libiris backend library for KDE 4.1 and that's not something I'm comfortable doing for KDE 4.0.2. If it proves stable enough, then maybe it will be done for KDE 4.0.3.
> We updated the libiris backend is there a link to the update? is it small enough of an update that one could apply to 4.0.1 or 4.0.2 sources manually? I'd LOVE to test, but I'd rather not build all of KDE from SVN or whatever just to test this one thing... (using gentoo - perhaps there is an overlay or something?) Thanks.
I think a patch would be great... KDE 4 is nice, but without a working kopete it's useless for normal work... (I'm using Gentoo too, so a patch or an overlay would be great. This way we could test the thing before 4.1)
Strange, but I am still experiencing the same issue with 0.50.50 (KDE 4.0.62, just updated from SVN). I did not try to reboot after the update, though, in case it matters. For the Gentoo guys: why not just to build from SVN using the KDE overlay (*-9999.4 ebuilds)? It is not really "to test one thing", as development is really rapid, and noticeable changes occur in many modules.
Unfortunately there is no SVN ebuild for the split builds (kde-base/Kopete in this case) in the KDE overlay... :(
my kde4 machines are not 'for testing' - rather, for using. If a single patch increases ability to 'use' I'd like to be able to apply (and test) it, singularly. If not, no big deal - I'm happy with what has been provided thus far, content to wait, and thankful for the efforts.
Henning: I do not think there will be any. Even classic split builds build the whole package (network in this case).
I compiled latest revision of kdenetwork today, but still wasn't able to connect to GTalk. Maybe I had to update other (KDE) packages too?
Problem might be in qca* packages.
I have latest versions of qca (2.0.0) and qca-ossl (2.0.0_beta3) from Gentoo Portage
Me too, no luck with latest SVN from today :( Same as it has always been. Is it worth trying to install qca from the kde repo instead of the released tarballs?
I have the same behaviour as above with MSN account on kopete 4.0.2 (kde 4.0.2) on gentoo x64. The 4.0.0 and 4.0.1 , were working fine... Stopped working today after upgrade to 4.0.2
With kopete 4.0.2 I've still continuing without connect to a jabber server over ssl. The workaround for me is use kopete from kde 3.5 with kde 4.
Just to add a none gentoo user to the mix.... I have this error as well. My output is the same as the one in the initial report. I have tried with the debian packaged qca2-openssl and the one in kdesupport.
I've compiled psi-svn, which is also using the same qca. It seems to connect properly, so I doubt that qca is the culprit.
Here's another gentoo-64-user hitting this bug, on 2 different machines. I've tried compiling qca from svn, didn't work. Turning off the "allow plaintext passwords authentication" doesn't have any effect, and neither does specifying a wrong password, so I think kopete forgets to send the authentication-info once the ssl-connection has been setup, or something like that.
If you take a look inside the ldd of all kopete libs, I am confused why kopete has linked only in /usr/kde/4.0/lib64/libiris_kopete.so and /usr/kde/4.0/lib64/kde4/kopete_jabber.so. ( As a Gentoo user, I've used equery to get it out : equery files kde-base/kopete | grep "/usr/kde/4.0/lib64" | xargs ldd >> /root/kopeteldd.txt ) OpenSSL is linked in MSN, but not QCA-Ossl! I've enabled debugging and tried to get something out of it by using strace to get more information about what happens, but a deadlock made it impossible : stat("/usr/kde/4.0/share/config/kopeterc", {st_mode=S_IFREG|0644, st_size=486, ...}) = 0 close(5) = 0 munmap(0x2b257a3a2000, 4096) = 0 stat("/root/.kde4.0/share/config/kopeterc", {st_mode=S_IFREG|0600, st_size=339, ...}) = 0 open("/root/.kde4.0/share/config/kopeterc", O_RDONLY) = 5 stat("/root/.kde4.0/share/config/kopeterc", {st_mode=S_IFREG|0600, st_size=339, ...}) = 0 stat("/root/.kde4.0/share/config/kopeterc", {st_mode=S_IFREG|0600, st_size=339, ...}) = 0 fstat(5, {st_mode=S_IFREG|0600, st_size=339, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b257a3a2000 lseek(5, 0, SEEK_CUR) = 0 read(5, "[$Version]\nupdate_info=kopete-pl"..., 4096) = 339 stat("/root/.kde4.0/share/config/kopeterc", {st_mode=S_IFREG|0600, st_size=339, ...}) = 0 lseek(5, 339, SEEK_SET) = 339 stat("/root/.kde4.0/share/config/kopeterc", {st_mode=S_IFREG|0600, st_size=339, ...}) = 0 close(5) = 0 munmap(0x2b257a3a2000, 4096) = 0 pipe([5, 6]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b2579de1f60) = 21162 close(6) = 0 read(5, QMutex::lock: Deadlock detected in thread 47439958384336 <unfinished ...> The only thing I got out of kopete, as posted before was : kopete(16849)/libkopete KopetePasswordRequest::begin: kopete(16849)/libkopete Kopete::WalletManager::openWalletInner: about to open wallet async kopete(16849)/libkopete Kopete::WalletManager::slotWalletChangedStatus: isOpen: true kopete(16849)/libkopete Kopete::WalletManager::slotWalletChangedStatus: Succesfully opened the wallet ! kopete(16849)/libkopete KopetePasswordRequest::walletReceived: kopete(16849) KopeteWindow::slotIdentityStatusIconChanged: QVariant(, ) kopete(16849)/libkopete Kopete::OnlineStatusManager::cacheLookupByObject: Missed "Verbinden/msn_protocol/#000000/msn_connecting/16/a" in icon cache! kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotReadyWrite: Sending command: "VER 0 MSNP11 MSNP10 CVR0" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotDataReceived: "VER 0 MSNP11 MSNP10 CVR0" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotReadyWrite: Sending command: "CVR 1 0x0409 winnt 5.1 i386 MSNMSGR 7.0.0816 MSMSGS lfwdpah@hotmail.com" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotDataReceived: "CVR 1 8.5.1302 8.5.1302 8.1.0178 http://msgr.dlservice.microsoft.com/download/5/6/4/5646481F-33EF-4B08-AF00-4904F7677B89/EN/Install_WLMessenger.exe http://messenger.msn.com Ú" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotReadyWrite: Sending command: "USR 2 TWN I lfwdpah@hotmail.com" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotDataReceived: "XFR 2 NS 207.46.111.50:1863 0 207.46.28.93:1863" kopete(16849)/kopete (msn) MSNSocket::slotSocketClosed: Socket closed. kopete(16849)/kopete (msn) MSNNotifySocket::~MSNNotifySocket: kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotReadyWrite: Sending command: "VER 0 MSNP11 MSNP10 CVR0" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotDataReceived: "VER 0 MSNP11 MSNP10 CVR0 ^" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotReadyWrite: Sending command: "CVR 1 0x0409 winnt 5.1 i386 MSNMSGR 7.0.0816 MSMSGS lfwdpah@hotmail.com" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotDataReceived: "CVR 1 8.5.1302 8.5.1302 8.1.0178 http://msgr.dlservice.microsoft.com/download/5/6/4/5646481F-33EF-4B08-AF00-4904F7677B89/EN/Install_WLMessenger.exe http://messenger.msn.com" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotReadyWrite: Sending command: "USR 2 TWN I lfwdpah@hotmail.com" kopete(16849)/kopete (msn - raw protocol) MSNSocket::slotDataReceived: "USR 2 TWN S ct=1207401203,rver=5.0.3270.0,wp=FS_40SEC_0_COMPACT,lc=1033,id=507,ru=http:%2F%2Fmessenger.msn.com,tw=0,kpp=1,kv=4,ver=2.1.6000.1,rn=1lgjBfIL,tpf=b0735e3a873dfb5e75054465196398e0 ." kopete(16849)/kopete (msn) MSNSecureLoginHandler::slotLoginServerReceived: "Keine Verbindung zu Rechner nexus.passport.com: SSL-Aushandlung fehlgeschlagen." kopete(16849)/kopete (msn) MSNAccount::slotNotifySocketClosed: kopete(16849) KopeteWindow::slotIdentityStatusIconChanged: QVariant(, ) Hope it helps a bit...
I also just compiled psi and it works fine. Also, changing the password in kopete or setting unchecking plain text passwords has no effect. I am using the svn as of today.
It connects successfully now (for me.) I am using the latest svn as of today.
David, what settings did you use to connect? I am using a fresh SVN checkout and it still does not connect for me.
Just the regular. I checked all the boxes and overrode the server to talk.google.com I still get The certificate of server gmail.com could not be validated for account dbroome@gmail.com: The host name does not match the one in the certificate. Do you want to continue? but I always got that. This is also on a fresh profile.
David, I'm not able to do it on a totally new login, with the latest SVN. Are there any other things of note you're doing? QCA versions, kdelibs, etc? I'm using everything from the latest SVN.
I do not even get the certificate dialog - just "Connecting" and then "Offline", like it has always been. This is with a clean profile and fresh SVN.
More interesting stuff: I tried to connect to a jabber.org account using SSL, and it went in right through. Is there something else we're missing while connecting to GTalk maybe?
I can connect to other Jabber server, with SSL, but Gtalk not.
Just to add as info, that with PSI 0.11, I can connect and talk with google talk. All the packages provided by Fedora 9.
In Fedora 9 I can connect to google talk service with Pidgin, Psi but not with Kopete. Other jabber servers with SSL is able to work with kopete. Strange thing...
I have the same probleme with kopete, It seems to be a problem with QCA and Qt because I had the same problem using a QSslSocket in an other project. It seems that in Psi, using wireshark, Psi sends its SSLv2 "Client hello" using that secure socket layer : "SSLv2 Record Layer: Client Hello". But Kopete sends its "Client hello" using the "SSL Record Layer: Handshake Protocol: Client Hello" secure socket layer which talk.google.com does not seem to understand as it closes the connection 20 seconds later. I attached all informations from wireshark as I don't have enough knowledge in that area to find the problem, maybe someone does know that.
Created attachment 24787 [details] Wireshark Log when kopete tries to connect to talk.google.com
Created attachment 24789 [details] Wireshark Log when psi tries to connect to talk.google.com
Your description sounds like the problem is that Kopete is trying to use the obsolete SSL version 1 protocol and Google's servers refuse using it (because it's insecure). Normally it should be negotiating the SSL version and use at least SSL version 2 (the newer TLS standard is preferred if the server supports it, but you'll get away with SSLv2).
The problem seemed to be a certificate problem, I committed a patch wich should solve the problem, please try the latest svn revision. That seems weird iris behaved like that, proposing SSL version 1 to the server. But the problem was actually on the Kopete side :)
Great job Detlev Casanova! Works fine here!
works here, too! thank you very much.
*** Bug has been marked as fixed ***.
When it'll come with the stable version?
Thanks, it works here too... :-)
*** Bug 162741 has been marked as a duplicate of this bug. ***
*** Bug 154059 has been marked as a duplicate of this bug. ***