squid-deb-proxy problem on Raring, IPv6 I think.

[Karl Auer]

Sorry, not responding to the OP here; the questions are for the OP, not
Tom H:

On Sun, 2013-02-24 at 15:50 -0500, Tom H wrote:
> >>> I have a problem with squid-deb-proxy on Raring which I think may be
> >>> an IPv6 related issue.
> >>>
> >>> With squid-deb-proxy and squid-deb-proxy-client on the same machine,
> >>> running Raring, when I run apt-get update I see error messages for
> >>> every connection, for example
> >>>
> >>> W: Failed to fetch
> >>> http://gb.archive.ubuntu.com/ubuntu/dists/raring-updates/restricted/binary-i386/Packages
> >>>  Cannot initiate the connection to fe80::290:f5ff:fece:342f:8000
> >>> (fe80::290:f5ff:fece:342f). - connect (22: Invalid argument)
> >>>
> >>> I think it is actually the client that is the issue as when I run
> >>> squid-deb-proxy-client on another box, running 12.04, but using the
> >>> proxy on Raring, then all is well.

How exactly does the client determine the address of the proxy?

The DNS does not return that address for gb.archive.ubuntu.com. Nor
would I would expect it to - it's a link local address. It looks to me
as if something is blindly substituting that address for the real one,
but is failing to add the zone identifier that is needed on link local
addresses. That error message is exactly what you would see if you did

   ping6 fe80::290:f5ff:fece:342f

on the client, instead of 

   ping6 fe80::290:f5ff:fece:342f%eth0

If the IPv6 protocol stack were doing this itself, it would "just work".
On the other hand, I can't see how a higher-level actor would know about
the link local address. So it's a puzzle!

I don't really understand avahi :-) but this entry looks like a suspect:

> > _apt_proxy._tcp      local
> >    hostname = [tigger.local]
> >    address = [fe80::290:f5ff:fece:342f]
> >    port = [8000]
> >    txt = []
> > =   eth0 IPv6 tigger
> > [..]

If the client is relying on avahi to get the address(es) of the proxy,
then this is probably the problem, combined with the fact that the
client is apparently not adding zone identifiers to link local
addresses. That's not avahi's fault, because it does supply the
interface name. If you can get avahi to return a global unicast IPv6
address for the proxy instead, that would probably solve the problem. Or
get a global unicast address for the proxy to the client some other way.

If you are not otherwise using IPv6 (i.e., your machines don't have
global unicast addresses), then the only fix I can see is to disable
IPv6 on the proxy, so that it doesn't HAVE a link local address. That's
an ugly solution, suitable only if the proxy is a single-service
machine. You can disable IPv6 on a Linux machine thus:

   sysctl -w net/ipv6/conf/all/disable_ipv6=1

And optionally make the equivalent change to /etc/sysctl.conf to make
the change permanent.
 
Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017