Need help

[Abhinay Sinha]

Hi,

I am developing a billing package for ISPs. I am trying to use the
freeradius server, but my problem is that my database schemas are
complex and won't be working with the available modules.

That means I will have to develop a custom module for my software and
compile it with freeradius. My problem is that if I do that, it won't
be compatible with general RADIUS servers and I'll have to provide the
software with freeradius server and my module. So will it mean that
I'll have to keep my software GPL, since I am using and distributing
freeradius and also it contains mysql server, or can I distribute my
software commercially?

Kindly help me and tell me what can be done regarding the same?

Thanks in advance.

Abhinay

[Peter Nixon]

Post by Abhinay Sinha
Hi,
I am developing a billing package for ISPs. I am trying to use the
freeradius server, but my problem is that my database schemas are
complex and won't be working with the available modules.

Complex database structures can still be accommodated via database stored
procedures which are usually faster than sending multiple queries to a
database in any case.

Post by Abhinay Sinha
That means I will have to develop a custom module for my software and
compile it with freeradius. My problem is that if I do that, it won't
be compatible with general RADIUS servers and I'll have to provide the
software with freeradius server and my module. So will it mean that
I'll have to keep my software GPL

Yes

Post by Abhinay Sinha
, since I am using and distributing
freeradius and also it contains mysql server, or can I distribute my
software commercially?

Yes. You may of course sell the software, however under the terms of the GPL
you will of course have to make the source code to your module available
also.

Regards

[Valts Mazurs]

Hello.

To avoid GPLish stuff you could either develop Python or Perl module
for FreeRADIUS or just use RADIUS server which doesn't come with GPL
"goodies".
Since I am maintainer of BSDRadius project (http://www.bsdradius.org) I
suggest you to try it. BSDRadius provides quick and easy way how to
write additional modules in Python.
However there is also Openradius (http://www.openradius.org) which
allows to write external modules in any programming language.
Sorry guys but FreeRADIUS's support for external, Python and Perl
modules is not very bright at the moment.

Best regards,
Valts.

Post by Peter Nixon

Post by Abhinay Sinha
Hi,
I am developing a billing package for ISPs. I am trying to use the
freeradius server, but my problem is that my database schemas are
complex and won't be working with the available modules.

Complex database structures can still be accommodated via database
stored procedures which are usually faster than sending multiple
queries to a database in any case.

Post by Abhinay Sinha
That means I will have to develop a custom module for my software
and compile it with freeradius. My problem is that if I do that, it
won't be compatible with general RADIUS servers and I'll have to
provide the software with freeradius server and my module. So will
it mean that I'll have to keep my software GPL

Yes

Post by Abhinay Sinha
, since I am using and distributing
freeradius and also it contains mysql server, or can I distribute my
software commercially?

Yes. You may of course sell the software, however under the terms of
the GPL you will of course have to make the source code to your
module available also.
Regards

[Alan DeKok]

Post by Valts Mazurs
To avoid GPLish stuff you could either develop Python or Perl module
for FreeRADIUS or just use RADIUS server which doesn't come with GPL
"goodies".

If you're going to bash the server and direct people to your own
product, I suggest you unsubscribe.

Post by Valts Mazurs
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.

Post by Valts Mazurs
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.

Post by Valts Mazurs
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.

"reduce code size" - Nonsense.

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.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog

[Valts Mazurs]

I already had a suspicion that I would get reply to my previous email
really fast.

Post by Alan DeKok
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.

Post by Alan DeKok

Post by Valts Mazurs
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.

Post by Alan DeKok

Post by Valts Mazurs
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.

Post by Alan DeKok

Post by Valts Mazurs
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.

Post by Alan DeKok
"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.

Post by Alan DeKok
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.

[Frank Cusack]

Post by Valts Mazurs
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.

Sounds like sql_relay in FreeRADIUS.

-frank

[Valts Mazurs]

On Sun, 14 Jan 2007 14:26:17 -0800

Post by Frank Cusack

Post by Valts Mazurs
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.

Sounds like sql_relay in FreeRADIUS.

Thanks. I'll take a look.

Valts.

[Alan DeKok]

Post by Valts Mazurs
I already had a suspicion that I would get reply to my previous email
really fast.

That's what happens when you troll on a list.

Post by Valts Mazurs

Post by Alan DeKok
If you're going to bash the server and direct people to your own
product, I suggest you unsubscribe.

This is not the case.

Simple contradiction doesn't establish your point, or make mine not true.

Post by Valts Mazurs
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).

Hmm.. You're saying it's easier to write & support a complete RADIUS
server than to fix rlm_python. Right.

Post by Valts Mazurs
I am not going to redirect any FreeRADIUS user to my product.

So when you said people should use bsdradius, you were doing what,
exactly?

Post by Valts Mazurs
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.

Ah, yes. I'm being rude for asking you to follow common politeness.

Post by Valts Mazurs
In case of all known radius servers they become slow when there's
serious business logic implemented in the backend.

You've successfully optimized the backends by writing a BSD-licensed
server?

i.e. This response indicates that your web site claims about the need
for a fast, small server are B.S.

Post by Valts Mazurs
And what if
authorization requests had higher priority than the accounting ones?

You can do this with FreeRADIUS. Read the config files, and the
documentation for the "nice" command.

Post by Valts Mazurs
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.

It optimizes away robust accounting. That's a non-starter for anyone
who's basing a business on correct accounting.

FreeRADIUS won't be implementing this "feature" It can destroy a
business.

Post by Valts Mazurs
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.

Is that near the 1000's/s limit I said? Nope. Then why the B.S.
claims about the need for a fast & efficient server?

Post by Valts Mazurs

Post by Alan DeKok
"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.

Try using something called "structured programming". It helps.

Post by Valts Mazurs
Just, please, Alan, don't take it so personally that there are other
RADIUS servers in the world.

It's easier to dismiss my points by labelling me as taking it
"personally". It's harder to dismiss my points by arguing the facts.

Post by Valts Mazurs
P.S.
You should take a look at openradius.org I really like the idea when
RADIUS server communicates with modules through pipes.

Really? Wow... it's only been listed as another open source RADIUS
server on freeradius.org for what, 3-4 years now?

And the author of OpenRADIUS hasn't trolled in this list, either.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog

[Valts Mazurs]

On Sun, 14 Jan 2007 19:44:10 -0500

Post by Alan DeKok

Post by Valts Mazurs
I already had a suspicion that I would get reply to my previous email
really fast.

That's what happens when you troll on a list.

Post by Valts Mazurs

Post by Alan DeKok
If you're going to bash the server and direct people to your own
product, I suggest you unsubscribe.

This is not the case.

Simple contradiction doesn't establish your point, or make mine not true.

Post by Valts Mazurs
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).

