-Coders,
I'm currently digging through the various engineID-releated functions to explain myself a strange behaviour with the "oldEngineID" config directive that bugs me for way too long now.
Even though snmptrapd handles the "oldEngineID 0x80001f888096c4781a71d0c43e" from the config file, it insists on generating a new one (e.g. 0x800007e58023572f3955f66341) soon thereafter in lcd_set_enginetime(). This is also the one that gets saved to the persistent file on shutdown.
Shouldn't snmptrapd use the supplied oldEngineID instead?!
- --- snip --- foo# snmptrapd --version
NET-SNMP Version: 5.2.pre1 Web: http://www.net-snmp.org/ Email: [EMAIL PROTECTED]
foo# cat /tmp/snmptrapd.conf
traphandle default /bin/true
oldEngineID 0x80001f888096c4781a71d0c43e
foo# snmptrapd -f -D -C -c /tmp/snmptrapd.conf
[...]
trace: read_configs(): read_config.c, 804:
read_config: reading normal configuration tokens
trace: read_configs(): read_config.c, 828:
read_config: Reading optional config file: "/tmp/snmptrapd.conf"
trace: read_config(): read_config.c, 711:
read_config: Reading configuration /tmp/snmptrapd.conf
trace: read_config(): read_config.c, 771:
read_config: /tmp/snmptrapd.conf:1 examining: traphandle default /bin/true
trace: run_config_handler(): read_config.c, 474:
read_config: Found a parser. Calling it: traphandle / default /bin/true
trace: snmptrapd_parse_traphandle(): snmptrapd_handlers.c, 82:
read_config:traphandle: registering handler for: default
trace: read_config(): read_config.c, 771:
read_config: /tmp/snmptrapd.conf:2 examining: oldEngineID 0x80001f888096c4781a71d0c43e
trace: run_config_handler(): read_config.c, 474:
read_config: Found a parser. Calling it: oldEngineID / 0x80001f888096c4781a71d0c43e
trace: netsnmp_ds_set_boolean(): default_store.c, 205:
netsnmp_ds_set_boolean: Setting LIB:27 = 1/True
trace: snmp_call_callbacks(): callback.c, 198:
callback: START calling callbacks for maj=0 min=0
trace: snmp_call_callbacks(): callback.c, 212:
callback: calling a callback for maj=0 min=0
trace: snmp_call_callbacks(): callback.c, 212:
callback: calling a callback for maj=0 min=0
trace: sc_hash(): scapi.c, 397:
trace: sc_get_properlength(): scapi.c, 117:
trace: sc_hash(): scapi.c, 397:
trace: sc_get_properlength(): scapi.c, 117:
trace: set_enginetime(): lcd_time.c, 354:
lcd_set_enginetime: engineID 80 00 07 E5 80 23 57 2F 39 55 F6 63 41
: boots=1, time=0
trace: snmp_call_callbacks(): callback.c, 212:
callback: calling a callback for maj=0 min=0
trace: set_an_alarm(): snmp_alarm.c, 363:
snmp_alarm: no alarms found to schedule
trace: snmp_call_callbacks(): callback.c, 224:
callback: END calling callbacks for maj=0 min=0 (3 called)
2004-10-06 15:42:46 NET-SNMP version 5.2.pre1 Started.
- --- snap ---
Since we explicitely save the "oldEngineID" in the persistent file on shutdown, I'd assume it to be a bug if it's ignored on startup.
Interestingly, if one uses the "engineID STRING" directive, everything works as expected. But, unlike oldEngineID, this doesn't allow to set an arbitrary engineID (despite it's name).
Any insights appreciated. I'm willing to work on a proper fix if needed.
+Thomas
-- Thomas Anders (thomas.anders at blue-cable.de)
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
