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

[Tom H]

On Sun, Feb 24, 2013 at 3:40 AM, Colin Law <clanlaw at googlemail.com> wrote:
> On 23 February 2013 22:52, Tom H <tomh0665 at gmail.com> wrote:
>> On Sat, Feb 23, 2013 at 6:26 AM, Colin Law <clanlaw at googlemail.com> wrote:


>>> I have a problem with squid-deb-proxy on Raring which I think may be
>>> an IPv6 related issue.  I hope someone can tell me whether it is a bug
>>> or a configuration issue.  In fact even if it is configuration it is
>>> likely also a bug as I am seeing it on a virgin install.
>>>
>>> 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.
>>
>> "fe80..." is the ipv6 equivalent of "169.254...".
>>
>> WAG: If you have avahi (and avahi-utils) installed, check whether it's
>> the culprit with "avahi-browse -akrt".
>
> avahi-utils is installed, there doesn't seem to be a package avahi but
> I assume that utils will pull in the appropriate stuff.

I should've said "avahi-daemon", sorry.


> user at tigger:~$ avahi-browse -akrt
> +   eth0 IPv6 Squid deb proxy on tigger
> _apt_proxy._tcp      local
> +   eth0 IPv4 Squid deb proxy on tigger
> _apt_proxy._tcp      local
> +   eth0 IPv6 tigger [00:90:f5:ce:34:2f]
> _workstation._tcp    local
> +   eth0 IPv4 tigger [00:90:f5:ce:34:2f]
> _workstation._tcp    local
> +   eth0 IPv6 tigger
> _udisks-ssh._tcp     local
> +   eth0 IPv4 tigger
> _udisks-ssh._tcp     local
> =   eth0 IPv6 tigger [00:90:f5:ce:34:2f]
> _workstation._tcp    local
>    hostname = [tigger.local]
>    address = [fe80::290:f5ff:fece:342f]
>    port = [9]
>    txt = []
> =   eth0 IPv6 Squid deb proxy on tigger
> _apt_proxy._tcp      local
>    hostname = [tigger.local]
>    address = [fe80::290:f5ff:fece:342f]
>    port = [8000]
>    txt = []
> =   eth0 IPv6 tigger
> _udisks-ssh._tcp     local
>    hostname = [tigger.local]
>    address = [fe80::290:f5ff:fece:342f]
>    port = [22]
>    txt = []
> =   eth0 IPv4 Squid deb proxy on tigger
> _apt_proxy._tcp      local
>    hostname = [tigger.local]
>    address = [192.168.1.92]
>    port = [8000]
>    txt = []
> =   eth0 IPv4 tigger
> _udisks-ssh._tcp     local
>    hostname = [tigger.local]
>    address = [192.168.1.92]
>    port = [22]
>    txt = []
> =   eth0 IPv4 tigger [00:90:f5:ce:34:2f]
> _workstation._tcp    local
>    hostname = [tigger.local]
>    address = [192.168.1.92]
>    port = [9]
>    txt = []
> +   eth0 IPv4 owl [f0:ad:4e:00:41:33]
> _workstation._tcp    local
> =   eth0 IPv4 owl [f0:ad:4e:00:41:33]
> _workstation._tcp    local
>    hostname = [owl.local]
>    address = [192.168.1.96]
>    port = [9]
>    txt = []
> +   eth0 IPv4 roo [00:1d:92:71:e2:0c]
> _workstation._tcp    local
> +   eth0 IPv4 roo
> _udisks-ssh._tcp     local
> =   eth0 IPv4 roo [00:1d:92:71:e2:0c]
> _workstation._tcp    local
>    hostname = [roo.local]
>    address = [192.168.1.98]
>    port = [9]
>    txt = []
> =   eth0 IPv4 roo
> _udisks-ssh._tcp     local
>    hostname = [roo.local]
>    address = [192.168.1.98]
>    port = [22]
>    txt = []
> +   eth0 IPv4 joggler [00:00:00:00:00:00]
> _workstation._tcp    local
> =   eth0 IPv4 joggler [00:00:00:00:00:00]
> _workstation._tcp    local
>    hostname = [joggler.local]
>    address = [fe80::20e:8eff:fe22:9be3]
>    port = [9]
>    txt = []
>
> Is that as it should be?  The local machine is tigger obviously.

I was hoping that you wouldn't have an ipv4 apt proxy entry. The
command that I asked you to run was therefore pretty much useless.

BUT!

I've been googling and found two old bug reports in which there are
better searches [1] [2] that show the problem is "avahi-browse" (and
that the workaround that you posted whereby you edited "30autoproxy"
is a good one) because "30autoproxy" runs "apt-avahi-discover",
"apt-avahi-discover" uses "avahi-browse" to find "_apt_proxy._tcp",
and "avahi-browse" sometimes returns an ipv4 result and sometimes
returns an ipv4 one.

1. https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/655187/comments/10

2. https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/686265/comments/11