valts at bsdradius.org
Sun Jan 14 21:53:30 CET 2007
I already had a suspicion that I would get reply to my previous email
Alan DeKok wrote:
> If you're going to bash the server and direct people to your own
> product, I suggest you unsubscribe.
This is not the case. I have been user of FreeRADIUS for very long
time, and I (and company I worked for then) decided that it will be
much easier and comfortable to make small RADIUS server which would not
be designed for general use. It's main purpose is to provide easy and
stable backend for writing modules in Python. I tried to do the same
with FreeRADIUS some time ago. There were fixes to rlm_python but it
still has never worked as expected (at least on all my systems).
I am not going to redirect any FreeRADIUS user to my product. The very
most of FreeRADIUS users don't want to develop their own modules in
Oh, and I am so unlucky to be the maintainer of another RADIUS project.
Seems like this is very serious reason for bashing me.
> As for the comments on your web page:
> > While there are quite large number of Radius servers (including
> > free) available in the world, little number of them (if any) are
> > developed with VoIP specific needs in mind.
> FreeRADIUS is developed with VOIP in mind, along with 802.1x, and
> almost anything else RADIUS related. In fact, by editing 3 lines of
> text in "radiusd.conf", the server will support VOIP out of the box.
> But you're right, that's too much work. I'll update the "digest"
> module so that that much work is no longer necessary.
VoIP doesn't consist only of digest authorization. Digest is SIP
specific, by the way.
> > Typical VoIP RADIUS server should be able to take high amount of AAA
> > requests in short time periods, handle large databases, and respond
> > timely to prevent time-outs and request retransmission cases.
> RADIUS servers that don't do that are servers that no one uses.
In case of all known radius servers they become slow when there's
serious business logic implemented in the backend. And what if
authorization requests had higher priority than the accounting ones?
And what if accounting response could be sent even before processing
the request? It is a major speedup. It is optimization in design, not
in several parts of code.
> > Most commonly used VoIP protocols (SIP and H.323) use small number
> > of Authentication methods (e.g. CHAP and Digest), and this can allow
> > reduce processing overhead and code size of server.
> "reduce processing overhead" - Nonsense.
> FreeRADIUS is configurable, to let you process only what you need
> for your site. And if your RADIUS server is handling more than 10
> requests per second, you have a HUGE site. And commodity hardware
> can handle 1000's of requests per second, so "processing overhead" is
In VoIP world 50 requests per second is nothing BIG. Users begin
and terminate their sessions very often. The main reason is bad
link quality which results in many unsuccessful call attempts.
> "reduce code size" - Nonsense.
I think that code size matters, a lot. It is much easier to hold in
your head all the stuff if it takes less space. The same is with
> FreeRADIUS is modular, so that the only code you need to install is
> code you will use.
> The developers of FreeRADIUS have to maintain more code than most
> systems use, of course. But that's not rocket science.
Of course. And thank you for that. I am sure that FreeRADIUS is the
best tool for vast majority of use cases.
Just, please, Alan, don't take it so personally that there are other
RADIUS servers in the world. I was just offering a person something I
think is better for particular case. You should agree that there are
easier ways how to add non GPLed code to the server than the ways
offered by FreeRADIUS.
You should take a look at openradius.org I really like the idea when
RADIUS server communicates with modules through pipes.
More information about the Freeradius-Devel