Hmm.. You're saying it's easier to write & support a complete RADIUS
server than to fix rlm_python. Right.

Yes, it is. rlm_python was not the only problem.

Post by Alan DeKok

Post by Valts Mazurs
I am not going to redirect any FreeRADIUS user to my product.

So when you said people should use bsdradius, you were doing what,
exactly?

Hmmm... I suppose that the person who started this thread is not user
of any RADIUS server yet. If I was not the maintainer of that evil
BSDRadius project would you also call me a troll? I was just trying to
save some headache for particular person. There are easier ways how to
write non GPL modules for RADIUS server. This is my opinion whether I am
maintainer of any project at all or not.
BTW I recommended also Openradius but I haven't seen much activity from
your side regarding this fact. Is it considered less evil than
BSDRadius?

Post by Alan DeKok

Post by Valts Mazurs
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.

Ah, yes. I'm being rude for asking you to follow common politeness.

Post by Valts Mazurs
In case of all known radius servers they become slow when there's
serious business logic implemented in the backend.

You've successfully optimized the backends by writing a BSD-licensed
server?
i.e. This response indicates that your web site claims about the need
for a fast, small server are B.S.

Post by Valts Mazurs
And what if
authorization requests had higher priority than the accounting ones?

You can do this with FreeRADIUS. Read the config files, and the
documentation for the "nice" command.

Thank you for pointing to this feature. I'll take a look.

Post by Alan DeKok

Post by Valts Mazurs
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.

It optimizes away robust accounting. That's a non-starter for anyone
who's basing a business on correct accounting.
FreeRADIUS won't be implementing this "feature" It can destroy a
business.

I have completely different opinion regarding this feature. It can
help slow backends to appear faster for end users thus reducing
unneccessary usage of network bandwidth, cpu resources of radius server
etc., etc.
In real life it is a common situation that during peak hours multiple
cloned accounting stop messages are sent to radius server. Radius
server appears to send acct response too late to the client. In client
side it has to keep bunch of requests into the memory until it receives
accounting response.
If you need old good robust accounting, just don't enable this feature.
It is turned off by default.

Post by Alan DeKok

Post by Valts Mazurs
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.

Is that near the 1000's/s limit I said? Nope. Then why the B.S.
claims about the need for a fast & efficient server?

Post by Valts Mazurs

Post by Alan DeKok
"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.

Try using something called "structured programming". It helps.

Post by Valts Mazurs
Just, please, Alan, don't take it so personally that there are other
RADIUS servers in the world.

