On 15/06/2015 2:42 a.m., Brian J. Murrell wrote: > On Sat, 2015-06-13 at 21:49 +1200, Amos Jeffries wrote: >> On 12/06/2015 11:48 p.m., Brian J. Murrell wrote: >>> On Fri, 2015-06-12 at 10:13 +1200, Amos Jeffries wrote: >>>> >>>> see <http://readlist.com/lists/squid-cache.org/squid-users/11/58405.html> >>> >>> Of course, I did see the rest of the messages in the thread. I'm not >>> sure what I'm supposed to be seeing in that particular message though >>> other than 3.4.3 worked for the person reporting that. >>> >>> So maybe I have a different problem? >> >> On the side of "probably". >> >>> >>>> - You speak of a > > >> If I assume it got as far as trying to connect it looks like it took >> 10sec waiting for some response. > > Indeed. That's what it looks like to me. > >> So, >> * can all of the DNS servers in your /etc/resolv.conf return results for >> irc.bcwireless.net? > > Yes. There is only one DNS server in my resolv.conf and that's the one > that runs on the same host as squid: > > $ dig irc.bcwireless.net any > > ; <<>> DiG 9.8.1-P1 <<>> irc.bcwireless.net any > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52707 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;irc.bcwireless.net. IN ANY > > ;; ANSWER SECTION: > irc.bcwireless.net. 300 IN AAAA fcaa:8ef7:51b9:8f04:58f1:7364:e16e:fe2f > irc.bcwireless.net. 300 IN A 198.27.79.54 > > ;; AUTHORITY SECTION: > bcwireless.net. 162451 IN NS kim.ns.cloudflare.com. > bcwireless.net. 162451 IN NS kip.ns.cloudflare.com. > > ;; Query time: 52 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Jun 14 10:39:21 2015 > ;; MSG SIZE rcvd: 133 > >> Probably these: >> debug_options ALL,1 11,2 44,2 5,5 17,5 > > I sent you a private e-mail with the log since it's long and as much as > I think I might have sanitized it, I don't want to unnecessarily leak > sensitive info. Sure. Thank you. 1) I have confirmed my suspicion that your IPv6 routing is a bit broken. The IPv6 address is in a private IP range fc00::/7. Which is the IPv6 equivalent of RFC1918 10.0.0.0/8 or 182.168.0.0/16. When your Squid contacts it nothing at all happens within 10 seconds. What should be happening is that when Squid tries to contact a network range which is not your own LAN fd31:aeb1:48df::/48 sub-net. The routing system in your Squid machine responds with a "network unavailable" within nanoseconds. This signal which is not appearing is what Squid depends on to to do the failover. Are you blocking ICMP? if so remove that. ICMP is not optional even in IPv4. Do you have an entry in the routing table for fc00::/7 or /8 ? in particular one larger than the fd31::/16 network your machines are talking on. If so, narrow it down to only your actual LAN range. 2) Squid should still be attemoting the IPv4 address though. Instead its just responding with an error and closing.doing failover though, but the CONNECT handling is for some reason seems to be generating an error page and deliverign it to teh celint iinstead of trying the IPv4. I also see you have Squid-3.4.3. Can you try an upgrade to 3.5.5 ? there have been some deep code stability fixes in this area since your version. If the problem persists after that upgrade. Please redo with 26,5 in the debug list. Also, check your proxy connect_timeout is shorter than forward_timeout. The connect timout affects these individual connections, forward_timeout needs to allow mulitiple (25?) of them for failover to have a chance in lost packet situations like this. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
