fr_packet_cmp again

Alan DeKok aland at deployingradius.com
Thu Apr 28 09:49:56 CEST 2011


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.

> It's not about threads; tried with -s, and it still dies.

  That's good to know.  I'm not sure what it means, but it's good to know.

> 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.

> 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)

> - edit etc/spizd.properties: change verboseThis and verboseThat to
> false, change spizd.circular to true
> - run spizd-radius.sh again and wait, it dies about 10-15 mins later
> - optionally, increase maxThreads to kill it faster
> 
> What this test does: Access-Request, Acct Start, (optionally a number of
> Interim-Update), Acct Stop - sending request imediatelly after response
> to previous request is received, thread per session.

  Hmm... that sounds to me like the issue is accounting packets getting
deleted while they're still being referenced.

  Alan DeKok.



More information about the Freeradius-Devel mailing list