Hello John -
Thanks for the update.
BTW - you can also use the incoming request packet as a temporary scratch-pad area, which avoids you having to worry about undefined attributes in the reply packet (as the packet is just deleted after processing).
regards
Hugh
On Friday, Aug 22, 2003, at 00:56 Australia/Melbourne, John McFadden wrote:
There may be better ways but the good news is I did get around my authenication sql logging issue.
I was able to get around the mac to userid tracking problem by adding temp attributes to the reply in the inner authentication then
using them in the outer authentication to do the acutal logging.
ie:
The inner authentication (posauth code) sets an action attribute to tell the outer authenication to put out a log, plus a couple of attributes to populate the log.
The outer authentication (postauth code) checks the action attribute and if set to log gets the other attributes and does the sql insert.
In either case it deletes the temp attributes.
Therefore the final pass through the outer authentication which has the mac can do the log with all the required attributes.
Regards John McFadden
=== 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 95/98/2000, NT, 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.
