It has been a long while since this discussion, but would anyone be interested in testing changes I made to kpac_dhcp_helper.c ?? I now have a version that uses getifaddrs instead of gethostname()+gethostbyname().
On Sat, Jun 5, 2010 at 11:54 AM, Dawit A <[email protected]> wrote: > On Thursday, June 03, 2010 21:11:49 Travers Carter wrote: > >> On Thu, 3 Jun 2010 07:12:43 Dawit A wrote: > >> > It never was at least not in a portable way and that is probably why >> > even > >> > Firefox does not support the DHCP based approach for WPAD. At least it > >> > did not before, no idea if that has changed recently.[1] > >> > >> I believe that is still the case, as far as I can find Firefox simply >> makes > >> a single request for http://wpad/wapd.dat and relies on the resolver to > >> append the appropriate domain. DHCP Discovery has been requested but not > >> implemented - https://bugzilla.mozilla.org/show_bug.cgi?id=356831 > >> > >> > That would assume that NetworkManager is used everywhere you want to do > >> > this. That will not be the case. For example, it won't work on my >> > machine > >> > as I do not use NetworkManager. > >> > >> Sure, that's why I was thinking routing lookup. > >> > >> > Personally, the DHCPINFORM look-up approach should be completely > >> > abandoned as an option for doing WPAD just almost all other major > >> > browsers (exception being IE). That feature should solely rely on the > >> > more reliable DNS based auto proxy discovery method. Even if you were > >> > somehow to come up with a way to do this in a semi-portable manner, you > >> > will have other issues such as multi-homed machines (which interface's > >> > ip address to use) etc ; so I rather doubt it is worth doing... > >> > >> Using a route lookup should yield the correct result on multi-homed hosts, > >> since it asks the kernel for what source address it would use when it >> sends > >> a packet to 255.255.255.255, but it's clearly not a portable solution and > >> would leave non-linux systems using the existing unreliable approach > >> unless someone else implemented a similar solution for them (eg I believe > >> BSD has a similar route API to linux netlink). > >> > >> I suppose since Firefox doesn't support DHCPINFORM lookups and there >> hasn't > >> been much complaint about that I guess you can infer it's not exactly a > >> critical feature. > >> > >> I am willing to have a go at implementing netlink route lookups on linux, > >> but DHCPINFORM discovery isn't critical for me since my networks support > >> both DHCPINFORM and DNS discovery, so if the consensus is that the > >> DHCPINFORM support should be dropped I won't bother. > > If you are willing to have a go at this, you might want to check if > SIOCGIFCONF with ioctl is a viable solution first. That should be more > portable even to Windows (SIO_GET_INTERFACE_LIST & ioctlsocket). There is > also getifaddrs/freeifaddrs, but that does not seem to be portable to the > commerical Unixes (e.g. Solaris) and Windows as you might have already > discovered. > > Anyhow, to me functionality like this is something that should be provided > by the KDE Solid library. I am sure there is a reason why > Solid::NetworkInterface does not provide this information at this time. > Perhaps if the ioctl approach works, then the functionality should simply be > merged into that class in order to avoid code duplication in the future... > > Regards, > > Dawit A.
