Bug 47960 - gabble not using system defined proxy
Summary: gabble not using system defined proxy
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-27 12:39 UTC by Ken VanDine
Modified: 2012-04-24 08:06 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
WOCKY_DEBUG=xmpp with contact info stripped out (12.02 KB, text/x-log)
2012-03-27 12:39 UTC, Ken VanDine
Details
All-24-04-12_11-03-19.log (144.44 KB, text/plain)
2012-04-24 08:06 UTC, Ken VanDine
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ken VanDine 2012-03-27 12:39:23 UTC
Created attachment 59127 [details]
WOCKY_DEBUG=xmpp with contact info stripped out

In my test scenario, I have a local squid proxy properly configured to handle HTTP CONNECT, tested with pidgin and it works.  MS Live accounts works as well using telepathy-haze.  However attempting to connect to gtalk or jabber.org accounts, according to the squid access log, never attempts to connect to the configured proxy.


Downstream bug report: https://bugs.launchpad.net/ubuntu/precise/+source/telepathy-gabble/+bug/893031
Comment 1 Nicolas Dufresne 2012-03-28 08:01:24 UTC
Can you provide your system configuration, and the returned configuration as seen by libproxy:

proxy xmpp-client://myserfer
proxy https://myserfer

HTTP Connect for bare jabber is currently not supported by libproxy (not support fro any non https:// protocols). Also, be aware that Pidgin erroneously reads the HTTP_PROXY rather then SECURE_PROXY gnome setting for doing HTTP Connect.
Comment 2 Ken VanDine 2012-03-28 11:59:38 UTC
proxy xmpp-client://myserfer
direct://
proxy https://myserfer
http://localhost:3128

Looking through the gabble source, I don't see anywhere that it uses libproxy, not even an includes for proxy.h.  How does it interact with libproxy?

Previously it had been suggested that it wasn't working because our version of libproxy in Ubuntu was too old, 0.3.x.  We now have the 0.4.7, the latest and it still doesn't work.

So this isn't a bug so much as it is not supported yet?
Comment 3 Nicolas Dufresne 2012-03-28 12:30:14 UTC
(In reply to comment #2)
> proxy xmpp-client://myserfer
> direct://
> proxy https://myserfer
> http://localhost:3128
> 
> Looking through the gabble source, I don't see anywhere that it uses libproxy,
> not even an includes for proxy.h.  How does it interact with libproxy?
> 
> Previously it had been suggested that it wasn't working because our version of
> libproxy in Ubuntu was too old, 0.3.x.  We now have the 0.4.7, the latest and
> it still doesn't work.
> 
> So this isn't a bug so much as it is not supported yet?

Gabble uses a library called Wocky which is base on GIO. And GIO has a libproxy and gnome plugin. I usually suggest using libproxy for distro that can run both KDE and Gnome on the same install, the Gnome plugin ignores the environment.

Currently the support for HTTP Connect is very restricted because the GIO developers did not agree it was a correct way of doing generic socket proxying. Here is how you can make it work. First thing to know is that wocky will do HTTP Connect only when you are running in Old SSL mode. Which mean the first thing you do is an TLS handshake (so it cannot be differentiated from a HTTPS connection). Then you need a correct configuration, which you have.

If you are using a google account configured with older version of Empathy, I suggest to remove it and re-create it. This will add the fallback-servers parameter to your account. Note that HTTP Connect is never the first, so connection may take a little while depending on how fat the other attempts fails. You can check the params using mc-tool show ... Here's what you should see:
(GStrv) fallback-servers = ["talkx.l.google.com", "talkx.l.google.com:443,oldssl", "talkx.l.google.com:80"]

Unless someone broke the fallbacks, wocky will try the server talk.google.com (use to do SRV, but was changed recently). In case of failure, it will fallback to talkx.l.google.com using normal TLS, if it fails again, it will try talkx.l.google.com:443 using OLD SSL mode, and if that still fails it will try cleartext on port 80 (I think this one always fails these days, not sure).

In the future, libproxy should try HTTP Connect for any type of connection, and have a direct fallback, but that couldn't be done without changing libproxy internals a lot. Also, the HTTP Connect GLIB plugin should be provided by libsoup. Feel free to contribute if you have time.
Comment 4 Ken VanDine 2012-03-28 12:42:19 UTC
My account does have the fallback-servers set with oldssl, but does this mean that if it can connect without going through the configured proxy it will do that? 

I am not actually required to use the proxy to connect, but set it up just for testing this bug.  If it just ignores the proxy setting because it can connect without it, my test environment isn't really good for validating this bug.
Comment 5 Nicolas Dufresne 2012-03-28 12:50:52 UTC
(In reply to comment #4)
> My account does have the fallback-servers set with oldssl, but does this mean
> that if it can connect without going through the configured proxy it will do
> that? 

With the current implementation, yes.

> 
> I am not actually required to use the proxy to connect, but set it up just for
> testing this bug.  If it just ignores the proxy setting because it can connect
> without it, my test environment isn't really good for validating this bug.

Right, to test it, you need to isolate yourself from the internet. Maybe you can try by disable dns (comment the nameserver lines in resolve.conf) and set your proxy server dns (if you have one) in /etc/hosts. If the proxy is on the same host, well at least you will see the proxy being called even if it fails in the end.
Comment 6 Nicolas Dufresne 2012-04-03 15:21:40 UTC
Should I conclude this bug was invalid ?
Comment 7 Ken VanDine 2012-04-24 08:06:11 UTC
Created attachment 60534 [details]
All-24-04-12_11-03-19.log

I tried that, with no nameserver set.  Other apps work fine through the proxy, firefox, ubuntuone, etc.  But when connecting with empathy it still doesn't even try to hit the proxy.  I am attaching the log.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.