It's easier to dismiss my points by labelling me as taking it
"personally". It's harder to dismiss my points by arguing the facts.

Yeah, right. And it is so pleasant to try to dismiss my points calling
them as "B.S.", "nonsense" and ranting about how badly designed is
BSDRadius.
Why don't you take the ideas, opinions, needs of people and try to make
FreeRADIUS better? Because these are not your ideas? Or what? It would
be much better if you focused more to your own project instead of trying
to discredit other ones.

Post by Alan DeKok

Post by Valts Mazurs
P.S.
You should take a look at openradius.org I really like the idea when
RADIUS server communicates with modules through pipes.

Really? Wow... it's only been listed as another open source RADIUS
server on freeradius.org for what, 3-4 years now?

I was not talking about the project itself but about the FEATURE.

Post by Alan DeKok
And the author of OpenRADIUS hasn't trolled in this list, either.

I suppose that he is a cool person.


Regards,
Valts.

[Alan DeKok]

Post by Valts Mazurs
Hmmm... I suppose that the person who started this thread is not user
of any RADIUS server yet. If I was not the maintainer of that evil
BSDRadius

Stop pretending it's personal. It's not.

Post by Valts Mazurs
project would you also call me a troll?

Yes.

Post by Valts Mazurs

Post by Alan DeKok
FreeRADIUS won't be implementing this "feature" It can destroy a
business.

I have completely different opinion regarding this feature. It can
help slow backends to appear faster for end users thus reducing
unneccessary usage of network bandwidth, cpu resources of radius server
etc., etc.

Why not just implement a robust and scalable solution?

Post by Valts Mazurs
Yeah, right. And it is so pleasant to try to dismiss my points calling
them as "B.S.", "nonsense" and ranting about how badly designed is
BSDRadius.

You're pretending it's personal again. Facts are not "rants", no
matter how often you claim they are.

Post by Valts Mazurs
Why don't you take the ideas, opinions, needs of people and try to make
FreeRADIUS better?

Stop being a troll. If you've spent any time reading the lists, you
know your comments are wrong.

Post by Valts Mazurs
Because these are not your ideas? Or what? It would
be much better if you focused more to your own project instead of trying
to discredit other ones.

I post hundreds of messages helping people, and making FreeRADIUS
better. You say nothing. I post one message pointing out your troll,
and you get annoyed that I should "focus more to your own project".

I think you're over-reacting. A lot.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog

[Peter Nixon]

Post by Valts Mazurs
I already had a suspicion that I would get reply to my previous email
really fast.

Post by Alan DeKok
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.

Post by Alan DeKok

Post by Valts Mazurs
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.

Post by Alan DeKok

Post by Valts Mazurs
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.

If the backend is slow there is not alot the radius server can do about...

Post by Valts Mazurs
And what if authorization requests had higher priority than the accounting

ones?

This is possible in FreeRADIUS. I run separate sql modules for accounting and
auth with different DB usernames. You may then assign different numbers of
sockets to them, fail them over differently (even use sql_log for accounting
if you wish) and assign different priorities to the queries on the database
side (if your DB supports such options), or different physical machines if
you wish.. (Auth queries can run on a read only slave mirror of the master
DB for example)

Post by Valts Mazurs
And what if accounting response could be sent even before processing
the request?

This is possible in FreeRADIUS.

Post by Valts Mazurs
It is a major speedup. It is optimization in design, not
in several parts of code.

Post by Alan DeKok

Post by Valts Mazurs
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.

Yes. You are correct. I have happily put 1000 requests per second through
FreeRADIUS. It all depends on a properly setup backend..

Post by Valts Mazurs

Post by Alan DeKok
"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.

Post by Alan DeKok
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.

[Valts Mazurs]

This post might be inappropriate. Click to display it.

[Alan DeKok]

Post by Valts Mazurs
What I mean is that I would like to process all authorization requests
before accounting requests. That means if there are any auth requests
in queue, working thread takes the youngest auth request. The logic is
that it is more reasonable to give answer to the youngest auth request
and deliver the answer in time. Older auth requests might be already
unworthy and there is no point of processing them.
Accounting requests may wait into the queue until they are processed.

a) run a radius server for authentication
b) run a different radius server for accounting
c) "nice +15" the accounting server.

Why write code when you can use standard Unix utilities? This won't
do *exactly* what you want, but it will come close.

Post by Valts Mazurs

Post by Peter Nixon

Post by Valts Mazurs
And what if accounting response could be sent even before processing
the request?

This is possible in FreeRADIUS.

1) incoming acct request
2) send acct response
3) pass request for modules to process
4) see if processing was ok
5) log the request to special file if processing failed

In a word: No.

It's possible, but it's wrong.

