Menu
▾
▴
[ net-snmp-Bugs-1605253 ] SNMP v2 traphandle output missing community string, agent IP
|
From: SourceForge.net <no...@so...> - 2006-11-29 16:30:42
|
Bugs item #1605253, was opened at 2006-11-29 14:35 Message generated for change (Comment added) made by tanders You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1605253&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: snmptrapd Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Burger (alex_b) Assigned to: Nobody/Anonymous (nobody) Summary: SNMP v2 traphandle output missing community string, agent IP Initial Comment: Net-SNMP 5.1 or higher (maybe others too). The output for traphandle is missing the community string, agent IP address and sometimes the enterprise for SNMP v2 traps. Output from a v1 trap (snmpd startup): <UNKNOWN> UDP: [127.0.0.1]:32897 DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:00:00.13 SNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart SNMP-COMMUNITY-MIB::snmpTrapAddress.0 192.168.4.1 SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 "public1" SNMPv2-MIB::snmpTrapEnterprise.0 NET-SNMP-MIB::netSnmpAgentOIDs.10 Output from a v2 trap (snmpd startup): <UNKNOWN> UDP: [127.0.0.1]:32898 DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:00:00.13 SNMPv2-MIB::snmpTrapOID.0 SNMPv2-MIB::coldStart SNMPv2-MIB::snmpTrapEnterprise.0 NET-SNMP-MIB::netSnmpAgentOIDs.10 Output from a v1 trap (snmpd shutdown): <UNKNOWN> UDP: [127.0.0.1]:32886 DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:01:20.36 SNMPv2-MIB::snmpTrapOID.0 NET-SNMP-AGENT-MIB::nsNotifyShutdown SNMP-COMMUNITY-MIB::snmpTrapAddress.0 192.168.4.1 SNMP-COMMUNITY-MIB::snmpTrapCommunity.0 "public1" Output from a v2 trap (snmpd shutdown): <UNKNOWN> UDP: [127.0.0.1]:32888 DISMAN-EVENT-MIB::sysUpTimeInstance 0:0:01:20.36 SNMPv2-MIB::snmpTrapOID.0 NET-SNMP-AGENT-MIB::nsNotifyShutdown The coldStart contains the enterprise, but the shutdown does not. command_handler in snmptrapd_handlers.c should be modified to add snmpTrapCommunity, snmpTrapAddress and snmpTrapEnterprise if it is not already in the pdu. This was reported to the -Users list recently: http://www.mail-archive.com/net...@li.../msg11785.html and also here: http://sourceforge.net/mailarchive/forum.php?thread_id=31128067&forum_id=11889 Alex ---------------------------------------------------------------------- >Comment By: Thomas Anders (tanders) Date: 2006-11-29 17:30 Message: Logged In: YES user_id=848638 Originator: NO I suggest you take it to the lists, then. I don't think adding varbinds that aren't in the payload of the original v2 notification is a backwards-compatible change. As for adding "anything that's in the original trap", how would you add all security info from a SNMPv3 notification, then? And in what format? ---------------------------------------------------------------------- Comment By: Alex Burger (alex_b) Date: 2006-11-29 17:09 Message: Logged In: YES user_id=85836 Originator: YES I still consider it a bug. If it's not a bug, then it's a feature that should have been there from the start. The interface says 'VARBINDS'. For SNMP v1 traps, then that *must* include the community, agent address and enterprise because the trap is converted to v2. To make it consistent, we should also add them for v2 traps. Maybe it's not a real 'bug', but something that should be 'fixed'. How is access control beyond the scope of notification handlers? Obviously people need this information passed via traphandle, so I consider it in scope. Anything that is in the original trap should be (optionally) passed to the trap handler. ---------------------------------------------------------------------- Comment By: Thomas Anders (tanders) Date: 2006-11-29 15:38 Message: Logged In: YES user_id=848638 Originator: NO I'm not convinced this is a bug. The documented behaviour of the traphandle command is to pass HOSTNAME IPADDRESS VARBINDS to the notification handler with v1 TRAPs being converted per RFC 2576. Adding anything else from the PDU (e.g. community) would be a violation of the documented interface. Also, access control is beyond the scope of notification handlers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1605253&group_id=12694 |