Bug 998 - (int-128216) Application Installer attempts to use disabled proxy
: Application Installer attempts to use disabled proxy
Product: Settings and Maintenance
Application manager
: 5.0-beta2
: All Maemo
: Medium normal with 1 vote (vote)
: 5.0 (1.2009.41-10)
Assigned To: unassigned
: application-manager-bugs
: https://vtunnel.com
: 3783
  Show dependency tree
Reported: 2007-01-30 19:25 UTC by Paul Klapperich
Modified: 2010-03-08 02:57 UTC (History)
6 users (show)

See Also:

Please remove, not applicable due to my mistake (9.13 KB, application/x-gzip)
2008-02-02 06:11 UTC, Larry Battraw


You need to log in before you can comment on or make changes to this bug.

Description Paul Klapperich (reporter) 2007-01-30 19:25:55 UTC
If a latent proxy configuration exists, the Application Installer will attempt
to use it /even though it's disabled/ when performing "Refresh application
list." Other applications ignore the disabled proxy, as expected.

This has been tested repeatedly on OS 2007 v 2.2006.51-6

Steps to Reproduce:
1) Disconnect from current access point and setup any http:// and https:// proxy
2) Reconnect.
3) Open Application Manager and attempt to "Refresh application list." If the
proxy settings were valid this will be successful. If not, failure with an error
in logs similar to:
"osso-application-installer 4.42, UI version 2
E: Failed to fetch
http://catalogue.tableteer.nokia.com/certified/dists/bora/Release.gpg  Could not
connect to ( - connect (111 Co$"
So far, this is as to be expected.
4) Close the Application Manager. 
5) Disconnect from the access point and uncheck the "Enabled" box in the proxy
settings. Notice the proxy information is retained but is greyed out.
6) Repeat step 3. This will fail with the same error as before, even though the
proxy should not be used.
7) Open "Browser" and verify the connection is valid.

At this point, "apt-get update" from XTerm will allow the list to be updated.
After updating with "apt-get update" applications may be installed from
Application Manager. This only seems to be affecting refreshing the list.

The simplest solution to this is to delete the offending connection and then
reconnect to it. This will cause the proxy tab to be completely blank, the
default state. Application manager will resume working normally.

Possible Reason:
I found that by manually editing
that this can be fixed without deleting the connection. This is detailed in the
following forum post:
It seems that the application manager reads this file when refreshing, but
ignores the "proxytype" field set to "NONE."
Comment 1 Laurent GUERBY 2007-03-23 22:51:01 UTC
I've just been beaten by this problem and it took me two good hours to sort out
why app manager was not working and I ended up reinventing your workaround
(delete connection and recreate it).

It was with latest 2007.10 OS, steps to reproduce:

1. disconnect
2. add a unexisting proxy to your connection setting (host=toto, port=1 for
http) with connection manager
3. connect
4. check web => doesnt work as planned, error about proxy
5. disconnect
6. uncheck the proxy in your connection setting
7. reconnect
8. check web => it works as planned
9. try app manager tools refresh => you get an error pop up => BAD
10. look app manager tools log, you see it's using still using "toto" host
11. type in xterm:
$ gconftool-2 -R /system/http_proxy
 use_http_proxy = true
 use_authentication = false
 host = toto
 ignore_hosts = []
 authentication_user = 
 authentication_password = 
 port = 1

I assume the connection manager check "use_http_proxy" and it's still true.

To fix I assume either change the connection manager behaviour to clean
use_http_proxy in case the proxy checkbox is unchecked, or change the
application manager to read proxy settings like the web browser (or both :).
Comment 2 Jonathan Matthews-Levine 2007-04-04 01:04:30 UTC
Confirmed on OS2007 2.2006.51-6.

However, there's no need to delete the connection to get the Application Manager
working again.

Just edit the connection in Connection Manager and in the "advanced" section:
o tick the proxy-enable box
o delete the proxy IP
o set the port to 0
o untick the proxy-enable box

Those steps worked immediately here.  No need to recreate the connection at all.
Comment 3 Larry Battraw 2008-02-02 06:11:36 UTC
Created an attachment (id=710) [details]
Copy of gconf dump and current prefs.js
Comment 4 Larry Battraw 2008-02-02 06:12:58 UTC
This bug is still present in the latest release of the OS
(RX-34_2008SE_2.2007.50-2).  I noticed it because a connection that uses a
proxy "contaminated" the other connection I had defined.  The proxy settings
for the proxy-using connection will always be written to prefs.js, regardless
of which connection is chosen.  Using gconftool to dump the connection settings
show the correct values; the connection manager does so as well.  I've attached
the complete gconftool dump for the device as well as a copy of the resulting
prefs.js.  The solutions given earlier do nothing because the problem is not
that the proxy values are incorrect (excluding microb prefs.js), but that the
wrong connection settings are being written to prefs.js.
Comment 5 Larry Battraw 2008-02-14 01:44:59 UTC
Withdrawing my vote for the bug-- my mistake!  I set the http_proxy environment
variable in the ~user/.profile.  With that gone everything works perfectly,
sorry for the confusion.
Comment 6 Andre Klapper maemo.org 2008-10-08 18:01:14 UTC
*** Bug 3110 has been marked as a duplicate of this bug. ***
Comment 7 Matt Johnston 2008-10-20 05:59:14 UTC
Confirming that this bug is still present in 4.2008.36-5
Comment 8 Andre Klapper maemo.org 2008-10-20 11:18:58 UTC
Matt: Does Larry's workaround (comment 5) work for you?
Comment 9 Matt Johnston 2008-10-20 11:34:22 UTC
I don't have http_proxy set in my ~/.profile. Leaving the port set to non-zero
doesn't seem to be a problem, it's only the proxy hostname that App Manager
seems to be looking at.

App manager needs to be restarted to get it to notice changes in the server
name field.
Comment 10 Patrik Flykt nokia 2008-11-06 11:27:31 UTC
(In reply to comment #7)
> Confirming that this bug is still present in 4.2008.36-5

Can you give the scripts /etc/network/if-up/00_proxy_set and
/etc/network/if-post-down.d/zz_proxy_unset a look and figure out what might be
Comment 11 Matt Johnston 2008-11-06 14:34:13 UTC
(In reply to comment #10)
> Can you give the scripts /etc/network/if-up/00_proxy_set and
> /etc/network/if-post-down.d/zz_proxy_unset a look and figure out what might be
> wrong?

In proxy_set, it does:

set_use         `read_proxy proxy_http`                              

set_use() does:

        if test x$1 = x                                         
                gconf_unset="$gconf_unset -u $key"             
                gconftool-2 -s $key -t bool TRUE         

It shouldn't be testing http_proxy (that's the proxy host itself), I think it
should be looking at the osso "proxytype" key instead?

Offtopic, testing this stuff reminds me how bad the network connection UI is
Comment 12 Quim Gil nokia 2009-05-18 23:03:07 UTC
Andre, it would be good to check this with the testers of the Fremantle AM. The
code of the application hasn't changed much from Diablo, so if there was a bug
there I wouldn't be surprised if it still exists.
Comment 13 Andre Klapper maemo.org 2009-07-14 16:03:24 UTC
DIABLO 5.2008.43-7:
1. Set up some fake proxy in Connection Settings > Advanced
2. In Terminal, run "gconftool-2 --get /system/proxy/mode". Get "manual".
3. Go to Connection Settings > Advanced
4. Disable "Use proxy"
5. In Terminal, run "gconftool-2 --get /system/proxy/mode". Still get "manual".

Current Fremantle:
1. Set up some fake proxy in Connection Settings > Advanced
2. In Terminal, run "gconftool-2 --get /system/proxy/mode". Get "manual".
3. Go to Connection Settings > Advanced
4. Disable "Use proxy"
5. In Terminal, run "gconftool-2 --get /system/proxy/mode". Get "none".
Comment 14 Andre Klapper maemo.org 2009-07-14 16:35:14 UTC
Still happening in latest Fremantle.
As the gconf key now gets updated correctly (compared to Diablo; see my last
comment) I consider this to be an application issue.

   "Application list partially refreshed.
    Some catalogues unavailable.
    Check catalogue details."
Click "Details" and click "Fremantle", result:
    Could not resolve 'example.foo'"

Ignore the *disabled* proxy and work correctly.
Comment 15 Andre Klapper maemo.org 2009-07-29 18:52:09 UTC
This issue has been FIXED in the internal Fremantle version.

Unfortunately this is a WONTFIX for Diablo as Diablo is in maintenance mode and
Nokia will only provide bugfixes for critical issues if at all.
For your interest the Mer project aims to provide a community backport of
Fremantle for N8x0 devices. See http://wiki.maemo.org/Mer for more information.
Comment 16 Lucas Maneos 2009-10-18 03:38:56 UTC
Verified in 1.2009.41-10 :-)