A better approach is to use rlm_sql_log, which is a fast & cheap way
to log the SQL inserts. A perl script can then run the inserts when the
system isn't busy.

Your approach involves the possibility of losing data, and still
writes to a "special file". Why not just write to a "special file" all
of the time?

Post by Valts Mazurs
I'm not telling that FreeRADIUS would be slow. It really is not.
Simply... there are ways how to help slow backends appear as not so
slow for end user.

Decouple the backend from the front end. This is a standard way to
make systems more robust, scalable, and easy to maintain.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog

[Valts Mazurs]

On Mon, 15 Jan 2007 15:51:36 +0100

Post by Alan DeKok

Post by Valts Mazurs
What I mean is that I would like to process all authorization requests
before accounting requests. That means if there are any auth requests
in queue, working thread takes the youngest auth request. The logic is
that it is more reasonable to give answer to the youngest auth request
and deliver the answer in time. Older auth requests might be already
unworthy and there is no point of processing them.
Accounting requests may wait into the queue until they are processed.

a) run a radius server for authentication
b) run a different radius server for accounting
c) "nice +15" the accounting server.
Why write code when you can use standard Unix utilities? This won't
do *exactly* what you want, but it will come close.

In this case I would like to exactly as I want. It seems the best
possible approach for me. I might be wrong, of course.

Post by Alan DeKok

Post by Valts Mazurs

Post by Peter Nixon

Post by Valts Mazurs
And what if accounting response could be sent even before processing
the request?

This is possible in FreeRADIUS.

1) incoming acct request
2) send acct response
3) pass request for modules to process
4) see if processing was ok
5) log the request to special file if processing failed

In a word: No.
It's possible, but it's wrong.
A better approach is to use rlm_sql_log, which is a fast & cheap way
to log the SQL inserts. A perl script can then run the inserts when the
system isn't busy.

It is another way how to do accounting. But it comes with other
problems. I chose some risc for getting more comfort.

Post by Alan DeKok
Your approach involves the possibility of losing data, and still
writes to a "special file". Why not just write to a "special file" all
of the time?

It writes to "special file" only failed requests. List of failed
requests is helpful for later debugging.
Of course, this feature comes with some risc because disks might get
full or just get out of order. RADIUS server then would happily accept
incoming acct requests and respond with acct response as if it was
operating normally. So, don't enable this feature unless you are sure
that you need it.

Post by Alan DeKok

Post by Valts Mazurs
I'm not telling that FreeRADIUS would be slow. It really is not.
Simply... there are ways how to help slow backends appear as not so
slow for end user.

Decouple the backend from the front end. This is a standard way to
make systems more robust, scalable, and easy to maintain.

Yes, of course. But there is more what can be done :)

Valts.

[Peter Nixon]

Post by Valts Mazurs
On Mon, 15 Jan 2007 11:54:46 +0200

Post by Peter Nixon

Post by Valts Mazurs
And what if authorization requests had higher priority than the accounting

ones?
This is possible in FreeRADIUS. I run separate sql modules for
accounting and auth with different DB usernames. You may then assign
different numbers of sockets to them, fail them over differently (even
use sql_log for accounting if you wish) and assign different priorities
to the queries on the database side (if your DB supports such options),
or different physical machines if you wish.. (Auth queries can run on a
read only slave mirror of the master DB for example)

What I mean is that I would like to process all authorization requests
before accounting requests. That means if there are any auth requests
in queue, working thread takes the youngest auth request. The logic is
that it is more reasonable to give answer to the youngest auth request
and deliver the answer in time. Older auth requests might be already
unworthy and there is no point of processing them.

I suspect that this give similars result as the reply caching in FreeRADIUS
("cleanup_delay" etc). What happens to "older" requests that are still in
the queue? Do you expire them after some time? Reply to them eventiually or
keep track of duplicates?

Post by Valts Mazurs
Accounting requests may wait into the queue until they are processed.

Post by Peter Nixon

Post by Valts Mazurs
And what if accounting response could be sent even before processing
the request?

This is possible in FreeRADIUS.

1) incoming acct request
2) send acct response
3) pass request for modules to process
4) see if processing was ok
5) log the request to special file if processing failed
If it is possible in FreeRADIUS I will consider it as my fault that I
have not found this functionality by myself.

ok. Basically the way you handle this with FreeRADIUS is:

* you use the sql (or ldap) module to directly service Authentication
requests. All Authentication requests are handled as fast as the backend can
respond.

* you pass all accounting requests to either the sqllog module OR a specially
configured detail module. (I prefer the detail method, and I am going
describe that, but the concept and result is effectively the same.)

* The detail module writes the accounting request to an on disk spool (on a
big system this should be a dedicated disk so that speed is not effected by
other system utilization) and sends accounting response.

