snmptrapd is unable to parse long trap header

[jridky]

Description of problem:

snmptrap which is send from specific equipment isn't logged.
According to the snmptrapd debug log, snmptrapd failed to parse snmptrap header.

    error while parsing VarBindList: (parse header length 3 too short: need 0)

Steps to Reproduce:

1. Modify snmptrapd.conf as follows.

     # cat /etc/snmp/snmptrapd.conf
     disableAuthorization yes

2. Compile a test program source.

     # gcc -o snmptrap snmptrap.c

3. Execute a test program.

     # ./snmptrap

Actual results:
snmptrap is not logged by parse error.

Expected results:
snmptrap is logged

Original bug report with reproducer
https://bugzilla.redhat.com/show_bug.cgi?id=1912242

Code reference

net-snmp/snmplib/asn1.c

Line 329 in 83eb660

asn_parse_nlength(u_char *pkt, size_t pkt_len, u_long *data_len)

Investigation background:
According to the packet from reproducer, VarBindList contains following data(*1).

# tshark -xV -r testtrap_192
  ...clipped...
  Simple Network Management Protocol
      version: version-1 (0)
      community: public
      data: trap (4)
          trap
              enterprise: 1.3.6.1.6.3.1.1.5 (iso.3.6.1.6.3.1.1.5)
              agent-addr: 192.168.1.34 (192.168.1.34)
              generic-trap: coldStart (0)
              specific-trap: 0
              time-stamp: 172339598
              variable-bindings: 0 items

  0000  00 0c 29 99 a9 96 00 a0 98 da 3c 35 08 00 45 00   ..).......<5..E.
  0010  00 4d 3c 3e 00 00 40 11 ba da c0 a8 01 22 c0 a8   .M<>..@......"..
  0020  01 15 00 a1 00 a2 00 39 95 b2 30 82 00 2d 02 01   .......9..0..-..
  0030  00 04 06 70 75 62 6c 69 63 a4 20 06 08 2b 06 01   ...public. ..+..
  0040  06 03 01 01 05 40 04 c0 a8 01 22 02 01 00 02 01   .....@....".....
  0050  00 43 04 0a 45 b1 8e 30 82 00 00                  .C..E..0...
                             ^^^^^^^^^^^(*1)

Snmptrapd equivalent to compare output from reproducer.
According to the packet, VarBindList has the following data(*2).

# snmptrap -v 1 -c public localhost 1.3.6.1.6.3.1.1.5 192.168.1.34 0 0 ''

# tshark -xV -r snmptrap_v1.cap
  ...clipped...
  Simple Network Management Protocol
      version: version-1 (0)
      community: public
      data: trap (4)
          trap
              enterprise: 1.3.6.1.6.3.1.1.5 (iso.3.6.1.6.3.1.1.5)
              agent-addr: 192.168.1.34
              generic-trap: coldStart (0)
              specific-trap: 0
              time-stamp: 6722566
              variable-bindings: 0 items

  0000  00 00 03 04 00 06 00 00 00 00 00 00 00 00 08 00   ................
  0010  45 00 00 48 11 64 40 00 40 11 2b 3f 7f 00 00 01   E..H.d@.@.+?....
  0020  7f 00 00 01 9f 98 00 a2 00 34 fe 47 30 2a 02 01   .........4.G0*..
  0030  00 04 06 70 75 62 6c 69 63 a4 1d 06 08 2b 06 01   ...public....+..
  0040  06 03 01 01 05 40 04 c0 a8 01 22 02 01 00 02 01   .....@....".....
  0050  00 43 03 66 94 06 30 00                           .C.f..0.
                          ^^^^^(*2)

SNMP is based on BER (Basic Encoding Rules - reference) of ASN.1 (Abstract Syntax Notation One).
According to the specific of BER, differences of VarBindList packets with the former and the latter example BER format are follows.

              a    b    b'   b'
reproducer: 0x30 0x82 0x00 0x00
snmptrap:   0x30 0x00

a) identifier octets
b) length octets
b') subsequent octets of b).
c) contents octets
   *In this case, it doesn't exist because VarBindList is "0".
d) end-of-contents octets
   *In this case, it doesn't exist because it is only used in indefinite-length method.

In this case, the assumption is that snmptrapd failed to parse the header
because snmptrapd thinks that there was no contents octets before
it determined the value of subsequent octets(0) when it parsed the
long form VarBindList packet.

[bvanassche]

Thanks for having reported this and also for the testcase. Please take a look at the following two commits: 92f0fe9 and baef04f.