Anonymous | Login | 2024-11-21 03:37 MST |
Main | My View | View Issues | Change Log | Roadmap | Repositories |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0019481 | ClearOS | app-wpad | public | 2018-03-27 05:17 | 2018-03-29 10:49 | ||||
Reporter | NickH | ||||||||
Assigned To | |||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | open | ||||||
Platform | OS | OS Version | |||||||
Product Version | 7.4.0 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0019481: When the WPAD DNS setting is updated, the hosts file is written to but dnsmasq is not restarted; other hosts issue | ||||||||
Description | In the WPAD app, if the DNS setting is enabled, the hosts file is added to but dnsmasq is not restarted so the changes don't take effect. The same thing happens if you disable the setting. BTW I am concerned at the effect of this setting as it sets the FQDN to resolve to each interface IP address in the hosts file, but in reality it only returns the the first one listed e.g. it is generating a hosts file for me: 172.17.2.5 wpad.test-7x.howitts.test 172.22.22.1 wpad.test-7x.howitts.test 172.17.222.1 wpad.test-7x.howitts.test from a LAN machine 172.22.22.x, "nslookup wpad.test-7x.howitts.test" returns 172.17.2.5 but that is the WAN interface. If 172.17.2.5 were a HotLAN no communication to it from the LAN would be allowed and the WPAD process would fail. In order for this to work correctly, you also need the "localise-queries" parameter in dnsmasq.conf (or run separate instances of dnsmasq per interface and use host-record= entries in each interface configuration - yuck). | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0007271) NickH (developer) 2018-03-29 03:00 |
Sleepless night here and eureka moment. I've just realised that the record written to the hosts file is incorrect for the DNS method but is necessary for the way the DHCP method has been implemented. For the DNS method, the record should be for wpad.howitts.test and not wpad.test-7x.howitts.test, i.e. should be for wpad.domain.com and not wpad.server.domain.com. Unfortunately this still breaks the WPAD server which seems to be looking specifically for http://wpad.test-7x.howitts.test/wpad.dat [^] and serving it out of /var/clearos/wpad/wpad.dat. If you create a symlink /var/www/html/wpad.dat pointing to /var/clearos/wpad/wpad.dat then the DNS method works. Again, just documenting for posterity. |
(0007331) bchambers (administrator) 2018-03-29 10:48 |
Won't fix for now...see tracker 19581 |