Since dhcpd is bound to the socket KDE's dhcp helper cannot retreive the information from the server. Reproducible: Always Steps to Reproduce: 1. Configure /etc/conf.d/net to have your dhcp supplied ifaces with dhcp configuration. 2. Configure KDE/Konqueror to try and obtain the proxy autoconfig file (.pac) URL from the server, using the wpad protocol (microsoft vendor extension). 3. Attempt to browse with Konqueror. Actual Results: After a short delay Konqueror's dhcp helper app did not find the proxy settings. Expected Results: Konqueror, as configured/built for a default gentoo distribution should have been made aware of dhcpcd and been able to work around it. The solution I came up with was this: 1. replace dhcpcd with dhclient, which is more flexible. 2. add the vendor option declaration option wpad code 252 = text; at the top level, and somewhere else, where scope applies, add request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name- servers, host-name, wpad; This will request all the default options, aswell as the URL for the pac file. An alternative would be to request all the info by default, using request; but this has it's obvious (but negligable) drawbacks. This is perhaps more desireable under a conf.d configuration style where, where extra parameters are named and saved via an easier to use interface such as ^(\d+)\s+(.+)$ as a regexp for capturing option names and adding them to the dhclient conf somehow... more on this later on 2. modify the default configuration script that comes with dhclient to have handlers for the various vendor option parameters, saving them in /var/dhcp/options/<option-names> Where <option-names> is a place holder for an autogenerated list of files, corresponding to environment variables, which have not been dealt with and are not general. This is more complex then what i've done - simply saving the wpad data to a file. Perhaps naming the additional options with a constant scheme, like prefixing dhcp_aux_opt_ to the names, and requiring these from an external configuration (conf.d?) from within /etc/ dhclient.conf, with an include statement, for various other options (dhcp_aux_opt_wpad, dhcp_aux_opt_netinfo_tag...). man dhclient-script has info on how this behaves under the BOUND section. Perhaps a gentoo- homegrown dhclient script in the spirit of how things are done is more applicable. Finally, replace konquror's helper with a simple one line "program": #!/bin/car /var/dhcp/options/<option-name> where <option-name> is the relevant string we chose to declare the option as (i chose wpad, in this example). Note that I have no installation of KDE at the moment, and thus am unable to recall the name of the konqueror dhcp helper. This solution was working on my sister's laptop till she decided a gnu/linux is still not yet as functional as the HD space it takes up... Natuarlly I hacked the /etc/init.d/net* scripts to have dhcp working properly. Good luck!
sorry for breaking the solution numbering....
Can anyone give some feedback on this one? Nothing has happened for over a year.
I'm by no means expert of this subject, but did the reporter find this file? kdelibs/kio/misc/kpac/README.wpad (http://webcvs.kde.org/kdelibs/kio/misc/kpac/README.wpad?view=markup) Does kpac_dhcp_helper fail if dhcpd is configured as shown in that file? Are you saying that dhcpcd is preventing kpac_dhcp_helper from succeeding, that is, that if you kill dhcpcd then kpac_dhcp_helper works as expected?
Hi, I'm the original reporter. I cannot confirm if the bug persists, as my only gentoo (and linux distros in general) installation is a mail server now. As for that doc from KDE - dhcpd was configured properly, but that has nothing to do with it. The problem is that dhcpcd is preventing kpac_dhcp_helper from receiving the DHCP response, because it is already bound to the port DHCP uses for traffic. If you kill dhcpcd then it does work as expected, but the solution I propsed works around that. Most dhcp clients need to stay on for various reasons. My solution replaces kpac_dhcp_helper with a mocked version, that simply reads a string from a file, while delegating the actual retrieval of the data from DHCP to a 'real' dhcp client. Unfortunately i couldn't pull it off with dhcpcd, but i did manage with dhclient, from ISC. dhclient is able to make more arbitrary use of data, and allowed me to simply take the data, as it is retrieved from DHCP, and write it to a file. Ciao!
Thanks for the clarification! Indeed it's a real issue, and apparently it was discussed by kde developers, too: http://bugs.kde.org/show_bug.cgi?id=69631#c5 IIRC in sys-apps/baselayout-1.11.x dhcpcd is not forced to users anymore, and one can choose the client he prefers. So probably Gentoo cannot do anything more about this problem... since there isn't an ad-hoc solution for each client (as you showed for dhclient), those who need this feature should use a client that does not bind to port 68, I suppose.
Apparently no DHCP clients/servers belong to a herd, and most of them have no metadata.xml at all. So there's noone in particular to CC on this. OTOH it's not a KDE issue; it can only be fixed by changes to the dhcp client daemon. Of course we can always close this as CANTFIX... Doesn't dhcpcd stay bound to port 63 on other distros, anyway?
The reason I submitted it as a KDE bug is that given modifications to a KDE client, and a flexible enough DHCP client, the situation can be worked around. The issue needs to be resolved by KDE because a tool in use by konqueror is trying to become a DHCP client when a DHCP client is already running. The question is actually how can kde get data from a DHCP server? My solution was to use a client that can serve as a sort of proxy. I have no idea what a solution with I client I don't know as well might look like. IMHO this bug can be fixed, and should not be closed as cant fix. The issue is that it's not important enough to take weird measures to fix, in the current state of linux distros' priorities. In several years, however, this issue may become more pressing, as Gentoo might progress to be a non-poweruser's OS, and things like simple configuration and tight integration of components start becoming important. Till then, I would ignore this bug.
> The reason I submitted it as a KDE bug is that given modifications to a > KDE client, and a flexible enough DHCP client, the situation can be worked > around. In your sample solution, a lot more modification to the dhcp client were needed than to the KDE side of things. That's why I say it's not really our job to orchestrate an overall solution. (Although of course we _could_ if we wanted to :-) > The issue needs to be resolved by KDE because a tool in use by konqueror is > trying to become a DHCP client when a DHCP client is already running. I'm still wondering how it works on _any_ distro when the computer has a running dhcp client. Maybe it never works in this situation, and the problem isn't Gentoo-specific. And maybe other distros have default dhcp client configs that don't keep the port open?
This appears to be resolved upstream some time ago (years). It also got changed to a wishlist item. http://bugs.kde.org/show_bug.cgi?id=69026
Me thinks Tom is right, time to close the bug.
