Summary: | [regression] Kopete unable to connect using dante SOCKS proxy with KNetwork based scoket implementation | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Jason 'vanRijn' Kasper <vR> |
Component: | general | Assignee: | Thiago Macieira <thiago> |
Status: | RESOLVED FIXED | ||
Severity: | grave | CC: | florian-evers, kde, kopete-bugs-null, m.a.ellis, tiggernews |
Priority: | VHI | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Jason 'vanRijn' Kasper
2005-01-27 20:38:00 UTC
This seems to be a regression the functionality of the KNetwork classes vs. KExtendedSocket. Protocols that use KNetwork classes won't connect via proxy. Protocols that use KExtendedSocket should work via proxy. (except IRC, but that's another problem, i'm sure) I'm hoping some of this helps... After talking with mattr in #kopete, I've discovered that the ONLY kopete account that I can log into via the SOCKS proxy is a yahoo account. In addition, I've just used gaim to connect via the SOCKS proxy and it worked fine, using a SOCKS4 setting, and this is what I see from ssh's debug.... debug1: channel 4: free: direct-tcpip: listening port 11080 for 207.46.106.142 port 1863, connect from 127.0.0.1 port 37432, nchannels 5 debug1: Connection to port 11080 forwarding to socks port 0 requested. debug1: channel 1: new [dynamic-tcpip] debug1: Connection to port 11080 forwarding to socks port 0 requested. debug1: channel 4: new [dynamic-tcpip] debug1: channel 1: free: direct-tcpip: listening port 11080 for 207.46.104.20 port 1863, connect from 127.0.0.1 port 37436, nchannels 6 debug1: Connection to port 11080 forwarding to socks port 0 requested. debug1: channel 1: new [dynamic-tcpip] debug1: Connection to port 11080 forwarding to socks port 0 requested. debug1: channel 6: new [dynamic-tcpip] debug1: channel 1: free: direct-tcpip: listening port 11080 for 65.54.179.228 port 443, connect from 127.0.0.1 port 37438, nchannels 7 debug1: Connection to port 11080 forwarding to socks port 0 requested. debug1: channel 1: new [dynamic-tcpip] debug1: channel 6: free: direct-tcpip: listening port 11080 for 65.54.179.192 port 443, connect from 127.0.0.1 port 37439, nchannels 7 debug1: channel 1: free: direct-tcpip: listening port 11080 for 65.54.179.198 port 443, connect from 127.0.0.1 port 37441, nchannels 6 Hope this helps you guys fix this!! =:) *** Bug 88766 has been marked as a duplicate of this bug. *** We got report of same problem in Konversation. Looks like a KNetwork problem. Thiago is there a chance of fixing this before 3.4? I hope to! Unfortunately, I have no working SOCKS proxy, no SOCKS client libraries installed and it's been three years since I've looked at SOCKS code. For KDE4, I hope to get rid of KSocks dependency on SOCKS client libraries and, instead, write our own SOCKS client code, much as has been done for the HTTP proxy support. Thiago - if you want a SOCKS proxy to test this on, I am sure I can run one for you on my PC here (it is up 24/7). Ping me in private mail if you want me to set one up. I was just going to add... The easiest way to do this is to simply install the dante client libraries (rpms are pretty readily available, iirc) and run the SSH command that I have shown above. SSH can act as a SOCKS4/5 proxy, which means that you don't actually have to set up a SOCKS server--all you have to do is have an SSH tunnel and that will be your SOCKS4/5 proxy server too (ssh -D). Please forgive if this is stating the obvious. =:) Raising severity even more. Sorry, debugging indicates nothing wrong in KDE code. So far, I'm leaning on libdsocks bug. I'll continue investigating. Indeed it's a bug in Dante, but it's one we already had workarounds for. CVS commit by thiago: Adding workaround for the Dante bug with asynchronous connection. This will make a *synchronous* connection every time Dante is used. So, too bad if you're using Dante, your KDE application will freeze its UI whenever a socket connects. For KDE4, I plan to write the SOCKS protocol myself and avoid this kind of problems. To be backported. BUG:98018 M +17 -1 ksockssocketdevice.cpp 1.7 --- kdelibs/kdecore/network/ksockssocketdevice.cpp #1.6:1.7 @@ -119,5 +119,21 @@ bool KSocksSocketDevice::connect(const K return false; // failed creating! - if (KSocks::self()->connect(m_sockfd, address.address(), address.length()) == -1) + int retval; + if (KSocks::self()->hasWorkingAsyncConnect()) + retval = KSocks::self()->connect(m_sockfd, address.address(), + address.length()); + else + { + // work around some SOCKS implementation bugs + // we will do a *synchronous* connection here! + // FIXME: KDE4, write a proper SOCKS implementation + bool isBlocking = blocking(); + setBlocking(true); + retval = KSocks::self()->connect(m_sockfd, address.address(), + address.length()); + setBlocking(isBlocking); + } + + if (retval == -1) { if (errno == EISCONN) Hi Thiago, Thanks so much for looking into this. > Adding workaround for the Dante bug with asynchronous connection. Cool. All working for me in Kopete and Konversation. :o) Have you reported upstream? > This will make a *synchronous* connection every time Dante is used. No big deal, I didn't notice any difference from a normal connect. Thanks again, Martin I'm not really sure. It was Waldo Bastian who first found the bug, not me. I'm not sure if he reported it upstream. CVS commit by thiago: (Backport 1.6:1.7) Backporting the fix to KDE 3.4.x. Sorry, this didn't make into 3.4.0. CCBUG:98018 M +17 -1 ksockssocketdevice.cpp 1.6.2.1 --- kdelibs/kdecore/network/ksockssocketdevice.cpp #1.6:1.6.2.1 @@ -119,5 +119,21 @@ bool KSocksSocketDevice::connect(const K return false; // failed creating! - if (KSocks::self()->connect(m_sockfd, address.address(), address.length()) == -1) + int retval; + if (KSocks::self()->hasWorkingAsyncConnect()) + retval = KSocks::self()->connect(m_sockfd, address.address(), + address.length()); + else + { + // work around some SOCKS implementation bugs + // we will do a *synchronous* connection here! + // FIXME: KDE4, write a proper SOCKS implementation + bool isBlocking = blocking(); + setBlocking(true); + retval = KSocks::self()->connect(m_sockfd, address.address(), + address.length()); + setBlocking(isBlocking); + } + + if (retval == -1) { if (errno == EISCONN) *** Bug 88215 has been marked as a duplicate of this bug. *** |