Hi Heikki,

Am 31.08.2017 um 19:53 schrieb Heikki Vatiainen:
On 14.08.2017 17:17, Karl Gaissmaier wrote:

we need it especially for RADSEC (Server AND AuthBy) because we can't decode the sniffered but encrypted RADSEC traffic without the TLS session keys.

Yes, that certainly helps. There's now an update in Radiator 4.19 patches that adds support for logging outgoing RadSec messages with MessageLog.

great! I'll test it tomorrow.

By the way, sorry, one more feature wish:

You know, MessageLogFILE unconditionally logs *every* recv/sent RADIUS packet, this fills the disks very quickly and gets unhandy for further debug processing.

What do you think about a LogSkipHook in MessageLogFILE?

I'm in the progress to test this little piece of code:

%Radius::MessageLogFILE::ConfigKeywords =
 'LogSkipHook' =>
'Specifies an optional Perl hook that will be run for each log message when defined. If it returns true the message is skipped and not logged. By default no Hook is defined and all messages are logged.',

and later in MessageLogFILE.pm

# Log a RADIUS message to a file
sub log_radius_msg
    my ($self, $p, $from_ip, $from_port, $to_ip, $to_port, $data) = @_;

    # skip this message by user request
    if (defined $self->{LogSkipHook})
        return if $self->runHook('LogSkipHook', $p, ... );

the same for

sub log_diameter_msg
    my ($self, $m, $from_ip, $from_port, $to_ip, $to_port, $data) = @_;

    # skip this message by user request
    if (defined $self->{LogSkipHook})
        return if $self->runHook('LogSkipHook', $m, ...);

maybe we just feed $p (or $m in case of diameter) to the hook or even the socket params, maybe it's useful for the hook programmer.

This would be handy to decide what gets logged programmatically, based on the RADIUS packet for elaborated Radiator admins.

What do you think?

Best Regards
radiator mailing list

Reply via email to