[squid-users] possible bug on 2.7S9

     Hi,

     i'll try to describe with the most details i can what i think is
something like a forwarding-loop-detection bug on 2.7S9

     i have squid 2.7S9 running on a CentOS 5.5 x64 box whici has 4
NICs. 3 NICs are for internal networks (192.168.x) and 1 NIC is for
internet (189.73.x.x). It was built with:

[root_at_firewall squid]# squid -v
Squid Cache: Version 2.7.STABLE9
configure options: '--prefix=/usr' '--exec-prefix=/usr/bin'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/bin'
'--sysconfdir=/etc/squid' '--datadir=/var/squid' '--localstatedir=/var'
'--enable-removal-policies=heap,lru' '--enable-storeio=ufs,aufs,null'
'--enable-delay-pools' '--enable-http-violations' '--with-maxfd=8192'
'--enable-async-io=8' '--enable-err-languages=Portuguese English'
'--enable-default-err-language=Portuguese' '--enable-snmp'
'--disable-ident-lookups' '--enable-linux-netfilter'
'--enable-auth=basic digest ntlm negotiate'
'--enable-basic-auth-helpers=DB LDAP NCSA SMB'
'--enable-digest-auth-helpers=password ldap'
'--enable-external-acl-helpers=ip_user ldap_group session wbinfo_group'
'--enable-negotiate-auth-helpers=squid_kerb_auth'
'--enable-ntlm-auth-helpers=fakeauth no_check' '--enable-useragent-log'
'--enable-referer-log' '--disable-wccp' '--disable-wccpv2'
'--enable-arp-acl' '--with-large-files' '--enable-large-cache-files'
'--enable-ssl' '--enable-icmp'

     i've setup squid with something like:

acl localhost src 127.0.0.1/255.255.255.255
acl localhost_to dst 127.0.0.1/255.255.255.255

acl network1 src 192.168.1.0/255.255.255.0
acl network1_to dst 192.168.1.0/255.255.255.0

acl network2 src 192.168.2.0/255.255.255.0
acl network2_to dst 192.168.2.0/255.255.255.0

acl network3 src 192.168.3.0/255.255.255.0
acl network3_to dst 192.168.3.0/255.255.255.0

http_port 8080 transparent
http_port 3128 transparent

tcp_outgoing_address 127.0.0.1 localhost_to
tcp_outgoing_address 192.168.1.1 network1_to
tcp_outgoing_address 192.168.2.1 network2_to
tcp_outgoing_address 192.168.3.1 network3_to
tcp_outgoing_address 189.73.x.x all

     config is OK, it runs just fine.

     problem is, on a given day, squid stop responding new connections
and i have to stop it (service squid stop). After searching logs, i have
found some interesting requests:

1288136326.944 48437 192.168.2.15 TCP_MISS/000 0 GET
http://localhost:8080/sync/sis/index.php - DIRECT/127.0.0.1 -
1288136326.944 48426 127.0.0.1 TCP_MISS/000 0 GET
http://localhost:8080/sync/sis/index.php - DIRECT/127.0.0.1 -
(and this second line repeated about 13000 times)

     and during these, i got also on cache.log:

2010/10/26 21:37:59| WARNING! Your cache is running out of filedescriptors
2010/10/26 21:38:15| WARNING! Your cache is running out of filedescriptors
2010/10/26 21:38:31| WARNING! Your cache is running out of filedescriptors
2010/10/26 21:38:48| WARNING! Your cache is running out of filedescriptors
2010/10/26 21:39:04| WARNING! Your cache is running out of filedescriptors
2010/10/26 21:39:20| WARNING! Your cache is running out of filedescriptors

     i'm running with 8192 filedescriptors on a 150 clients network,
that's more than enough filedescriptors for normal usage.

(from cache.log)
2010/10/31 12:27:50| Starting Squid Cache version 2.7.STABLE9 for
x86_64-unknown-linux-gnu...
2010/10/31 12:27:50| Process ID 16093
2010/10/31 12:27:50| With 8192 file descriptors available

     Well ..... after found that, i tried to reproduce it doing some
request to localhost:8080 on 8080 squid port and i could successfully
reproduce it, all the times, with the above squid.conf configuration.

     after some tryings, i have found that:

1) removing the:
tcp_outgoing_address 127.0.0.1 localhost_to

     would avoid the problem and make the forwarding-loop-detection
works fine

2) removing the transparent from
http_port 8080 transparent

     would avoid the problem too, even with the tcp_outgoing_address
127.0.0.1 active

     question is ..... squid NOT detecting this forwarding-loop should
be expected with this transparent and tcp_outgoing_address combination ?
Are we talking of a bug or are we talking of some expected behavior ? Is
there any other information that i could provide to help tracking this ?

-- 
	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br
	Minha armadilha de SPAM, NÃO mandem email
	gertrudes_at_solutti.com.br
	My SPAMTRAP, do not email it