* A second copy of FreeRADIUS configured in "radrelay" mode lazily reads this
spool from disk and processes it into your accounting database. (As I
mentioned in a previous email, your accounting database may be a Master
while your Auth database is a read only slave if you wish to split up the
load between multiple machines)

This is superior to your method in that it is not possible to lose an
accounting record after having already sent an accounting response. If your
radius server crashes/disappears your NASes will think that the accounting
packet has been logged and forget about it, mine will resend it to my
secondary RADIUS server and the packet will not be lost.

While there IS a difference in speed between writing to an on-disk spool and
your method (in memory queue) our method is "correct" and a dedicated disk
(or raid set) is more than fast enough to keep up with thousands of requests
per second. (I haven't benchmarked it recently but I suspect we are in 100K
requests per second territory here depending on disk spindle speed,
filesystem and cache configuration)

This could be possibly improved by adding an in memory authentication queue
to make sure that radiusd never tries to send more than the maximum number
of sql sockets to the database backend at one time, however this only buys
you a small advantage (given that we are already queuing acct) in that if
the request is delayed for more than 1 second (this is typically
configurable on the NAS of course) the NAS will resend the Auth request to
the secondary RADIUS. This results in duplicated load on the backend
(assuming its shared, although it could be a second slave database) which
makes the problem even worse.
Basically a queue of more than a second (or the timeout configured on your
NAS) is worse than sending an Authentication reject to a couple of users as
the whole thing just snowballs! An Auth queue only helps in the case where
you have a huge peak of requests that cannot be serviced simultaneously but
CAN be serviced quicker than the configurable timeout of your NAS. If you
continually have a deep queue then you need to increase the speed of your
backend.

Post by Valts Mazurs

Post by Peter Nixon

Post by Valts Mazurs
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.

Yes. You are correct. I have happily put 1000 requests per second
through FreeRADIUS. It all depends on a properly setup backend..

I'm not telling that FreeRADIUS would be slow. It really is not.
Simply... there are ways how to help slow backends appear as not so
slow for end user.

Yes. There are _some_ tricks you can play to try and deal with restart
conditions (When one or more NAS reset a group of interfaces due to an error
condition or reboot completely) more effectively. In the end however if your
Authentication backend cannot clear the load backlog within a second or so
you are lost anyway. Accounting of course can be handled lazily, as I
explain above.

I would be interested to see you run a benchmark to show that your algorithm
for dealing with newest Auth request first is actually a performance gain in
a high load environment. (I suspect that it will make very little difference
compared with out caching system) If it does make a considerable difference,
then of course we would consider adding a similar feature to FreeRADIUS.
(ie. Please prove to us that what you have done is actually better!)

Regarding your accounting optimization, it would be trivial for us to do the
same thing but it would be wrong as it introduces the possibility of lost
packets. (While there ARE companies out there that can enough accounting
packets to saturate a single disk, they can afford to purchase a raid set,
and they DO care about doing everything possible to not losing data!)

Cheers

[Alan DeKok]

Post by Peter Nixon
While there IS a difference in speed between writing to an on-disk spool and
your method (in memory queue) our method is "correct" and a dedicated disk
(or raid set) is more than fast enough to keep up with thousands of requests
per second. (I haven't benchmarked it recently but I suspect we are in 100K
requests per second territory here depending on disk spindle speed,
filesystem and cache configuration)

To put it another way, if a system doesn't have to be correct, you can
make it run as fast as you want.

Never underestimate that speed of a process that does "exit 0". It's
not correct, but *man* is it fast!

Post by Peter Nixon
Basically a queue of more than a second (or the timeout configured on your
NAS) is worse than sending an Authentication reject to a couple of users as
the whole thing just snowballs! An Auth queue only helps in the case where
you have a huge peak of requests that cannot be serviced simultaneously but
CAN be serviced quicker than the configurable timeout of your NAS. If you
continually have a deep queue then you need to increase the speed of your
backend.

The CVS head tries to be a little smarter. The priority is:

a) replies from proxies (i.e. ongoing requests)
b) requests with State attribute (i.e. EAP)
c) everything else.

This means that people get to finish their authentications.

Post by Peter Nixon
I would be interested to see you run a benchmark to show that your algorithm
for dealing with newest Auth request first is actually a performance gain in
a high load environment. (I suspect that it will make very little difference
compared with out caching system) If it does make a considerable difference,
then of course we would consider adding a similar feature to FreeRADIUS.
(ie. Please prove to us that what you have done is actually better!)

Dealing the the newest request first is *bad*. FreeRADIUS puts
requests into a queue, and discards requests from the queue if it
determines that they've timed out, or that the NAS has given up on them.

