Trap header blues - SNMP

This is a discussion on Trap header blues - SNMP ; Hi All - I used a packet sniffer to capture 2 SNMP Trap packets so I can analyze their contents and better understand what is being transmitted and make my own application to capture and decode these packets. What I'm ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Trap header blues

  1. Trap header blues

    Hi All -

    I used a packet sniffer to capture 2 SNMP Trap packets so I can analyze
    their contents and better understand what is being transmitted and make my
    own application to capture and decode these packets.

    What I'm having problems with is the first few bytes of each trap message.
    Here is what the first one looks like:
    30 2A 02 01 00

    Bytes 3,4 and 5 are obviously the version information. I know that byte 2
    denotes the number of bytes to follow, in this particular case there are 42
    bytes that follow, starting with the version information. The second packet
    I captured looks like this:

    30 82 00 6D 02 01 00

    As before, bytes 5,6 and 7 are the version information. I know that byte 4
    is the number of bytes to follow (109). What I don't understand is - what
    is the 82 located at byte position 2? I was hoping the byte header was a
    fixed length (2 bytes?) but that obviously isn't the case. Can anyone
    explain to me what in the world 82 means and why the header is 4 bytes now
    instead of 2 like I saw before?

    Thanks!
    Brian Patterson

    NOTE - remove all upper case letters from return email address to email me
    directly.



  2. Re: Trap header blues

    In article <7loUa.147613$ye4.102722@sccrnsc01>,
    NObriandpatterson@SPAMmchsiGOAWAY.com says...

    > 30 82 00 6D 02 01 00
    >
    > As before, bytes 5,6 and 7 are the version information. I know that byte 4
    > is the number of bytes to follow (109). What I don't understand is - what
    > is the 82 located at byte position 2? I was hoping the byte header was a
    > fixed length (2 bytes?) but that obviously isn't the case. Can anyone
    > explain to me what in the world 82 means and why the header is 4 bytes now
    > instead of 2 like I saw before?


    I would suggest going to the ITU-T website and downloading the X.209
    (Basic Encoding Rules) spec. It's free, last I checked. But..

    An ASN.1 encoding as you've gathered looks like this:

    ---------------------------
    | Tag | Length | Contents |
    ---------------------------

    The Tag is a single octet, consisting of three parts, that indicates the
    type of data encoded in the contents, and the form of the encoding. The
    highest two bits indicate the class -- application, universal, context,
    private (which more or less indicates whether it is a true ASN.1 type of
    it it's a defined type with tag other than what normally appears)--
    followed by a primitive/constructed flag (which indicates whether the
    encoding is entirely present of it's fragmented; SNMP uses ONLY primitive
    encodings), and finally 5 bits distinguishing the type. For example, the
    Counter32 type is really an INTEGER (0x02) encoding, but it has a tag of
    [APPLICATION 1] or (0x41).

    The length field, of course, indicates the number of octets in the
    contents portion. However, there are two forms that the length field can
    take, owing to the fact that content lengths are not limited to 255
    octets. The highest bit of the first octet in the length field indicates
    which form the length field takes. If this bit is set then it indicates
    the long form; if it is not set, then it indicates the short form. In
    the short form, you're limited to the lower 7 bits to indicate the
    content length (maximum of 127). In the long form, the remaining 7 bits
    of the first octet indicate how many *following* octets are part of the
    length field. Further, there is no requirement that you use the short
    form for content lengths less than 127 octets, and SNMP messages are
    often longer than that, so you must be prepared to handle both forms at
    any time.

    The form for the contents portion depends on the base ASN.1 type the data
    is being encoded as, regardless of the actual tag. e.g., in the
    Counter32 case, the contents are encoded as an INTEGER because Counter32
    is defined as:

    Counter32 ::=
    [APPLICATION 1]
    IMPLICIT INTEGER (0..4294967295)

    The following encodings for the integer value 0, for example, are all
    equivalent but have different (all legal) length fields:

    02 01 00
    02 81 01 00
    02 84 00 00 00 01 00
    02 89 00 00 00 00 00 00 00 00 01 00

    The latter is one you aren't likely to ever see except under a QA testing
    scenario, but it's something a robust ASN.1 decoder should be capable of
    handling anyway.

    So, getting back to the excerpt from your message:

    > 30 82 00 6D 02 01 00


    The first octet (0x30) indicates a SEQUENCE encoding. The highest bit of
    the next octet is set, which indicates the long form for the length
    field. Masking off that bit leaves the value 2, which means the next two
    octets of the encoding (00 6D) are both part of the length field:
    0x006d == 109. And thus begins the contents of the SEQUENCE, staring
    with the 02 octet (which is the tag for the INTEGER identifying the SNMP
    version).

    >
    > Thanks!
    > Brian Patterson
    >
    > NOTE - remove all upper case letters from return email address to email me
    > directly.
    >
    >
    >


    --
    Michael Kirkham
    Muonics
    http://www.muonics.com/

  3. Re: Trap header blues

    Thank You! Thank You! Thank You!

    I actually saw the document on ASN.1 but didn't read it very well so I
    didn't know just how involved everything was. I appreciate the quick
    response and extremly helpful information.

    Brian Patterson

    "Michael Kirkham" wrote in message
    news:MPG.198bf47660c713b8989723@news.sf.sbcglobal. net...
    > In article <7loUa.147613$ye4.102722@sccrnsc01>,
    > NObriandpatterson@SPAMmchsiGOAWAY.com says...
    >
    > > 30 82 00 6D 02 01 00
    > >
    > > As before, bytes 5,6 and 7 are the version information. I know that

    byte 4
    > > is the number of bytes to follow (109). What I don't understand is -

    what
    > > is the 82 located at byte position 2? I was hoping the byte header was

    a
    > > fixed length (2 bytes?) but that obviously isn't the case. Can anyone
    > > explain to me what in the world 82 means and why the header is 4 bytes

    now
    > > instead of 2 like I saw before?

    >
    > I would suggest going to the ITU-T website and downloading the X.209
    > (Basic Encoding Rules) spec. It's free, last I checked. But..
    >
    > An ASN.1 encoding as you've gathered looks like this:
    >
    > ---------------------------
    > | Tag | Length | Contents |
    > ---------------------------
    >
    > The Tag is a single octet, consisting of three parts, that indicates the
    > type of data encoded in the contents, and the form of the encoding. The
    > highest two bits indicate the class -- application, universal, context,
    > private (which more or less indicates whether it is a true ASN.1 type of
    > it it's a defined type with tag other than what normally appears)--
    > followed by a primitive/constructed flag (which indicates whether the
    > encoding is entirely present of it's fragmented; SNMP uses ONLY primitive
    > encodings), and finally 5 bits distinguishing the type. For example, the
    > Counter32 type is really an INTEGER (0x02) encoding, but it has a tag of
    > [APPLICATION 1] or (0x41).
    >
    > The length field, of course, indicates the number of octets in the
    > contents portion. However, there are two forms that the length field can
    > take, owing to the fact that content lengths are not limited to 255
    > octets. The highest bit of the first octet in the length field indicates
    > which form the length field takes. If this bit is set then it indicates
    > the long form; if it is not set, then it indicates the short form. In
    > the short form, you're limited to the lower 7 bits to indicate the
    > content length (maximum of 127). In the long form, the remaining 7 bits
    > of the first octet indicate how many *following* octets are part of the
    > length field. Further, there is no requirement that you use the short
    > form for content lengths less than 127 octets, and SNMP messages are
    > often longer than that, so you must be prepared to handle both forms at
    > any time.
    >
    > The form for the contents portion depends on the base ASN.1 type the data
    > is being encoded as, regardless of the actual tag. e.g., in the
    > Counter32 case, the contents are encoded as an INTEGER because Counter32
    > is defined as:
    >
    > Counter32 ::=
    > [APPLICATION 1]
    > IMPLICIT INTEGER (0..4294967295)
    >
    > The following encodings for the integer value 0, for example, are all
    > equivalent but have different (all legal) length fields:
    >
    > 02 01 00
    > 02 81 01 00
    > 02 84 00 00 00 01 00
    > 02 89 00 00 00 00 00 00 00 00 01 00
    >
    > The latter is one you aren't likely to ever see except under a QA testing
    > scenario, but it's something a robust ASN.1 decoder should be capable of
    > handling anyway.
    >
    > So, getting back to the excerpt from your message:
    >
    > > 30 82 00 6D 02 01 00

    >
    > The first octet (0x30) indicates a SEQUENCE encoding. The highest bit of
    > the next octet is set, which indicates the long form for the length
    > field. Masking off that bit leaves the value 2, which means the next two
    > octets of the encoding (00 6D) are both part of the length field:
    > 0x006d == 109. And thus begins the contents of the SEQUENCE, staring
    > with the 02 octet (which is the tag for the INTEGER identifying the SNMP
    > version).
    >
    > >
    > > Thanks!
    > > Brian Patterson
    > >
    > > NOTE - remove all upper case letters from return email address to email

    me
    > > directly.
    > >
    > >
    > >

    >
    > --
    > Michael Kirkham
    > Muonics
    > http://www.muonics.com/




+ Reply to Thread