[squid-users] 3.5.4 Can't access Google or Yahoo SSL pages

[Amos Jeffries]

On 5/05/2015 4:35 p.m., Jason Haar wrote:
> On 04/05/15 20:53, Chris Palmer wrote:
>> 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?
> 
> 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