[ net-snmp-Bugs-1638225 ] 5.4 traphandle: unresolved IP translated to <UNKNOWN>

[SourceForge.net <no...@so...>]

Bugs item #1638225, was opened at 2007-01-18 03:00
Message generated for change (Comment added) made by dts12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1638225&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: traps
>Status: Closed
>Resolution: Fixed
Priority: 6
Private: No
Submitted By: Alex Burger (alex_b)
Assigned to: Nobody/Anonymous (nobody)
Summary: 5.4 traphandle: unresolved IP translated to <UNKNOWN>

Initial Comment:
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;


----------------------------------------------------------------------

>Comment By: Dave Shield (dts12)
Date: 2007-01-23 15:03

Message:
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.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2007-01-22 23:45

Message:
Logged In: YES 
user_id=848638
Originator: NO

Good catch! Bumping severity ...

----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2007-01-22 22:56

Message:
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").

----------------------------------------------------------------------

Comment By: Alex Burger (alex_b)
Date: 2007-01-18 12:55

Message:
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


----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2007-01-18 09:09

Message:
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? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1638225&group_id=12694