Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am having some trouble configuring snmptt to properly translate snmp traps.

The following is a problem:

/etc/snmp/snmptt.conf reflects:

EVENT fgFmTrapIfChange . "Status Events" Critical
EXEC /usr/local/nagios/libexec/eventhandlers/submit_check_result $r "snmp_traps" 2 "$O: $+*" "$*"

Trap is sent to the managing FortiManager if an interface IP is changed
  1: fnSysSerial
  2: ifName
  3: fgManIfIp
  4: fgManIfMask

when a trap is received, /var/log/messages reflects:

Sep  6 12:07:32 SNMPMANAGERHOST snmptrapd[15385]:
2012-09-06 12:07:32 <UNKNOWN>
# = Timeticks: (707253943) 81 days, 20:35:39.43
# = OID: .
# = STRING: internal4
# = IpAddress:
# = IpAddress:

Sep  6 12:07:37 SNMPMANAGERHOST icinga:
enterprises.12356. enterprises.12356. ifName.10:internal4 enterprises.12356. enterprises.12356.

Since the icinga entry reflects the EXEC, it's obvious there is no translations occurring by snmptt.

I have verified that translate_log_trap_oid and net_snmp_perl_enable is enabled in snmptt.ini

When using --debug=1 to start snmptt, I see the following in the --debugfile:

********** Net-SNMP version 5.05 Perl module enabled **********

The main NET-SNMP version is reported as NET-SNMP version: 5.5.

What else can be done to verify that snmptt is configured properly to translate traps?

I have run snmptt-net-snmp-test to verify whatever net-snmp-perl version I have installed properly supports translations. The output indicates it does.

/root/snmptt_1.3/snmptt-net-snmp-test --best_guess=2

SNMPTT Net-SNMP Test v1.0
(c) 2003 Alex Burger

best_guess: 2

Testing translateObj

Testing: ., long_names=disabled, include_module=disabled
Test passed.  Result: sysDescr

Testing: ., long_names=disabled, include_module=enabled
Test passed.  Result: RFC1213-MIB::sysDescr

Testing: ., long_names=enabled, include_module=disabled
Test passed.  Result:

Testing: ., long_names=enabled, include_module=enabled
Test passed.  Result:

Testing: sysDescr, long_names=disabled, include_module=disabled
Test passed.  Result: .

Testing: RFC1213-MIB::sysDescr, long_names=disabled, include_module=disabled
Test passed.  Result: .

Testing: system.sysDescr, long_names=disabled, include_module=disabled
Test passed.  Result: .

Testing: RFC1213-MIB::system.sysDescr, long_names=disabled, include_module=disabled
Test passed.  Result: .

Testing:, long_names=disabled, include_module=disabled
Test passed.  Result: .

Testing getType

Testing: .
Test passed.  Result: INTEGER

Testing: ipForwarding
Test passed.  Result: INTEGER

