(RADIATOR) Accessing radiator internals from a postauthhook?

[Hugh Irvine]

Hello Jeff -

I generally find the simplest thing to do is add Identifiers to my  
Client clauses (this can also be done with ClientListSQL).


<Client 1.1.1.1>
	Identifier BROKEN
	.....
</Client>

<Client 2.2.2.2>
	Identifier BROKEN
	.....
</Client>

<Client 3.3.3.3>
	Identifier NOT-BROKEN
	.....
</Client>

.....


Then your hook code can check the Identifier and do whatever:


# PostAuthHook

sub
{
     my $p = ${$_[0]};
     my $rp = ${$_[1]};
     my $handled = $_[2];
     my $reason = $_[3];

     my $clientIdentifier = $p->{Client}->{Identifier};

     return unless $clientIdentifier eq 'BROKEN';

     # do whatever

     .......

     return;
}


There are numerous examples in "goodies/hooks.txt".

And no there is no "description of the request object", per se, but  
you will see everything contained in the requests in a trace 4 debug.

Hope that helps.

regards

Hugh


On 20 Jan 2006, at 06:41, Jeff Wolfe wrote:

>
>
> I'm trying to work around a deficiency in the implementation of  
> RADIUS on some of our network hardware. In particular, several  
> vendors' switches do 802.1x just fine, but do not produce any  
> useful information in RADIUS accounting messages.
>
> To work around this problem, I would like to have a postauthhook  
> log certain information from an .1x access-request operation, but  
> only for certain NASes. Since <ClientListSQL> already imports  
> enough information for my code to discriminate between NASes, I  
> would like to access that information instead of going out and  
> hitting the SQL db for each authentication operation.
>
> So the logic would go:
>
> Postauthhook:
>
> 	Look up NAS
> 	
> 	if  br0ken
> 		 do additional logging
>       	else
> 		ignore.
>
>
> Unfortunately, the current TTLS eap_anon_hook isn't enough.. These  
> particular NASes either don't do RADIUS accounting, or only log  
> useful information like the EAP outer identity and  start time, so  
> there's nothing unique to tie the info in the access request with  
> the accounting packets.
>
> Actually, is there a description of the request object anywhere,  
> too? :)
> Once I get this stuff sorted out, I need to pull the relevant bits  
> out of the request packet.
>
> I've been over the manual once, but nothing jumped out at me.
>
> Thanks.
>
> -JEff
>
> --
> 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 read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
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.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


--
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.