Bug 88766 - ICQ Plugin does not work with SOCKS
Summary: ICQ Plugin does not work with SOCKS
Status: RESOLVED DUPLICATE of bug 98018
Alias: None
Product: kopete
Classification: Applications
Component: ICQ and AIM Plugins (show other bugs)
Version: 0.9.0
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-03 13:26 UTC by S. Lorsbach
Modified: 2005-01-28 22:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. Lorsbach 2004-09-03 13:26:02 UTC
Version:           0.9.0 (using KDE KDE 3.3.0)
Installed from:    Compiled From Sources
Compiler:          gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) 
OS:                Linux

Hi,

when I try to connect via socks (Dante), kopetes ICQ plugin doesn't try to connect (I can not see any connection-attempts in my logfiles of socks).
So I have done a netstat and see that it makes a normal connect to oscarserver:5190 and not to the socksserver:1080.

I tested the IRC-Plugin - it works with socks and Konqueror works with socks too.
The ICQ Plugin in Kopete Version 0.8.3 @ KDE3.2 works perfectly with socks.
Comment 1 Mindaugas 2004-11-10 16:10:15 UTC
Hi,

I have same problem:

Version:           0.9.1 (using KDE KDE 3.3.1) 
Installed from:    RPM
OS:   Suse linux 9.1 

I tested Yahoo and IRC plugins it works fine, but ICQ  doesn't try to connect, I see  in Xterm window only requested connections.

Best regards,

Mindaugas 

Comment 2 Thiago Macieira 2005-01-27 23:31:25 UTC

*** This bug has been marked as a duplicate of 98018 ***
Comment 3 Jason 'vanRijn' Kasper 2005-01-28 14:20:02 UTC
I have found that the way dante is configured causes this to happen.  The bug that I raised (98018) is a secondary bug in this issue.  The first problem (this one) is that if dante is not configured exactly how KDE expects it to be, KDE does not even try to use dante.  I cannot explain why this happens, but I can show you how to reproduce it.

If, in your /etc/dante.conf or /etc/socks.conf (the norm), you have this:

resolveprotocol: fake

then KDE won't even try to use dante.  If you leave it as the default of udp or change it to tcp, then KDE will attempt to use dante, and in my experience, things like konqueror will actually use it and work correctly.  Kopete has the problem in that it will try to use it and will not be able to, which is what bug 98018 is about.

There are other settings that I have found that if I put into /etc/socks.conf, KDE will not use dante, even though it will if I remove that one small thing.  One that comes to mind is "command: bind"--if I added that to a route {} paragraph, then KDE wouldn't try to use dante.  I know there are others too, but can't recall them at the moment.

At the end of the day, it would sure be a WHOLE lot nicer if KDE was able to talk directly to a SOCKS proxy server, like gaim and firefox and other programs can do, instead of relying on configuring a SOCKS client like Dante on the machine.  It's a whole lot easier to enter SOCKS server and port information (as in firefox, gaim, etc.), than it is to spend 5 days trying to debug what layer things are breaking in (as I have just painfully done).

I think it would also be helpful if you guys posted your socks.conf files to this bug so we can see if there are any such settings that are keeping KDE from working with dante.

Also, bug-guys...  I'm not sure that this bug should be marked as resolved.  It's not a duplicate of 98018.  98018 is the bug that when Kopete tries to use dante, it doesn't succeed.  This bug is that because of a configuration issue in the SOCKS handling of KDE, Kopete doesn't EVEN TRY to use socks.  And I don't think it's a wishlist--this is a legitimate bug, IMHO.
Comment 4 Thiago Macieira 2005-01-28 22:22:59 UTC
Since it'll be the same person (me) to solve both problems, I don't see why separating the bugs should be an issue.

I plan to have our own implementation of the SOCKS protocol in the future. Some day...