Marc> (I'm still curious to know what I'm missing, and why configure
Marc> didn't disable the use of multicast sockets if linux is not
Marc> supposed to support them)
The question whether multicast sockets can be used depends on the
network interfaces that are up and running. It would be a bad idea to
make configure dependent on the current interface status and thats why
you get this warning message. Linux does support multicast sockets.
Marc> From the Retixes, I receive two kinds of traps:
Marc> Thu May 22 12:26:39 PDT 1997 SNMPv1 trap from [204.80.112.65]:
Marc> sysUpTime.0 = 0d 2:11:35.48
Marc> snmpTrapOID.0 = 1.3.6.1.4.1.72.0.11
Marc> portLgclPortID.13 = 13
Marc> snmpTrapEnterprise.0 = retix
Marc> Here, the 0.11 trap wasn't converted into useful text, because
Marc> I can't seem to get the MIB contain the 72.0 branch (traps if
Marc> I'm not mistaken). That's a problem I'll have to solve with
Marc> Retix.
I am not sure if Retix will be able to help you here. Scotty follows
the SNMPv2 rules and hence a SNMPv1 trap is automatically converted
into an SNMPv2 trap. This means that the enterprise, generic and
specific fields of a SNMPv1 message are converted into a trap object
identifier. See RFC 1908 section 3.1.2 paragraph (2) for details.
This means that your SNMPv1 trap from the retix box was:
enterprise = 1.3.6.1.4.1.72
generic = enterpriseSpecific
specific = 11
The scotty MIB parser is supposed to do the same conversion when it
reads a TRAP-TYPE macro. The parser registers a node with the correct
trap object identifier in the MIB tree. This did not happen in your
case. The question is now, whether the Retix MIB does not use the
TRAP-TYPE properly, or if there is a bug in the parser, or both.
Marc> The other messages seem to work fine:
Marc> Thu May 22 12:26:46 PDT 1997 SNMPv1 trap from [204.80.112.65]:
Marc> sysUpTime.0 = 0d 2:11:35.59
Marc> snmpTrapOID.0 = BRIDGE-MIB!newRoot
Marc> snmpTrapEnterprise.0 = dot1dBridge
This one is defined in rfc1493.mib or rfc1525.mib and looks like a
proper definition, where the conversions actually work as designed.
Marc> My much bigger problem is with Ascend (and it's far from being
Marc> the first time I have "fun" with them).
Marc> The box sends me traps of this form:
Marc> Thu May 22 12:27:17 PDT 1997 SNMPv1 trap from [198.147.96.77]:
Marc> sysUpTime.0 = 67d 10:32:16.00
Marc> snmpTrapOID.0 = 1.3.6.1.4.1.529.1.2.4.0.12
Marc> consoleIndex.2 = 2
Marc> snmpTrapEnterprise.0 = max4000
Marc> Descriptor: max4000
Marc> MIB Module: ASCEND-MIB
Marc> Identifier: 1.3.6.1.4.1.529.1.2.4
Marc> Max. Access: not-accessible
Marc> File: /usr/local/lib/tnm2.1.5/mibs/ascend.mib
Marc> So, a trap like 1.3.6.1.4.1.529.1.2.4 would make sense and
Marc> would be resolved as ascend.products.max.max4000, and the
Marc> resulting string is max4000
This is the same problem. This is SNMPv1 trap with enterprise =
1.3.6.1.4.1.529.1.2.4 and specific = 12. It all depends on the Trap
definition in the MIB.
Marc> I haven't read the SNMP RFCs (a bit numerous), but this looks
Marc> wrong to me, yet ascend tells me it's the way it's supposed to
Marc> be and that their HP openview deals fine with it.
Marc> Here's the question:
Marc> Who messes up: Tkined or Ascend?
The scotty protocol engine seems to handle this quite nicely. The
question is whether the MIB parser does a poor job or if the MIB
definition of these traps is insufficient/broken. Please look how the
traps are defined in the Retix or in the Ascend MIB in order to
determine where the problem actually is.
Juergen
-- Juergen Schoenwaelder <schoenw@gaertner.de> (Tel: +49-531-23873-0) Gaertner Datensysteme, Hamburger Strasse 273a, 38114 Braunschweig, Germany-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.