On Sat, 19 Mar 2011 21:10:51 -0000, Steve wrote:
Hi all,
I wonder if anyone can help. I am using Squid 3.2.0.4 compiled with
-disable-ipv6. Whenever I access hosts that have AAAA records as well
as A
records then an attempt is made to access them using IPv6. My network
doesn't have IPv6 so it is no surprise the attempts to connect to
IPv6
destinations do not work. Given that I have compiled with
-disable-ipv6
option I would not expect Squid to even bother looking up the AAAA
records.
Squid also crashes and automatically restarts after the connect to an
IPv6
address fails.
I have included a relevant log extract below showing the problem as
well as
output from squid -v.
Is there any way to force Squid to fully ignore ipV6?
Any assistance or pointers would be gratefully received.
Thanks
Steve
Squid Cache: Version 3.2.0.4
configure options: '--prefix=/usr/arcadia/Squid_0'
'--enable-replacement-policies=heap,lru' '--enable-snmp'
'--enable-delay-pools' '--enable-removal-policies=heap,lru'
'--enable-useragent-log' '--enable-auth' '--enable-auth-basic=LDAP'
'--enable-external-acl-helpers=LDAP_group' '--disable-ipv6'
--enable-ltdl-convenience
2011/03/16 23:27:25.278 kid1| idnsALookup: buf is 39 bytes for
secure.nominet.org.uk, id = 0x0
2011/03/16 23:27:25.296 kid1| idnsRead: starting with FD 8
2011/03/16 23:27:25.296 kid1| commSetSelect(FD
8,type=1,handler=1,client_data=0,timeout=0)
2011/03/16 23:27:25.296 kid1| comm_udp_recvfrom: FD 8 from [::]
2011/03/16 23:27:25.296 kid1| idnsRead: FD 8: received 91 bytes from
10.99.99.55:53
2011/03/16 23:27:25.296 kid1| idnsGrokReply: QID 0xb731, 2 answers
2011/03/16 23:27:25.296 kid1| idnsGrokReply: secure.nominet.org.uk
AAAA
query done. Configured to retrieve A now also.
2011/03/16 23:27:25.296 kid1| comm_udp_recvfrom: FD 8 from
10.99.99.55:53
2011/03/16 23:27:25.300 kid1| comm_select(): got FD 8 events=1
monitoring=19
F->read_handler=1 F->write_handler=0
2011/03/16 23:27:25.300 kid1| comm_select(): Calling read handler on
FD 8
2011/03/16 23:27:25.300 kid1| idnsRead: starting with FD 8
2011/03/16 23:27:25.300 kid1| commSetSelect(FD
8,type=1,handler=1,client_data=0,timeout=0)
2011/03/16 23:27:25.300 kid1| comm_udp_recvfrom: FD 8 from [::]
2011/03/16 23:27:25.300 kid1| idnsRead: FD 8: received 79 bytes from
10.99.99.55:53
2011/03/16 23:27:25.300 kid1| idnsGrokReply: QID 0xb000, 2 answers
2011/03/16 23:27:25.300 kid1| dns_internal.cc(1197) idnsGrokReply:
Merging
DNS results secure.nominet.org.uk AAAA has 2 RR, A has 2 RR
2011/03/16 23:27:25.300 kid1| dns_internal.cc(1221) idnsGrokReply:
Sending 4
DNS results to caller.
2011/03/16 23:27:25.300 kid1| comm.cc(1033) connect: to
[2a01:618:300:1:3a0:b555:5db7:f25d]:443
2011/03/16 23:27:25.300 kid1| comm.cc(1163) comm_connect_addr:
connecting
socket FD 15 to [2a01:618:300:1:3a0:b555:5db7:f25d]:443 (want family:
2)
2011/03/16 23:27:25.300 kid1| comm.cc(1049) connect: FD 15:
COMM_ERR_PROTOCOL - try again
2011/03/16 23:27:25.300 kid1| commSetSelect(FD
15,type=0,handler=0,client_data=0,timeout=0)
2011/03/16 23:27:25.300 kid1| comm_udp_recvfrom: FD 8 from
10.99.99.55:53
An *IPv4* DNS packet is received.
... then Squid crashes.
This indicates either a crash handling DNS packets, or somewhere
unrelated and not logged.
The weird thing is that earlier successful packets were received from
the wildcard UDP listening address [::]. Yet the first sign of an
IPv4-only UDP receive dies.
Please try todays 3.2 snapshot tarball, if it can be replicated there
please get a full debug trace (level ALL,9).
Giving that a brief look may show the crash somewhere else. Then please
follow the usual bug reporting procedure (checking the crash is not
already known and reported, then reporting along with the trace).
2011/03/16 23:27:28.313 kid1| fd_open() FD 5
/nosave/Squid_0/logs/cache.log
2011/03/16 23:27:28.313 kid1| Starting Squid Cache version 3.2.0.4
for
x86_64-unknown-linux-gnu...
2011/03/16 23:27:28.313 kid1| idnsInit: attempt open DNS socket to:
[::]
2011/03/16 23:27:28.313 kid1| comm_open: FD 7 is a new socket
2011/03/16 23:27:28.314 kid1| fd_open() FD 7 DNS Socket IPv6
Amos