Priority (or time-based) queues stabilize networks. FILO queues do not.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog

[Peter Nixon]

Post by Peter Nixon
I would be interested to see you run a benchmark to show that your
algorithm for dealing with newest Auth request first is actually a
performance gain in a high load environment. (I suspect that it will
make very little difference compared with out caching system) If it does
make a considerable difference, then of course we would consider adding
a similar feature to FreeRADIUS. (ie. Please prove to us that what you
have done is actually better!)

  Dealing the the newest request first is *bad*.  FreeRADIUS puts
requests into a queue, and discards requests from the queue if it
determines that they've timed out, or that the NAS has given up on them.
  Priority (or time-based) queues stabilize networks.  FILO queues do not.

Yeah. It seems to me that a FILO queue on a AAA server could lead to some
very difficult to debug network behavior...

[Valts Mazurs]

On Mon, 15 Jan 2007 22:41:55 +0200

Post by Peter Nixon

Post by Peter Nixon
I would be interested to see you run a benchmark to show that your
algorithm for dealing with newest Auth request first is actually a
performance gain in a high load environment. (I suspect that it will
make very little difference compared with out caching system) If it does
make a considerable difference, then of course we would consider adding
a similar feature to FreeRADIUS. (ie. Please prove to us that what you
have done is actually better!)

  Dealing the the newest request first is *bad*.  FreeRADIUS puts
requests into a queue, and discards requests from the queue if it
determines that they've timed out, or that the NAS has given up on them.
  Priority (or time-based) queues stabilize networks.  FILO queues do not.

Yeah. It seems to me that a FILO queue on a AAA server could lead to some
very difficult to debug network behavior...

Your opinion seems to be reasonable. Although BSDRadius has timeout for
auth packets I think that there is place for some experiments. FILO vs
FIFO. Expiration time for auth packets is here to stay, of course.

Valts.

[Frank Cusack]

Post by Valts Mazurs
What I mean is that I would like to process all authorization requests
before accounting requests. That means if there are any auth requests
in queue, working thread takes the youngest auth request. The logic is
that it is more reasonable to give answer to the youngest auth request
and deliver the answer in time. Older auth requests might be already
unworthy and there is no point of processing them.

That's a pretty bad method. Under a dos attack, where dos traffic
is substantially greater than good traffic, real auths will tend
to get dropped in favor of processing attack auths. It's better
to process them in order, short-circuiting the hard work by testing the
age of the request before going on to do any work, including sending
a response at all. You could even set up a new queue every second
and simply drop all requests older than 3s without even looking at
the timestamps on them. (Although you'd probably want to use 12s
as the cutoff, to allow for retransmission. That way the age of
the packet is established from the first transmission.)

FreeRADIUS essentially does this.

-frank

[Valts Mazurs]

On Mon, 15 Jan 2007 09:33:29 -0800

Post by Frank Cusack

Post by Valts Mazurs
What I mean is that I would like to process all authorization requests
before accounting requests. That means if there are any auth requests
in queue, working thread takes the youngest auth request. The logic is
that it is more reasonable to give answer to the youngest auth request
and deliver the answer in time. Older auth requests might be already
unworthy and there is no point of processing them.

That's a pretty bad method. Under a dos attack, where dos traffic
is substantially greater than good traffic, real auths will tend
to get dropped in favor of processing attack auths. It's better
to process them in order, short-circuiting the hard work by testing the
age of the request before going on to do any work, including sending
a response at all. You could even set up a new queue every second
and simply drop all requests older than 3s without even looking at
the timestamps on them. (Although you'd probably want to use 12s
as the cutoff, to allow for retransmission. That way the age of
the packet is established from the first transmission.)

In my implementation requests from unauthorized clients (as in
FreeRADIUS - whose IP address is not found in clients.conf) are not put
into the queue at all. I decided to ignore them completely. It seems
safer for DOS attackers. But anyway... if there are 1'000'000 zombed
windows pc's attacking the site, nothing can be done in RADIUS server
software to prevent it.

Valts.

[Alan DeKok]

Post by Valts Mazurs
In my implementation requests from unauthorized clients (as in
FreeRADIUS - whose IP address is not found in clients.conf) are not put
into the queue at all. I decided to ignore them completely.

That's what the RFC's say, because it's a good idea. But look at the
following scenario, which actually happened in a FreeRADIUS installation.

Something went wrong in a customer site, and they continually tried to
login. As soon as they logged in, they logged off again. The result
was a DoS from a *known* client.

