I have quite the same problem as reported, but not limited to bugs.debian.org.
Same
problem occurs e.g. with security.debian.org or www.debian.org. Yes, this
behaviour
seems to have started with squid3 3.1.6-1. Some other sites are affected as
well,
of course I cannot state that all sites with AAAA address records are affected.
But here's what I get from calling security.debian.org on log level 3. To me, it
seems as if squid is supposed to try all found addresses, including two v6 and
three
v4 addresses. It seems to record that connection to the v4 addresses was broken,
which is not the case (I can call up www.debian.org via one of the v4
addresses):
2010/09/05 16:08:09.364| fwdConnectStart: got TCP FD 29
2010/09/05 16:08:09.364| comm.cc(1195) commSetTimeout: FD 29 timeout 60
2010/09/05 16:08:09.364| comm.cc(1206) commSetTimeout: FD 29 timeout 60
2010/09/05 16:08:09.364| The AsyncCall SomeCommConnectHandler constructed,
this=0x242ee40 [call26912]
2010/09/05 16:08:09.364| commConnectStart: FD 29, cb 0x242ee40*1,
security.debian.org:80
2010/09/05 16:08:09.364| idnsALookup: buf is 37 bytes for security.debian.org,
id = 0xce35
2010/09/05 16:08:09.364| comm_udp_sendto: Attempt to send UDP packet to
127.0.0.1:53 using FD 9 using Port 49982
2010/09/05 16:08:09.365| StoreEntry::unlock: key
'5E00BEE466E7BCBF9FC93EC165CC152C' count=2
2010/09/05 16:08:09.443| idnsRead: starting with FD 9
2010/09/05 16:08:09.443| idnsRead: FD 9: received 178 bytes from 127.0.0.1:53
2010/09/05 16:08:09.443| idnsGrokReply: ID 0xce35, 3 answers
2010/09/05 16:08:09.443| idnsGrokReply: security.debian.org AAAA query done.
Configured to retrieve A now also.
2010/09/05 16:08:09.443| comm_udp_sendto: Attempt to send UDP packet to
127.0.0.1:53 using FD 9 using Port 49982
2010/09/05 16:08:09.444| idnsRead: FD 9: received 142 bytes from 127.0.0.1:53
2010/09/05 16:08:09.444| idnsGrokReply: ID 0xfb14, 3 answers
2010/09/05 16:08:09.444| ipcacheParse: security.debian.org #0
[2001:8d8:2:1:6564:a62:0:2]
2010/09/05 16:08:09.444| ipcacheParse: security.debian.org #1 [2001:a78::16]
2010/09/05 16:08:09.444| ipcacheParse: security.debian.org #2 [2001:a78::1a]
2010/09/05 16:08:09.445| ipcacheParse: security.debian.org #3 195.20.242.89
2010/09/05 16:08:09.445| ipcacheParse: security.debian.org #4 212.211.132.32
2010/09/05 16:08:09.445| ipcacheParse: security.debian.org #5 212.211.132.250
2010/09/05 16:08:09.445| ipcacheMarkBadAddr: security.debian.org
[2001:8d8:2:1:6564:a62:0:2]:80
2010/09/05 16:08:09.445| ipcacheCycleAddr: security.debian.org now at
[2001:a78::16] (2 of 6)
2010/09/05 16:08:09.445| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.445| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.446| ipcacheMarkBadAddr: security.debian.org
[2001:a78::16]:80
2010/09/05 16:08:09.446| ipcacheCycleAddr: security.debian.org now at
[2001:a78::1a] (3 of 6)
2010/09/05 16:08:09.446| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.446| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.446| ipcacheMarkBadAddr: security.debian.org
[2001:a78::1a]:80
2010/09/05 16:08:09.446| ipcacheCycleAddr: security.debian.org now at
195.20.242.89 (4 of 6)
2010/09/05 16:08:09.446| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.447| ipcacheMarkBadAddr: security.debian.org
195.20.242.89:80
2010/09/05 16:08:09.447| ipcacheCycleAddr: security.debian.org now at
212.211.132.32 (5 of 6)
2010/09/05 16:08:09.447| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.447| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.447| ipcacheMarkBadAddr: security.debian.org
212.211.132.32:80
2010/09/05 16:08:09.447| ipcacheCycleAddr: security.debian.org now at
212.211.132.250 (6 of 6)
2010/09/05 16:08:09.447| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.447| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.447| ipcacheMarkBadAddr: security.debian.org
212.211.132.250:80
2010/09/05 16:08:09.448| ipcacheCycleAddr: Changing ALL security.debian.org
addrs from BAD to OK
2010/09/05 16:08:09.448| ipcacheCycleAddr: security.debian.org now at
[2001:8d8:2:1:6564:a62:0:2] (1 of 6)
2010/09/05 16:08:09.448| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.448| commResetFD: Reset socket FD 29->31 : family=10
2010/09/05 16:08:09.448| ipcacheMarkBadAddr: security.debian.org
[2001:8d8:2:1:6564:a62:0:2]:80
2010/09/05 16:08:09.448| ipcacheCycleAddr: security.debian.org now at
[2001:a78::16] (2 of 6)
2010/09/05 16:08:09.448| ipcacheMarkAllGood: Changing ALL security.debian.org
addrs to OK (1/6 bad)
2010/09/05 16:08:09.449| commConnectCallback: FD 29
2010/09/05 16:08:09.449| comm.cc(1195) commSetTimeout: FD 29 timeout -1
2010/09/05 16:08:09.449| comm.cc(1206) commSetTimeout: FD 29 timeout -1
2010/09/05 16:08:09.449| comm.cc(934) will call SomeCommConnectHandler(FD 29,
errno=101, flag=-8, data=0x1e8baf8, ) [call26912]
2010/09/05 16:08:09.449| commConnectFree: FD 29
2010/09/05 16:08:09.449| entering SomeCommConnectHandler(FD 29, errno=101,
flag=-8, data=0x1e8baf8, )
2010/09/05 16:08:09.449| AsyncCall.cc(32) make: make call
SomeCommConnectHandler [call26912]
2010/09/05 16:08:09.449| forward.cc(280) fail: ERR_CONNECT_FAIL "Service
Unavailable"
http://security.debian.org/
2010/09/05 16:08:09.449| comm_close: start closing FD 29
2010/09/05 16:08:09.449| comm.cc(1195) commSetTimeout: FD 29 timeout -1
2010/09/05 16:08:09.449| comm.cc(1206) commSetTimeout: FD 29 timeout -1
2010/09/05 16:08:09.449| leaving SomeCommConnectHandler(FD 29, errno=101,
flag=-8, data=0x1e8baf8, )
Any ideas what's going on?
Best regards,
Andreas.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
