[RADIATOR] DEBUG logging oddities
hvn at open.com.au
Thu Feb 18 05:37:30 CST 2016
On 18.2.2016 12.40, Karl Gaissmaier wrote:
> no official solution or ACK for this problem til now :-(
Huh, almost a week already. I have no official solution, but I can tell
what we have been up to recently. The virtualisation work we have done
has brought up similar requirements as what you describe. Don't hesitate
to let us if you have comments on this.
There are the main two enhancements for logging in Radiator:
1. Message log for received and sent messages
2. Id that binds together at authentication and accounting in log
messages, including multiround authentication such as EAP.
I think 1. would be what you need. You could use INFO level logging and
use a specific logger to log the incoming and outgoing messages with as
much detail as needed.
In other words, the requests and responses and their attributes would be
available regardless of trace level and the rest of the logging.
2. means that the loggers, such as log to stdout, and their format
hooks, etc. can display and have access to an id that's the same for all
log messages that are related to each other. For example:
45e94fd0 Wed Feb 17 16:38:29 2016 876349: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 50172 ....
45e94fd0 Wed Feb 17 16:38:29 2016 878402: DEBUG: Access accepted for mikem
45e94fd0 Wed Feb 17 16:38:29 2016 878763: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 50172 ....
String 45e94fd0 could then be used to get all log messages related to
this authentication. The above is from stdout/file, but if you push logs
to e.g., InfluxDB, the id could be a separate field there allowing for
The goal is to have the id available over the authentication and
accounting session. This would mean that 45e94fd0 could be used to look
up all EAP requests and the subsequent accounting requests if it's an id
for an EAP authentication that has a related accounting session.
> Currently I use the following homebrew workaround to get debug messages
> with trace level 4 in private log clauses:
That's a good trick. Hopefully the above will make it unnecessary, though :)
> # Gimmick to trick &main::willLog
> # has an unnecessary processing component, I know, but ...
> <Log FILE>
> Trace 4
> Identifier NULL-LOGGER-GIMMICK
> Filename /dev/null
> # more global loggers for errors, warnings and notices:
> <Log FILE>
> Trace 2
> Identifier radiatorlog
> Filename %L/radiatorlog
> <Log SYSLOG>
> Trace 2
Heikki Vatiainen <hvn at open.com.au>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
More information about the radiator