Using a FILO queue means that it's likely that most of the "new"
requests are from the broken user, so *good* users get blocked. A FIFO
queue isn't a whole lot better, but FreeRADIUS also limits the queue
size. So the bad user is more likely to get blocked than good users,
and if users wait long enough, they get on the net.

Again, your ideas are interesting, but not realistic. Many of the
FreeRADIUS developers have been working with RADIUS for over a decade
(nearly 15 years for some), and there are often good reasons why
"optimizations" are not done.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog

[Valts Mazurs]

On Tue, 16 Jan 2007 15:50:28 +0100

Post by Alan DeKok

Post by Valts Mazurs
In my implementation requests from unauthorized clients (as in
FreeRADIUS - whose IP address is not found in clients.conf) are not put
into the queue at all. I decided to ignore them completely.

That's what the RFC's say, because it's a good idea. But look at the
following scenario, which actually happened in a FreeRADIUS installation.
Something went wrong in a customer site, and they continually tried to
login. As soon as they logged in, they logged off again. The result
was a DoS from a *known* client.

I haven't had such scenario yet :)

Post by Alan DeKok
Using a FILO queue means that it's likely that most of the "new"
requests are from the broken user, so *good* users get blocked. A FIFO
queue isn't a whole lot better, but FreeRADIUS also limits the queue
size. So the bad user is more likely to get blocked than good users,
and if users wait long enough, they get on the net.

Queue size is limited also in my implementation. However I don't see
clear evidence that FIFO is definately better than FILO. In both cases
there is lot of garbage between "normal" auth requests, and that garbage
has to be processed. The server anyway will be busy to get those
requests done. It seems for me that it is a greater chance that "normal"
request will be answered in time if it is taken from the fresh ones.

Post by Alan DeKok
Again, your ideas are interesting, but not realistic. Many of the
FreeRADIUS developers have been working with RADIUS for over a decade
(nearly 15 years for some), and there are often good reasons why
"optimizations" are not done.

I don't push anyone to use these optimizations. This is just how my
implementation works.
Btw, BSDRadius is not "ready" yet. It has to survive some serious tests
before I can call it BSDRadius 1.0

I really appreciate your experience and critics. But there are real
business requirements and needs why I have made such decisions. The
time will show if I am totally wrong or not :)

Valts.

[Abhinay Sinha]

Hi everybody and thanks for so big response for my thread.

Looks like I started a heated debate, but that was not my idea. I just
wanted to get my software working with any and all RADIUS servers.

Initially I developed a separate AAA module which did not confirm to
RADIUS protocol and was entirely written differently. The problem was
that I was not happy with the results and then I heard of RADIUS and
tried my hands on that. So it was true that I was not a user of any
RADIUS server beforehand as said in a post.

Thanks everybody for helping me in this. I guess I will write a module
for freeradius, GPL it, and will send it to the community for
inclusion if they like it.

I can then keep my NAS server closed. :)

Will it be OK then?

-Abhinay

[Frank Cusack]

Post by Abhinay Sinha
Thanks everybody for helping me in this. I guess I will write a module
for freeradius, GPL it, and will send it to the community for
inclusion if they like it.
I can then keep my NAS server closed. :)
Will it be OK then?

Unfortunately not.

The GPL doesn't require that you send the original authors your derived
code. It requires that if YOU DISTRIBUTE a binary of the GPL code or
derived code, that YOU DISTRIBUTE the source code at a reasonable cost
to THOSE PEOPLE that you have distributed the binary to, and without
restriction (such as limiting them to not be allowed to redistribute)
except that they may not apply additional restrictions.

That is, if you create a NAS server which runs freeradius, or code
derived from freeradius, you must make the freeradius and derived
code available to the folks whome you sell (or give away) your NAS
server to.

But since you're willing to send your module to "us", it shouldn't
be difficult for you to simply make it available yourself. You don't
need to publish it to "the world", just to those who obtain your
NAS server (if that makes a difference).

Note that only the freeradius (or other GPL parts) of your NAS server
need to be redistributed as source. For example if you create a
configuration GUI that isn't derived from some GPL source, you need
not distribute source code for that, even if it modifies configuration
for GPL software (ie, freeradius).

-frank

[Abhinay Sinha]

Post by Frank Cusack

Post by Abhinay Sinha
Thanks everybody for helping me in this. I guess I will write a module
for freeradius, GPL it, and will send it to the community for
inclusion if they like it.
I can then keep my NAS server closed. :)
Will it be OK then?

