Re: [RADIATOR] LogSkipHook for MessageLog
On 4.9.2017 15.05, Heikki Vatiainen wrote: On 1.9.2017 16.48, Karl Gaissmaier wrote: See the attached patch, this would be very helpful for debugging sporadically occurring errors. I would be glad if you could accept this feature request or patch. We'll take a look at how to fit this in. It's probably better to have in the parent class and be more aware of direction (in/out) and protocol so that we can support TACACS+ too. However, I'd say it would be close to what you had in the patch. Changes based on your ideas with some additional enhancements for MessageLog functionality are now in 4.19 patches. Radius and RadSec are now different "protocols" in the sense that message log for Radius no longer logs RadSec messages too. If you want to just log radsec, you can configure GlobalMessageLog for 'radsec' protocol and it won't log Radius messages that use UDP transport. The hook is name LogSelectHook with the idea that the hook must return true if the message should be logged. See the update configuration sample in goodies/logformat.cfg Thanks, Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. ___ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] LogSkipHook for MessageLog
Hi Heikki,
Am 04.09.2017 um 14:05 schrieb Heikki Vatiainen:
On 1.9.2017 16.48, Karl Gaissmaier wrote:
What do you think about a LogSkipHook in MessageLogFILE?
Tuure mentioned that similar functionality (ACL to match what gets
captured) on certain devices has been very useful. The hook would also
allow trigger capture based on attributes since it can access the
message contents too.
yep
See the attached patch, this would be very helpful for debugging
sporadically occurring errors.
I would be glad if you could accept this feature request or patch.
We'll take a look at how to fit this in. It's probably better to have
in the parent class and be more aware of direction (in/out) and
protocol so that we can support TACACS+ too. However, I'd say it would
be close to what you had in the patch.
Sure, the way you implement the skip hook is truly best in your hands!
Btw, I named it LogSkipHook and not MessageLogSkipHook because a
LogSkipHook would also be very useful in some Log Modules.
I you logg in DEBUG mode, the amount is overwhelming, to choose
programmatically what messages get skipped would be fine.
...
And, you know, it was just a quick and dirty solution for me, now I was
able to debug the long running nasty behavior of this messages:
WARNING: 1XX.1YY.75.138 Unknown reply received in AuthRADSEC for
request 51157 from .dfn.de (1XX.1YY.75.138:2083)
in wireshark.
Solution:
You log just the extended Id from $fp proxied to the upstream, since the
original packet $p is no longer in pending state.
But when you logg the noreply for $p seconds before, you logg just the
identifier of the original $p and NOT the corresponding proxied ext Id
of $fp, therefore I could not match the late responsive packet to the
originator!
Now I've understood the reason I wrote a NoReplyHook in AuthBy RADSEC in
order to be able to match both logg message:
NoReplyHook sub { \
my ($p, $fp) = (${$_[0]}, ${$_[1]}); \
my $psid = Radius::AuthRADSEC->get_psid($fp); \
main::log($main::LOG_WARNING,"AuthRADSEC: No
reply for $p->{OriginalUserName} id=($p->{Identifier}),
proxy-ext-Id:($psid)"); \
}
Maybe you should patch also the Logg message
sub failed
{
my ($self, $host, $fp, $p) = @_;
my $msg = "AuthRADSEC: No reply from $host->{Host}:$host->{Port}
for $p->{OriginalUserName} ($p->{Identifier})";
to logg the corresponding $fp Extended Idtoo, then we need no Hook to
match the reason for the
'Unknown reply received in AuthRADSEC ' logg messages,
Best Regards and thanks again for maintaining and improving RADIATOR!
Charly
--
Karl Gaissmaier
Universität Ulm
kiz, Kommunikations und Informationszentrum
89069 Ulm
Tel.: 49(0)731/50-22499
Fax : 49(0)731/50-12-22499
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] LogSkipHook for MessageLog
On 1.9.2017 16.48, Karl Gaissmaier wrote: What do you think about a LogSkipHook in MessageLogFILE? Tuure mentioned that similar functionality (ACL to match what gets captured) on certain devices has been very useful. The hook would also allow trigger capture based on attributes since it can access the message contents too. See the attached patch, this would be very helpful for debugging sporadically occurring errors. I would be glad if you could accept this feature request or patch. We'll take a look at how to fit this in. It's probably better to have in the parent class and be more aware of direction (in/out) and protocol so that we can support TACACS+ too. However, I'd say it would be close to what you had in the patch. Thanks again for your suggestion! Heikki -- Heikki Vatiainen Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. ___ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] LogSkipHook for MessageLog
Hi Heikki,
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 implemented it now and 'it works well for me'(TM),
See the attached patch, this would be very helpful for debugging
sporadically occurring errors.
I would be glad if you could accept this feature request or patch.
Best Regards
Charly
--
Karl Gaissmaier
Universität Ulm
kiz, Kommunikations und Informationszentrum
89069 Ulm
Tel.: 49(0)731/50-22499
Fax : 49(0)731/50-12-22499
diff --git a/Radius/MessageLogFILE.pm b/Radius/MessageLogFILE.pm
index a0c7e0b..3f2d4c6 100644
--- a/Radius/MessageLogFILE.pm
+++ b/Radius/MessageLogFILE.pm
@@ -88,6 +88,17 @@ 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})
+{
+ # help hook writers
+ my $from_ip = Radius::Util::inet_ntop($from_ip);
+ my $to_ip = Radius::Util::inet_ntop($to_ip);
+
+ my ($skip) = $self->runHook('LogSkipHook', undef, $p, $from_ip,
$from_port, $to_ip, $to_port);
+ return if $skip;
+}
+
my $format = $self->{Format};
my $encoding = $self->{Encoding} ||
$Radius::MessageLogFILE::file_encoding_enum[0];
my $filename = Radius::Util::format_special($self->{Filename}, $p, $self,
'radius', $format, $encoding);
@@ -154,6 +165,17 @@ 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})
+{
+ # help hook writers
+ my $from_ip = Radius::Util::inet_ntop($from_ip);
+ my $to_ip = Radius::Util::inet_ntop($to_ip);
+
+ my ($skip) = $self->runHook('LogSkipHook', undef, $m, $from_ip,
$from_port, $to_ip, $to_port);
+ return if $skip;
+}
+
my $format = $self->{Format};
my $encoding = $self->{Encoding} ||
$Radius::MessageLogFILE::file_encoding_enum[0];
my $filename = Radius::Util::format_special($self->{Filename}, undef,
$self, 'diameter', $format, $encoding);
diff --git a/Radius/MessageLogGeneric.pm b/Radius/MessageLogGeneric.pm
index 2bc7099..29286f3 100644
--- a/Radius/MessageLogGeneric.pm
+++ b/Radius/MessageLogGeneric.pm
@@ -16,6 +16,11 @@ use warnings;
%Radius::MessageLogGeneric::ConfigKeywords =
(
+ 'LogSkipHook' =>
+ ['hook',
+ '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.',
+ 1],
+
);
# RCS version number of this module
___
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
