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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