Unfortunately not.
The GPL doesn't require that you send the original authors your derived
code. It requires that if YOU DISTRIBUTE a binary of the GPL code or
derived code, that YOU DISTRIBUTE the source code at a reasonable cost
to THOSE PEOPLE that you have distributed the binary to, and without
restriction (such as limiting them to not be allowed to redistribute)
except that they may not apply additional restrictions.
That is, if you create a NAS server which runs freeradius, or code
derived from freeradius, you must make the freeradius and derived
code available to the folks whome you sell (or give away) your NAS
server to.
But since you're willing to send your module to "us", it shouldn't
be difficult for you to simply make it available yourself. You don't
need to publish it to "the world", just to those who obtain your
NAS server (if that makes a difference).
Note that only the freeradius (or other GPL parts) of your NAS server
need to be redistributed as source. For example if you create a
configuration GUI that isn't derived from some GPL source, you need
not distribute source code for that, even if it modifies configuration
for GPL software (ie, freeradius).
-frank
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

Thanks :)

[Frank Cusack]

Post by Valts Mazurs
On Mon, 15 Jan 2007 09:33:29 -0800

Post by Frank Cusack

Post by Valts Mazurs
What I mean is that I would like to process all authorization requests
before accounting requests. That means if there are any auth requests
in queue, working thread takes the youngest auth request. The logic is
that it is more reasonable to give answer to the youngest auth request
and deliver the answer in time. Older auth requests might be already
unworthy and there is no point of processing them.

That's a pretty bad method. Under a dos attack, where dos traffic
is substantially greater than good traffic, real auths will tend
to get dropped in favor of processing attack auths. It's better
to process them in order, short-circuiting the hard work by testing the
age of the request before going on to do any work, including sending
a response at all. You could even set up a new queue every second
and simply drop all requests older than 3s without even looking at
the timestamps on them. (Although you'd probably want to use 12s
as the cutoff, to allow for retransmission. That way the age of
the packet is established from the first transmission.)

In my implementation requests from unauthorized clients (as in
FreeRADIUS - whose IP address is not found in clients.conf) are not put
into the queue at all. I decided to ignore them completely. It seems
safer for DOS attackers. But anyway... if there are 1'000'000 zombed
windows pc's attacking the site, nothing can be done in RADIUS server
software to prevent it.

That has nothing to do with what I'm talking about. I am only talking
about requests that get queued for processing, not requests from
unauthorized clients. I thought that was obvious.

Post by Valts Mazurs
On Tue, 16 Jan 2007 15:50:28 +0100

Post by Frank Cusack

Post by Valts Mazurs
In my implementation requests from unauthorized clients (as in
FreeRADIUS - whose IP address is not found in clients.conf) are not put
into the queue at all. I decided to ignore them completely.

That's what the RFC's say, because it's a good idea. But look at the
following scenario, which actually happened in a FreeRADIUS installation.
Something went wrong in a customer site, and they continually tried to
login. As soon as they logged in, they logged off again. The result
was a DoS from a *known* client.

I haven't had such scenario yet :)

Ah, since you haven't experienced it, you don't have enough forward
vision to handle it? Sounds like some great software you have there.

Sorry, I don't really mean to be so caustic, but I hope it does make
my point.

Post by Valts Mazurs

Post by Frank Cusack
Using a FILO queue means that it's likely that most of the "new"
requests are from the broken user, so *good* users get blocked. A FIFO
queue isn't a whole lot better, but FreeRADIUS also limits the queue
size. So the bad user is more likely to get blocked than good users,
and if users wait long enough, they get on the net.

Queue size is limited also in my implementation. However I don't see
clear evidence that FIFO is definately better than FILO. In both cases
there is lot of garbage between "normal" auth requests, and that garbage
has to be processed. The server anyway will be busy to get those
requests done. It seems for me that it is a greater chance that "normal"
request will be answered in time if it is taken from the fresh ones.

It is clear (seems obvious to me) that answering requests in order is
the best approach. If you're so busy that you are dropping requests
for sitting on the queue too long, handling the first request makes
you handle that much more retransmission traffic, and pushes old
requests into the bin thus causing the client to present a new request,
again increasing the load.

Handling the oldest packet STILL gives you the chance to handle that
newer packet even under load.

This is pretty well understood in the network -- are you aware of any
routers that deliver packets out of order when output queues get busy?
(Sometimes they do, but under priority criteria, not FILO.) That would
be a disaster.

-frank

[Alexander Schrab]

Post by Alan DeKok
But you're right, that's too much work. I'll update the
"digest" module so that that much work is no longer necessary.

Speaking of which, has anyone any updated info on the RFC4590 status?


/Alex

[Alan DeKok]

Post by Alexander Schrab

Post by Alan DeKok
But you're right, that's too much work. I'll update the
"digest" module so that that much work is no longer necessary.

Speaking of which, has anyone any updated info on the RFC4590 status?

I think the updated document is in last call. It should be issued
within a few weeks, maybe a month.

Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog