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 radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.