Testing Description
Test passed.  Result:
The indication of whether this entity is acting
as an IP gateway in respect to the forwarding of
datagrams received by, but not addressed to, this
entity.  IP gateways forward datagrams.  IP hosts
do not (except those source-routed via the host).
Note that for some managed nodes, this object may
take on only a subset of the values possible.
Accordingly, it is appropriate for an agent to
return a `badValue' response if a management
station attempts to change this object to an
inappropriate value.

I have manually gone through the MIB with the definition that's not resolving, and verified that it is properly linking back to the proper resolved definition. It is:


    OBJECTS     { fnSysSerial, ifName, fgManIfIp, fgManIfMask }
    STATUS      current
        "Trap is sent to the managing FortiManager if an interface IP is changed"
    ::= { fgFmTrapPrefix 1004 }

    ::= { fgMgmt 0 }

    ::= { fnFortiGateMib 6 }

    ::= { fortinet 101 }

    FnBoolState, FnIndex, fnAdminEntry, fnSysSerial, fortinet

    ::= { enterprises 12356 }


I've exhausted all the documentation and even posted fruitlessly in the snmptt-users mailing list.

I can not prove it is the MIB.

Why would snmptt fail to translate traps?


  • $O = enterprises.12356.
  • when $O should = fgFmTrapIfChange






authCommunity log,execute,net communitystr
traphandle default /usr/bin/snmptthandler


MIB where trap that isn't being translated lives (and it's referenced MIB).

Note that linkUp and linkDown are translating properly.


I have also tested with another MIB that isn't a default MIB contained within the net-snmp package, and this MIB also fails to resolve.


If I set the following in snmptt.ini:

mode = standalone

And I set the following in snmptrapd.conf:

traphandle default /usr/sbin/snmptt --ini=/etc/snmp/snmptt.ini

I am able to translate traps as expected.

This means that whatever method /usr/sbin/snmptt uses to daemonize may not have access to the MIBs, or may be doing something other than what's described. The documentation included within snmptt.ini likely will contain the answers I seek.


Set mibs_environment = ALL in snmptt.ini


# Allows you to set the MIBS environment variable used by SNMPTT
# Leave blank or comment out to have the systems enviroment settings used
# To have all MIBS processed, set to ALL
# See the snmp.conf manual page for more info.

mibs_environment = ALL must be set in snmptt.ini even with snmptrapd starting with -m ALL (where ALL is a wild card statement that includes all MIBs [defined within the files]).


share|improve this question
Can you post your snmptt.ini? How are you starting snmptt? – D.F. Sep 12 '12 at 3:58
original question updated with: snmptt. snmptrapd.conf snmptt.conf, trap MIB and MIB referenced for trap definition. – mbrownnyc Sep 12 '12 at 12:36
So, are you using nagios or icinga? I haven't used icinga at all, but does it install utilities in /usr/local/nagios? – D.F. Sep 12 '12 at 13:52
What utilities are you concerned with? icinga and nagios are essentially the same thing. My concern isn't with icinga alerting; as the passive services are configured and the pipe is functioning. It is the script that pipes data into the FIFO that is the command pipe for icinga/nagios is not being provided with the correctly translated data. This translated data is a result of snmptt translating the OID of received traps. – mbrownnyc Sep 12 '12 at 13:58
let us continue this discussion in chat – D.F. Sep 12 '12 at 14:26
up vote 3 down vote accepted

I posted this in the chat window awhile back, but it looks like you may have left it. Your snmptt.ini file has the following translation options set :

translate_log_trap_oid = 1
translate_value_oids = 1
translate_enterprise_oid_format = 1
translate_trap_oid_format = 0
translate_varname_oid_format = 0
translate_integers = 1

The interesting one is the 'translate_trap_oid_format' which affects the value of $O. Valid values are 0 - 4, with 0 turning off translation, the rest are listed in snmptt.ini --

Set to 0 to disable translating OID values to text (symbolic form)
Set to 1 to translate OID values to short text (symbolic form) (eg: BuildingAlarm)
Set to 2 to translate OID values to short text with module name (eg: UPS-MIB::BuildingAlarm)
Set to 3 to translate OID values to long text (eg: iso...upsAlarm.BuildingAlarm)
Set to 4 to translate OID values to long text with module name (eg:UPS-MIB::iso...upsAlarm.BuildingAlarm)
share|improve this answer
Ahh hah! I knew it would be something trivial that I missed... always is! I will test tomorrow and award as necessary. What's the deal with update 3 above? Seems weird; but I guess it's a question for the dev(s). – mbrownnyc Sep 13 '12 at 1:18
That is odd. I can only really offer guesses as to the reason for that behavior...that for some reason when its run standalone it ignores options in the .ini file. It would probably take someone familiar with the source to answer that. – D.F. Sep 13 '12 at 15:03
Believe it or not, this doesn't solve the problem. However, referencing an old centreon installation, I was able to see that they use the standalone mode flag and feed the ini file in using --ini= as I had done in testing yesterday. I'm hopeless in getting daemon mode to translate a MIB that doesn't come along with the net-snmp package. I will just use the standalone method as it functions as I wish it to function. Thanks for your help! – mbrownnyc Sep 13 '12 at 18:58
Solution: mibs_environment= ALL. # Allows you to set the MIBS environment variable used by SNMPTT # Leave blank or comment out to have the systems enviroment settings used # To have all MIBS processed, set to ALL # See the snmp.conf manual page for more info. Works in daemon. Alright! – mbrownnyc Sep 13 '12 at 19:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.