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

[Tom H]

On Sun, Feb 24, 2013 at 4:51 PM, Karl Auer <kauer at biplane.com.au> wrote:
> 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?

With "avahi-browse".


> 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!

The problem is that the OP needs an ipv4 address to be returned not an
ipv6 one. (If he wanted an ipv6 one, I don't think that he'd want a
link-local ipv6 address to be returned because I don't think that it
would work, unless ipv6 link-local addresses are different from ipv4
ones in this respect.)


> 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.

The "avahi-browse" incantation returned both the ipv4 and ipv6
proxies. The one that "deb-squid-proxy" uses returns one or the other
- and according to the bug reports that I've seen, it returns the ipv6
one more often.


> 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.

Why optionally? :)

It's probably better to disable ipv6 just for avahi with "use-ipv6=no"
in "/etc/avahi/avahi-daemon.conf".

But these are just workarounds.