On 13.03.2012 22:10, Eugene M. Zheganin wrote:
Hi.
I'm using squid 3.1.x on FreeBSD. Squid is built from ports.
Recently I was hit by a weird issue: my users cannot open HTTPS
pages. This is not something constant - if they hit the F5 button in
browser, the pages are loading, sometimes showing the message like
'Unable to connect. Firefox can't establish a connection to the
server
at access.ripe.net.' (for example. most of them are using FF). In the
same time plain HTTP pages are working fine.
I did some investigation and it appears like squid really thinks it
cannot connect to HTTPS-enabled web server:
As you guessed this does seem to be a stack issue. Dual-stack systems
can be configured to operate as hybrid stacks or as split stacks (two
distinct socket handling paths). Recently there has been a trend away
from the simpler hybrid stacks towards split stacks.
Squid-3.1 was written for hybrid stacks with v4-mapping ability. When
run on stack without mapping (split) it cannot reset the FD protocol to
switch stack types. Workaround/Support for split stacks has been added
incrementally across the 3.1 series, with some of the deeper changes
only in 3.2.
===Cut===
<snip>
2012/03/13 14:08:39.661| ipcache_nbgethostbyname: HIT for
'access.ripe.net'
Found the site IPs.
assuming: connect to the first one (IPv6).
2012/03/13 14:08:39.662| ipcacheMarkBadAddr: access.ripe.net
[2001:67c:2e8:22::c100:685]:443
Didn't work. Mark it bad.
2012/03/13 14:08:39.662| ipcacheCycleAddr: access.ripe.net now at
193.0.6.133 (2 of 2)
2012/03/13 14:08:39.662| commResetFD: Reset socket FD 14->16 :
family=28
2012/03/13 14:08:39.662| commResetFD: Reset socket FD 14->16 :
family=28
Reset the socket FD to convert for the new IP (v4).
assuming: socket still IPv6 and trying to use for IPv4?
assuming: connect to this IP also failed.
2012/03/13 14:08:39.662| ipcache_nbgethostbyname: Name
'access.ripe.net'.
2012/03/13 14:08:39.662| ipcache_nbgethostbyname: HIT for
'access.ripe.net'
2012/03/13 14:08:39.662| commResetFD: Reset socket FD 14->16 :
family=28
2012/03/13 14:08:39.662| commResetFD: Reset socket FD 14->16 :
family=28
Reset the socket FD (again).. Bit strange that this is still "14->16".
2012/03/13 14:08:39.662| ipcacheCycleAddr: access.ripe.net now at
193.0.6.133 (2 of 2)
2012/03/13 14:08:39.662| ipcache_nbgethostbyname: Name
'access.ripe.net'.
2012/03/13 14:08:39.662| ipcache_nbgethostbyname: HIT for
'access.ripe.net'
2012/03/13 14:08:39.662| ipcacheMarkAllGood: Changing ALL
access.ripe.net addrs to OK (1/2 bad)
Failed a second time. tries > number of IPs (huh? 3 or 2 tries?)
Instead of retrying yet again, cycle the IPs ...
2012/03/13 14:08:39.662| errorpage.cc(1051) BuildContent: No existing
error page language negotiated for ERR_CONNECT_FAIL. Using default
error file.
... and respond with error.
===Cut==
But why ? I did some telnetting from this server to the
access.ripe.net:443, and it succeeded like 10 from 10 times (squid
error rate is far more frequent). The only thing that bothers me is
that telnet also first tries ipv6 too, but then switches to the ipv4,
and connects.
Now some suggestions (probably a shot in the dark). This only happens
on an ipv6-enabled machines, but without actual ipv6 connectivity (no
ipv6 default route or no public ipv6 address, for example I have
unique-local addresses for the testing purposes). In the same time
this issue can be easily solved by restoring the ipv6 connectivity to
the outer world. So, can it be some dual-stack behavior bug ? Or is
it
'by design' ? Do I need to report it ?
Squid opens an IPv6 socket by default, attempts the IPv6 destination
(route down, IPv6 socket). Fails. Then attempts to reset the socket
protocol family and contact the IPv4 destination (route fine, IPv6
socket [oops!]).
You can avoid this in 3.1 by enabling v4-mapping capability in your
kernel or using "tcp_outgoing_address 0.0.0.0" to force the sockets to
be IPv4-only from the start. 3.2 series has better split-stack support
so should have this behaviour problem fixed now.
Amos
