[squid-users] Further diagnosis on squid/radius auth problems

Hi,

I've had a whole series of issues with Squid and radius, and I believe
that at last I have some meat for diagnosis. The problem seems to be
with squid_auth_radius, but this seems to be the only related mailing
list.

I'm using:

Squid Cache: Version 2.5.STABLE13
configure options: --prefix=/usr/local/squid --enable-snmp --disable-internal-dns

on RHEL 4 with squid_radius_auth 1.08.

At times it has seemed that clients attempting to authenticate are
being rejected despite having good passwords. Similarly, users have
been able to get out to the Internet without a legitimate username and
password. Squid's debugging output shows that the authenticator was
returning an "ok" response for these nonexistent usernames and
passwords. At the time this happened, we would see "Warning: Received
invalid reply digest from server" errors. A "squid -k reconfigure"
made those go away by restarting the authenticator children, of
course, but running that once a minute is not an ideal solution.

I'm not comfortable doing random debugging in C, so I made an
alternate authenticator out of Perl, based on authen::radius, that
logged via syslogd whenever it attempted authentication and the
results of that authentication attempt. Either the problem would go
away, or I'd have some debugging output. :-)

The problem persisted, but I now logged requests that did and didn't
match and could compare them to the Radius logs. The Radius
authenticator returned an error when the Radius server had returned
OK.

At the time of the error, netstat -na -u on the RHEL box shows:

Proto Recv-Q Send-Q Local Address Foreign Address State
...
udp 0 0 10.184.1.94:33006 10.184.1.56:1812 ESTABLISHED
udp 0 0 10.184.1.94:33007 10.184.1.56:1812 ESTABLISHED
udp 0 0 10.184.1.94:33008 10.184.1.56:1812 ESTABLISHED
udp 2352 0 10.184.1.94:33009 10.184.1.56:1812 ESTABLISHED
udp 0 0 10.184.1.94:33010 10.184.1.56:1812 ESTABLISHED

lsof shows that the process with the big recv queue is the
authenticator. This happens with both squid_radius_auth and my perl
applet.

I see a couple of possibilities:

a) Red Hat ties up the buffer somehow
b) problem in the radius routines in squid_rad_auth
c) problem with squid taking the data back from authenticator, or
   interaction between squid and squid_rad_auth

Surely someone out there has experienced this? Any pointers on where
to look further?

On a related note, should Squid use the same authenticator child most
of the time? I have five running, but the log shows that the same
child gets queried again and again. We rarely get busy enough to need
the second child, however.

==ml

-- 
Michael W. Lucas	mwlucas@FreeBSD.org, mwlucas@BlackHelicopters.org
		http://www.BlackHelicopters.org/~mwlucas/
	    Latest book: PGP & GPG -- http://www.pgpandgpg.com
"The cloak of anonymity protects me from the nuisance of caring." -Non Sequitur