I already had a suspicion that I would get reply to my previous email really fast. 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 Python. 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 negligible.
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 screen.
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. Valts. P.S. You should take a look at openradius.org I really like the idea when RADIUS server communicates with modules through pipes.