|Summary:||Web proxy auto-discovery (WPAD) fails|
|Product:||[Fedora] Fedora||Reporter:||Travers Carter <tcarter>|
|Component:||kdelibs||Assignee:||Than Ngo <than>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||13||CC:||auxsvr, dcbw, fedora, jreznik, kevin, ltinkl, rdieter, smparrish, than|
|Target Milestone:||---||Keywords:||EasyFix, Triaged|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-06-27 16:23:46 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Travers Carter 2010-05-16 00:49:04 UTC
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): kdelibs-4.4.2-4.fc13.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure the proxy settings to automatically discover 2. Start a KDE session 3. Launch konqueror & request a web page Actual results: A notification "Could not find a usable proxy configuration script" is displayed, the web request fails. Expected results: The proxy should be discovered and used. Additional info:
Comment 1 Rex Dieter 2010-05-16 16:39:57 UTC
Thanks for the useful analysis of the problem, I'll take a look into fixing up the packaging.
Comment 2 Travers Carter 2010-05-24 08:35:26 UTC
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.
Comment 3 Travers Carter 2010-05-28 11:59:57 UTC
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: https://bugzilla.gnome.org/show_bug.cgi?id=619931 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: http://bugreports.qt.nokia.com/browse/QTBUG-10972 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.
Comment 4 Rex Dieter 2010-05-28 14:34:39 UTC
Thanks! Fwiw, the permissions of the helper was fixed in kdelibs-4.4.3-5 %changelog * Sun May 16 2010 Rex Dieter <rdieter> 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.
Comment 5 Dan Williams 2010-05-29 01:19:14 UTC
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.
Comment 6 Travers Carter 2010-05-31 06:56:39 UTC
Comment 7 Bug Zapper 2011-06-02 13:59:00 UTC
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2011-06-27 16:23:46 UTC
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.
Comment 9 Red Hat Bugzilla 2013-10-04 00:18:46 UTC
Removing external tracker bug with the id '10972' as it is not valid for this tracker