Menu
▾
▴
#1760 5.4 traphandle: unresolved IP translated to <UNKNOWN>
Net-SNMP 5.4:
The output from traphandle in snmptrapd gives <UNKNOWN> for the first line instead of the host name. I think previous versions would output the IP address if the hostname could not be resolved.
The following traphandle can be used for testing:
#!/usr/bin/perl
use strict;
open (OUT, ">>/tmp/traphandler.out");
select OUT;
print "traphandler called: " . localtime() . "\n";
while (defined(my $line = <>))
{
print $line;
}
close OUT;
Logged In: YES
user_id=848638
Originator: NO
Which previous versions did *not* output <UNKNOWN> here? Based on a *very* quick glance, <UNKNOWN> is there at least since June 2003. Also, I don't really see a problem with the curtrent approach given that the second line in the traphandler input will still always contain the IP address, won't it?
Logged In: YES
user_id=85836
Originator: YES
I haven't tested the other versions yet. There are a few places in the code where it will output <UNKNOWN>, but I don't think I have ever seen it actually output <UNKNOWN> until recently. I have been using my SNMPTT trap handler on many systems since 2002, and I have never had this problem before.
Something has obviously changed.
Alex
Logged In: YES
user_id=88893
Originator: NO
It looks as if this problem has arisen relatively recently.
Certainly on the 5.2.x line, the most recent release (5.2.3)
works as expected, while the current CVS code for that branch
is broken. It's not that the UNKNOWN handling is new code.
Rather that the earlier checks have suddenly started to fail.
I believe that the culprit is the recent-ish change to
snmplib/snmpUDPDomain.c (see Patch #1509943). This changed
the format (and size) of the pdu->transport_data field.
But the snmptrapd_log.c code hasn't been updated to match,
so the size test fails, and processing falls through to the
default handling (hence "UNKNOWN").
Logged In: YES
user_id=848638
Originator: NO
Good catch! Bumping severity ...
Logged In: YES
user_id=88893
Originator: NO
OK - I've fixed this on all active lines (i.e. 52x and above), by
copying the new-style transport_data handling into snmptrapd_log.c
But I can't help feeling that this is the wrong way to tackle this
problem - it would make more sense for the hostname lookup to be
handled within the transport-specific format routine.
Logged In: YES
user_id=1717075
Originator: NO
Hi
I made snmptrapd resolve hostnames from ipaddresses with a small but maybe not nice change to snmptrapd_log.c in the source:
by changing line 735 in the code for snmptrapd_log.c from:
if (addr != NULL
&& pdu->transport_data_length ==
sizeof(struct sockaddr_in))
to
if (addr != NULL
&& pdu->transport_data_length >= 0)
made it work for me.
I currently use snmptt with nagios for serversurveillence and it works.
Best regards
Rene Jensen
Logged In: YES
user_id=88893
Originator: NO
I'd be surprised if that worked correctly,
since the *format* of the 'transport_data' field
has changed - not just the size.
The current CVS code branches have what should
be the correct fix for this problem. It would
be useful to have some feedback as to whether
this does actually work as expected.
Logged In: YES
user_id=1717075
Originator: NO
To us the quick fix as described earlier works as expected. We now get the data correctly trasnlated through snmptt to nagios. But of course it will be worth trying out the CVS code branches, as I am not sure the fix might have bad effects elsewhere than using it with snmptt. But still it works for us for now.