Alan DeKok wrote:
Curtis Doty [EMAIL PROTECTED] wrote:
Yes, disabling this feature works around. But what about the
aforementioned request confuses radiusd? Auth failures respond
immediately from other nas devices. And the reject_delay feature is
desirable.
It's a bug. It doesn't
I just found a PIX that kicks out the following auth:
User-Name = bozo
NAS-IP-Address = 10.1.1.1
User-Password = krusty
NAS-Port = 103
Cisco-AVPair = ip:source-ip=10.1.1.2
To which freeradius does not respond until *after* the pix sends the
first retry
Curtis Doty [EMAIL PROTECTED] wrote:
To which freeradius does not respond until *after* the pix sends the
first retry packet.
Set reject_delay = 0
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan DeKok wrote:
Curtis Doty [EMAIL PROTECTED] wrote:
To which freeradius does not respond until *after* the pix sends the
first retry packet.
Set reject_delay = 0
Yes, disabling this feature works around. But what about the
aforementioned request confuses radiusd? Auth
Curtis Doty wrote:
Alan DeKok wrote:
Curtis Doty [EMAIL PROTECTED] wrote:
To which freeradius does not respond until *after* the pix sends the
first retry packet.
Set reject_delay = 0
Yes, disabling this feature works around. But what about the
aforementioned request confuses
Curtis Doty [EMAIL PROTECTED] wrote:
Yes, disabling this feature works around. But what about the
aforementioned request confuses radiusd? Auth failures respond
immediately from other nas devices. And the reject_delay feature is
desirable.
It's a bug. It doesn't work for *any* nas
Curtis Doty [EMAIL PROTECTED] wrote:
I'm still curious as to why radiusd can't handle these requests but
handles others fine. Does this bug belong on http://bugs.freeradius.org
or on the http://bugzilla.redhat.com site?
There's already a bug open for it. I forget which one.
And please
7 matches
Mail list logo
