Hello Claudio -
For the first case it isn't quite so simple, therefore it is probably easier to use a two-stage proxy approach with the first stage employing an AuthBy ROUNDROBIN clause to distribute requests evenly to a number of targets. Each target can then be configured with AuthBy INTERNAL clauses to do whatever you want, ie ACCEPT, REJECT, IGNORE, so if you have three targets you can simulate 33% by having one target IGNORE.
For the second case, yes you can use a PostAuthHook and alter the reply to IGNORE.
The hook code would look something like this:
sub
{
my $p = ${$_[0]}; # original request packet
my $rp = ${$_[1]}; # reply packet to NAS
my $handled = $_[2]; # flag to indicate ACCEPT, REJECT or IGNORE # Only deal with authentication requests
my $code = $p->code();
return unless $code eq 'Access-Request'; if (.....)
{
$$handled = $main::IGNORE;
.....
}
return;
}regards
Hugh
On Monday, Sep 29, 2003, at 09:40 Australia/Melbourne, Claudio Lapidus wrote:
Hello all,
Now this may sound a little crazy, but...
We're finishing a development for a billing application. In order to
ascertain how resilient it is to network faults, we're trying to setup a
test scenario with known failure rates at the Radius packet transmission
stages. The basic idea is to setup a PreClientHook that drops a configured
percentage of the incoming packets, something like
sub { my $p = ${$_[0]}; my $r = rand;
if ($r < 0.3) { # discards 30% of incoming traffic # # discard packet here, perhaps log it # } }
so the question is how to instruct the hook to discard the packet completely, preventing further processing?
Second one: to implement the same 'induced error' for the reply side, I
think PostAuthHook is perhaps the proper place, to simulate the case where
the response get lost after the transaction was correctly registered at the
server side. The point here is if it is possible to intercept the reply in
some way, before it gets transmitted.
As a side note, I try to use these hooks in order to alter the server
configuration at the least possible degree. I'm aware that it may be simpler
to alter the packet in some way as to force a particular handler, etc., but
I'd prefer to simply discard the whole packet altogether.
Comments? cl. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening?
-- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
=== Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
