Bug #115487 - automatic proxy discovery problems

[Dawit A]

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 <adawit at kde.org> 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.