Alan DeKok wrote:
Josip Almasi wrote:
compiled current 2.1.11 branch on RHEL 6.0 and RHEL 5.5, hit it with about 7.5K req/s, and it dies on both, after about 1-3.5M requests.
Argh. I've tested it with 40K packets/s for *days*, and haven't seen this.
Yep, seen you write this before:)
So it seems something still frees data before yanking list...? Well, beats me. Any hints?
Grab the "master" branch. See http://git.freeradius.org for instructions. The internal state machine has been *completely* re-written so that it's sane. If the bug still exists there, I'll be shocked.
Will try. I don't remember why exactly, but master didn't work for me.
Now, how to reproduce:
- get spizd 0.5 from http://sourceforge.net/projects/spizd/files/ - unzip, have java in path - edit etc/dictionary.txt, enter at least one username:password pair - run bin/spizd-radius.sh <server>, verify you get Access-Accept
Why? Why not just run "radclient"? Or radperf (http://networkradius.com)
In fact I needed a simple tool to stress various servers and protocols. Spizd vs radclient is thread vs process. But spizd vs radperf is... well, sure there are better tools for any specific protocols. Though seems I don't need them, see I killed it anyway;) And, radperf wants me to register;> Regards...