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 packet. The delay is always until the first retry; regardless if whatever I set the pix retry timer. Nor is it affected by the cleanup_delay or reject_delay. However, the last retry is eventually responded to after the 30 second max_request_time. The pix is only collecting timeouts on the aaa-server scoreboard. The problem goes away if radiusd is put in single process mode. Platform is Fedora Core and this is reproducible with their RPMs as well as pristine freeradius 1.1. ../C
Alan DeKok wrote:
Curtis Doty <Curtis@GreenKey.net> 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 failures respond immediately from other nas devices. And the reject_delay feature is desirable. Also, I tried compiling --without-threads but the source ignored this and still built with. ../C
Curtis Doty wrote:
Alan DeKok wrote:
Curtis Doty <Curtis@GreenKey.net> 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 failures respond immediately from other nas devices. And the reject_delay feature is desirable.
Also, I tried compiling --without-threads but the source ignored this and still built with.
Nevermind on that last comment only. I was installing in the wrong location. Compiling on Fedora Core --without-threads does also work around the buggy handling of these auth requests. 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? ../C
Curtis Doty <Curtis@GreenKey.net> 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 use the bugs.freeradius.org site for FreeRADIUS bugs. If there are problem with the redhat RPM's, file a bug with them. Alan DeKok.
Curtis Doty <Curtis@GreenKey.net> 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 devices except by accident. Alan DeKok.
Alan DeKok wrote:
Curtis Doty <Curtis@GreenKey.net> 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 devices except by accident.
Hrmm, I notice quite a few post-1.1.0 changes around the spawn_flag in cvs. And an initial test of my case proves successful, FYI. Is this by design or still by accident? ../C
participants (2)
-
Alan DeKok -
Curtis Doty