Bug #115487 - automatic proxy discovery problems

[Dawit A]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100605/a954213d/attachment.htm>