http://bugs.meego.com/show_bug.cgi?id=11366 Summary: libsoup overrides http_proxy with invalid string: breaks SyncEvolution Classification: MeeGo Platform Product: OS Middleware Version: 1.2 Platform: All Architecture: --- Status: NEW Severity: normal Priority: Undecided Component: SyncEvolution AssignedTo: patrick.ohly(a)intel.com ReportedBy: han.dai(a)intel.com QAContact: jingke.zhang(a)intel.com CC: syncevolution-bugs(a)meego.bugs, dwmw2(a)linux.intel.com Blocks: 10015 Estimated Hours: 0.0 Syncevolution doesn't use libproxy to find current proxy information as provided by ConnMan; it seems to be looking at the static settings in gconf. And even when those are *correct*, it's broken -- it seems to connect to port *zero* of the host which GConf tells it is serving the proxy PAC script. --- Comment #1 from dwmw2intel <dwmw2(a)linux.intel.com&gt; 2010-11-13 14:08:53 PST --- Hm, it is using the proxy resolver from libsoup-gnome, which would have worked. But then it's *overriding* the proxy with the string 'pac+http://autoproxy.intel.com/'. Soup doesn't recognise 'pac+http' as a URL scheme, and that's probably what leads to the attempt to contact port 0. I can't quite work out where it's pulling that bogus override string from. This is also happening in MeeGo 1.1. --- Comment #2 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-14 11:58:31 PST --- (In reply to comment #1) Is it perhaps somewhere in your SyncEvolution config (proxyHost) or environment (http_proxy). Those override the automatism in libsoup, if set (which normally they shouldn't be in MeeGo). I cannot think of any other reason why SyncEvolution should set the proxy information. --- Comment #3 from dwmw2intel <dwmw2(a)linux.intel.com&gt; 2010-11-14 13:17:59 PST --- Something seems to be automatically setting this. It certainly wasn't me -- this is a clean install of the current MeeGo IT Build. --- Comment #4 from dwmw2intel <dwmw2(a)linux.intel.com&gt; 2010-11-14 13:18:23 PST --- I don't know where to find the syncevolution configuration files to check... --- Comment #5 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-14 23:17:16 PST --- (In reply to comment #4) "syncevolution --print-configs" gives a list of configurations and their location on disk, "syncevolution --print-config -q <config name>" summarizes all relevant options for a config (takes properties from multiple files). --- Comment #6 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-20 16:41:46 PST --- [dwoodhou@dwoodhou-mobl4 ~]$ syncevolution --print-config google | grep proxy # set to T to choose an HTTP proxy explicitly; otherwise the default # proxy settings of the underlying HTTP transport mechanism are used; # proxy URL (http://<host>:<port>) # proxyHost = # authentication for proxy: username # proxyUsername = # proxy password, can be specified in different ways, # proxyPassword = # per-peer (unshared) properties: syncURL, username, password, loglevel, printChanges, autoSync, autoSyncInterval, autoSyncDelay, preventSlowSync, useProxy, proxyHost, proxyUsername, proxyPassword, clientAuthType, RetryDuration, RetryInterval, remoteIdentifier, PeerIsClient, SyncMLVersion, PeerName, remoteDeviceId, enableWBXML, maxMsgSize, maxObjSize, enableCompression, SSLServerCertificates, SSLVerifyServer, SSLVerifyHost, WebURL, IconURI, ConsumerReady --- Comment #7 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-21 05:39:19 PST --- Is the "http_proxy" env variable set in the environment of the SyncEvolution process? --- Comment #8 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-21 12:16:32 PST --- No. This should be easy to reproduce with the image from http://opensource.intel.com/linux-wiki/MeeGoITBuild --- Comment #9 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-22 01:24:59 PST --- (In reply to comment #8) I tried to reproduce it, but half-way through the install process realized that it would probably only occur when inside Intel. At home, I cannot even set up the Intel specific part of that image - at least not easily. I know about the tricks with routing traffic through a connected machine, but that's too involved for now. I'll be in the Ulm site tomorrow and will try again there. --- Comment #10 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-22 03:08:14 PST --- You don't have to route through a connected machine. Just use 'openconnect --cookieonly' to get a VPN cookie on another machine, then use connman's connect-vpn script to *connect* using that cookie from your test box. Note that you have to transfer ~/.cert/intel-certchain.crt from your existing machine to the MeeGo box, so that openconnect can validate the server's SSL certificate. Then: /usr/lib/connman/test/connect-vpn openconnect "my VPN" $SERVERIP intel.com $COOKIE /where/you/put/intel-certchain.crt You can ssh into the machine as root using the password 'meego' while it's sitting at the firstboot screen. There's no way to make it tell you its IP addresses from the UI, so watch for it doing mDNS or note its IP address before you reinstall it (for IPv6 at least it should have a constant address; for Legacy IP there are a lot of buggy DHCP servers out there which will move it around). --- Comment #11 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-24 03:38:26 PST --- I found that getenv("http_proxy") returns the "pac+http://autoproxy.intel.com" string. But is indeed not in the environment. That leaves a setenv() call at runtime, and indeed, here it is: Breakpoint 1, __setenv (name=0x4285a353 "http_proxy", value=0x82d56a8 "pac+http://autoproxy.intel.com/", replace=1) at setenv.c:268 268 if (name == NULL || *name == '\0' || strchr (name, '=') != NULL) (gdb) where #0 __setenv (name=0x4285a353 "http_proxy", value=0x82d56a8 "pac+http://autoproxy.intel.com/", replace=1) at setenv.c:268 #1 0x417e0b52 in g_setenv () from /lib/libglib-2.0.so.0 #2 0x4285913a in ?? () from /usr/lib/libsoup-gnome-2.4.so.1 #3 0x428595d4 in ?? () from /usr/lib/libsoup-gnome-2.4.so.1 #4 0x4285975c in ?? () from /usr/lib/libsoup-gnome-2.4.so.1 #5 0x41880be4 in g_type_create_instance () from /lib/libgobject-2.0.so.0 #6 0x41879047 in ?? () from /lib/libgobject-2.0.so.0 #7 0x4187954c in g_object_newv () from /lib/libgobject-2.0.so.0 #8 0x41879714 in g_object_new () from /lib/libgobject-2.0.so.0 #9 0x42cca3bd in soup_session_add_feature_by_type () from /usr/lib/libsoup-2.4.so.1 #10 0x42f9f543 in SyncEvo::SoupTransportAgent::SoupTransportAgent (this=<value optimized out>, loop=<value optimized out>) at SoupTransportAgent.cpp:48 SyncEvolution then picks up that value and passes it to libsoup again. Note that I wasn't even connected to the Intel intranet while doing the run above. Therefore the sync failed with: [INFO] SoupTransport Failure: https://m.google.com/syncml via libsoup: Cannot resolve proxy hostname I don't know why libsoup does that. /system/proxy/autoconfig_url is set to http://autoproxy.intel.com, but /system/http_proxy/use_http_proxy is off. Any suggestions how this should be fixed? Move the http_proxy check in SyncEvolution to a point before libsoup has a chance to mess with the environment? That feels like working around the issue instead of fixing it, because other apps invoked indirectly will still inherit the wrong environment. --- Comment #12 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-24 03:46:34 PST --- Somehow I get the same "cannot connect to proxy host" even while VPN is up. There's no telnet installed (or available?!), but Chrome has no problem accessing http:://autoproxy.intel.com. Is it the pac+http scheme which is causing that problem? --- Comment #13 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-24 03:48:11 PST --- Yeah, pac+http:// is complete nonsense. --- Comment #14 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-24 03:53:13 PST --- I'm confused. libsoup-gnome should only be doing this crappy setenv thing if it's using a *really* old version of libproxy: AC_MSG_CHECKING(libproxy version) libproxy_version=`$PKG_CONFIG --modversion libproxy-1.0` case $libproxy_version in 0.2.*) AC_MSG_RESULT([$libproxy_version, using workarounds...]) AC_DEFINE(HAVE_LIBPROXY_WITH_NON_THREAD_SAFE_GNOME_MODULE, 1, [Defined if libproxy is old and has a non-thread-safe gnome module]) /* If we have a "bad" libproxy, set environment variables * and force it to use them. */ #ifdef HAVE_LIBPROXY_WITH_NON_THREAD_SAFE_GNOME_MODULE g_setenv ("PX_CONFIG_ORDER", "envvar", TRUE); if (http_proxy) g_setenv ("http_proxy", http_proxy, TRUE); We have never had libproxy 0.2 in MeeGo, although now we're using PacRunner it may advertise itself as 0.1. --- Comment #15 from pohly <patrick.ohly(a)intel.com&gt; 2010-11-24 03:53:45 PST --- (In reply to comment #0) That answers my previous question about "cannot connect to proxy host". It seems that pac+http leads to "let's try port 0". Setting port 80 in the autoconfig_url gets me beyond that, but then it fails with: [INFO] SoupTransport Failure: https://m.google.com/syncml via libsoup: Connection terminated unexpectedly I have not done any network dumps to investigate that further. --- Comment #16 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-24 04:03:53 PST --- https://bugzilla.gnome.org/show_bug.cgi?id=603285 Fixed in libsoup commit 25bfd5cbcfb93b94efc7c0f6f0d4bbfa51244e42 Although ideally we should just drop libproxy completely and talk D-Bus directly to pacrunner. --- Comment #17 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-24 04:21:36 PST --- Thanks for the diagnosis. A fixed package should now be available in the devel:enterprise repository at http://download.meego.com/live/devel:/enterprise/MeeGo_1.1_Netbook/ --- Comment #18 from dwmw2 <dwmw2(a)infradead.org&gt; 2010-11-24 04:27:58 PST --- Yan, this probably wants to get into the 1.0 build for Fab28 too. --- Comment #19 from dwmw2intel <dwmw2(a)linux.intel.com&gt; 2010-12-03 10:00:29 PST --- I've pushed the fix into devel:enterprise:1.0 for Fab 28 too. --- Comment #20 from daihan <han.dai(a)intel.com&gt; 2010-12-14 17:55:46 PST --- submitted the patch in devel:enterprise/libsoup to MeeGo:1.1:Core:Update:Testing request id 10924 --- Comment #21 from dwmw2intel <dwmw2(a)linux.intel.com&gt; 2010-12-15 07:47:51 PST --- Submitted to Trunk too, but it was pointlessly rejected. Apparently we need a *separate* bug filed against Trunk, and the changelog there must reference *that* bug, so the Trunk and 1.1 packages would be gratuitously different despite having exactly the same code. Clever. Really, this is not the way to build a community and encourage people to contribute. --- Comment #22 from daihan <han.dai(a)intel.com&gt; 2010-12-15 18:32:16 PST --- +++ This bug was initially created as a clone of Bug #10015 +++ -- Configure bugmail: http://bugs.meego.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug.