Description of problem:
KDE applications fail to discover the web proxy on my work network through WPAD auto-discovery. The network provides the configuration information via both DHCP and "wpad" DNS CNAMES. Auto-discovery works for Firefox on all platforms, KDE 3 and Internet Explorer on Windows on the same network.
I believe that there may be an actual code bug in the KDE DNS proxy discovery, but the failure of the DHCP discovery seems to be a packaging issue /usr/libexec/kde4/kpac_dhcp_helper needs to be set-uid root and it isn't the equivalent kdelibs3 binary (/usr/bin/kpac_dhcp_helper) is set-uid root.
I don't have access to the network to test today, but I have checked with wireshark that no DHCP request is made unless I "chmod u+s /usr/libexec/kde4/kpac_dhcp_helper"
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure the proxy settings to automatically discover
2. Start a KDE session
3. Launch konqueror & request a web page
A notification "Could not find a usable proxy configuration script" is displayed, the web request fails.
The proxy should be discovered and used.
Thanks for the useful analysis of the problem, I'll take a look into fixing up the packaging.
I tested this on my work network and even with /usr/libexec/kde4/kpac_dhcp_helper set-uid root proxy discovery still doesn't work.
The problem now seems to be that kpac_dhcp_helper sends a DHCPINFORM request with a client IP of 127.0.0.1, which is ignored by the DHCP server as it isn't on the DHCP subnet (I believe that this is expected behaviour for DHCP).
I had a look at the kpac_dhcp_helper code and it does a gethostname() followed by a gethostbyname() to find the address to use, but the problem is that NetworkManager inserts an entry for the system's hostname into /etc/hosts as 127.0.0.1 (I confirmed that it was NetworkManager by deleting the entry and adding an auditctl rule).
I'm not sure sure whether this is a kpac_dhcp_helper problem, or a NetworkManager problem though.
I've done some more investigation and I believe that NetworkManager is probably doing the wrong thing with /etc/hosts, I've filed an upstream bug here:
I've also tracked down why the DNS based discovery doesn't work, which is due to a bug in Qt 4's URL parsing, I've opened an upstream bug for that here:
Overall I believe the only fedora specific issue is the set-uid root permission on kpac_dhcp_helper, but without the above two bugs being dealt with proxy discovery isn't going to work for most people regardless.
Fwiw, the permissions of the helper was fixed in kdelibs-4.4.3-5
* Sun May 16 2010 Rex Dieter <email@example.com> 6:4.4.3-5
- Web proxy auto-discovery (WPAD) fails (#592658)
(which unfortunately didn't get included in our last 4.4.3 updates push)
I'll put it into our unofficial kde-redhat -testing repo, and will make sure to include it when the next batch of updates are queue'd.
Suggestion: kpac_dhcp_helper should look up the default route, get the device that the default route uses, then get that device's IP addresses. Or it could use NetworkManager via D-Bus if NM is running.
If it continues to rely on looking up the hostname it'll fail in a large number of cases where for example your hostname is 'localhost.localdomain' or 'localhost' which is the default on Fedora. So this is something NM can help out, but kpac_dhcp_helper is still being pretty simplistic about getting the IP address.
See also https://bugs.kde.org/show_bug.cgi?id=153973
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.
Removing external tracker bug with the id '10972' as it is not valid for this tracker