>>> There has been a change in behaviour in 3.5.4. It now really does
>>> prefer to contact a site using an ipv6 address rather than a v4. The
>>> network stack here doesn't permit v6 so the traffic to sites such as
>>> google was failing. Setting the following restored the previous
>>> behaviour:
>>>
>>> dns_v4_first on
>>
>> As far as I'm aware squid won't try to use ipv6 unless your server has a
>> Global address, so that shouldn't be needed? Also, wouldn't squid simply
>> treat that as a DNS name that resolves to a bunch of addresses, so as
>> long as the IPv6 addresses fail to connect at all, it should have still
>> ended up succeeding with ipv4 addresses?
>>
The description of dns_v4_first (squid.conf.documented) says
With the IPv6 Internet being as fast or faster than IPv4 Internet
for most networks Squid prefers to contact websites over IPv6.
This option reverses the order of preference to make Squid contact
dual-stack websites over IPv4 first. Squid will still perform both
IPv6 and IPv4 DNS lookups before connecting.
This does indicate specific treatment of IPv6 addresses.
>> Finally, I'm running squid-3.5.4, don't have ipv6 (just like everyone
>> else, I still do have the standard fe80:xxx ipv6 link local address) and
>> google.com works just fine without "dns_v4_first" - which implies my
>> statements above are correct
>>
>> ie this smells like you actually do have ipv6 enabled, but it's broken
>> in some subtle way (like the pmtu issue Amos mentioned)
>>
>
>
> The tunnel.cc code producing that read/write error is one of the bits
> still broken in regards to errno usage. So I dont entirely trust that
> "endpoint not connected" detail, it seems right but could be something
> subtly different.
>
> Ayways, to get the output at all the TCP SYN/ACK handshake has to have
> already setup the IPv6 connection with no errors. Then a (first? TLS?)
> read/write operation attempted on the IPv6 socket fails and does that
> log message
>
> There is supposed to be callback event protections preventing closed
> sockets being used for read/write (adding to suspicion about the log
> message), which is where I'm currently trying to figure out what state
> things could be in.
>
> Amos
>
I've done some more investigation. The problem is not SSL-related, but
merely IPv6-related.
A network trace confirms that, in the failing IPv6 case, no traffic
leaves the squid host. This is
expected, as there is no v6 routing. I had the default IPv6 link-local
address on each interface,
but as an experiment removed all IPv6 addresses from all interfaces, and
the problem is still the
same. Similarly a traceroute6 correctly reports no route.
In the "configure" help, there is an option to not build v6 support. The
comment indicates that
squid probes the kernel to determine if it is v6-capable. The problem
arises when the kernel is compiled
with v6 support, but v6 is not operational on any interface - no
addresses, no routes etc.
With 3.5.3 I didn't "see" the default "dns_first_v4 off" actually doing
anything. So for a destination host
that had a v4 address it would try to use those, and it worked. I don't
know whether it never tried the
v6 address, or maybe it did, realised it had failed, and then
successfully tried one of the other v4
addresses. With 3.5.4 it definitely goes for the v6 address and then
fails hard (transport not connected)
without attempting to use any of the v4 addresses.
My hunch is that 3.5.4 has introduced a problem with error handling in
the v6 code, causing it to fail and
never try any other addresses.
For the majority of installations that do not have v6 capability, I
suspect that the default setting
of "dns_first_v4 off" is inefficient for sites with both v4 and v6
addresses as it always tries the v6 addresses
and fails, then goes for the v4 ones that work?? If that is the case, a
better default for v4
installations might be "dns_first_v4 on". It would obviously fail on
v6-only destinations but that is to
be expected.
There is a warning in the documentation about using dns_first_v4 though
which I don't really understand.
I'd like to know what the implications are - and whether I would be
better simply building squid
without v6 support at all.
Chris
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
