Re: [nv-l] Authentication Failure Trap Argument interpretation

[James Shanks <jshanks@us.ibm.com>]

Perhaps so, Joe, but when you send an SNMP V1 trap about an IPv4 address, everybody expects it to be x'40", and not just us apparently, but those other tools as well.  

In trapd's case, he does not consult any MIB before formatting the data values in a V1 trap.  It's a straightforward parse based on the embedded ASN.1 type. That design decision was made a long time ago.  Perhaps trapd should start reading MIBs first before he attempts to format the variable data ,  but  that kind of enhancement is a long way off, in my opinion.    The performance implications of it are huge to say the least.

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

Joe Fernandez <jfernand@kardinia.com> Sent by: owner-nv-l-digest@lists.us.ibm.com 10/23/2003 10:29 AM Please respond to nv-l

To:        nv-l@lists.us.ibm.com         cc:                 Subject:        Re: [nv-l] Authentication Failure Trap Argument interpretation

James,

The two objects that Craig lists are from the Cisco System MIB.

1.3.6.1.4.1.9.9.131.1.5.2.0 = csySnmpAuthFailAddressType
Syntax=netAddressType

1.3.6.1.4.1.9.9.131.1.5.3.0 = csySnmpAuthFailAddress
Syntax=InetAddress

The MIB imports these Textual Conventions from INET-ADDRESS-MIB

If I read INET-ADDRESS-MIB correctly, the IETF is telling MIB designers to
stop
using the old IpAddress syntax because it does not cater for IPv6, and start
using these Textual Conventions to allow for both IP v4 and v6. 

And the way to use them is to have two objects, the first defining the type of
address (v4,v6,..), the second with the actual address.
The first value below is 1 which is the enumeration for IPv4 if
Syntax=netAddressType.
The syntax of InetAddress is defined as just Octet String, so that is why
it is
encoded that way.
 

 

At 12:01 PM 22/10/2003 -0400, you wrote: 

>
> Well, if that's the trap hex, it just says "OCTET STRING"  (x04) and not "IP
> ADDRESS" (x40) 
>         04 04 a2 83 26 3d     
> means "octet string of 4 bytes" with that data.  We would expect an IP
> Address to be 
>          40 04 a2 83 26 3d 
>                                         
> I cannot answer why your other tools seem to know that this is meant as
an IP
> Address.  That's not what it says. 
>
>
> James Shanks
> Level 3 Support  for Tivoli NetView for UNIX and Windows
> Tivoli Software / IBM Software Group 
>
>
> "Treptow, Craig" <Treptow.Craig@principal.com> 
> Sent by: owner-nv-l-digest@lists.us.ibm.com 
>
> 10/22/2003 11:47 AM 
> Please respond to nv-l 
>         
>         To:        "NetView List (E-mail)" <nv-l@lists.us.ibm.com> 
>         cc:         
>         Subject:        [nv-l] Authentication Failure Trap Argument
> interpretation 
>
>
>
> Hi.  We are running NV 7.1.3 on AIX.  Some of our Cisco switches (and
> possibly routers), are sending us Authentication Failure traps.  The problem
> is that Netview seems to be interpreting the second argument as an ASCII
> character string, rather than 4 hex values.  Therefore, in the trap that
gets
> displayed in Netview and processed, the second argument shows up as some
> strange characters, rather than a IP address.  For what it's worth, Sniffer
> and Ethereal also interpret it this way.  However, in the reading I've done,
> I don't see that Cisco is doing anything wrong when they format this trap.
>  Perhaps I've missed something.  Any help is appreciated.
>
> Here is an example:
>
> User Datagram Protocol, Src Port: 49608 (49608), Dst Port: snmptrap (162)
>    Source port: 49608 (49608)
>    Destination port: snmptrap (162)
>    Length: 96
>    Checksum: 0xd4b0 (correct)
> Simple Network Management Protocol
>    Version: 1 (0)
>    Community: public
>    PDU type: TRAP-V1 (4)
>    Enterprise: 1.3.6.1.4.1.9.5.51 (iso.3.6.1.4.1.9.5.51)
>    Agent address: risgrandisland1ne-sw5.net.principal.com (172.25.117.133)
>    Trap type: AUTHENTICATION FAILED (4)
>    Specific trap type: 0
>    Timestamp: 34124361
>    Object identifier 1: 1.3.6.1.4.1.9.9.131.1.5.2.0
> (iso.3.6.1.4.1.9.9.131.1.5.2.0)
>    Value: INTEGER: 1
>    Object identifier 2: 1.3.6.1.4.1.9.9.131.1.5.3.0
> (iso.3.6.1.4.1.9.9.131.1.5.3.0)
>    Value: STRING: "¢f&="
>
> 0000  00 06 29 6c c3 1a 00 05 5e 45 4b 02 08 00 45 00   ..)l....^EK...E.
> 0010  00 74 4d 66 00 00 19 11 69 b4 ac 19 75 85 a2 83   .tMf....i...u...
> 0020  26 3d c1 c8 00 a2 00 60 d4 b0 30 56 02 01 00 04   &=.....`..0V....
> 0030  06 70 75 62 6c 69 63 a4 49 06 08 2b 06 01 04 01   .public.I..+....
> 0040  09 05 33 40 04 ac 19 75 85 02 01 04 02 01 00 43   ..3@...u.......C
> 0050  04 02 08 b2 49 30 2b 30 12 06 0d 2b 06 01 04 01   ....I0+0...+....
> 0060  09 09 81 03 01 05 02 00 02 01 01 30 15 06 0d 2b   ...........0...+
> 0070  06 01 04 01 09 09 81 03 01 05 03 00 04 04 a2 83   ................
> 0080  26 3d                                             &=
>
>
> Thanks,
>
> Craig
>
>
>
>



Joe Fernandez
Kardinia Software
jfernand@kardinia.com

http://www.kardinia.com