[SNMP4J] Initial SNMPv3 handshake extra step?

Frank Fock fock at agentpp.com
Thu Aug 5 23:33:05 CEST 2010


Hi Scott,

The SNMP4J implementation ist strictly following RFC 3414 which
does not suggest the shortcut NET-SNMP uses.

The use that shortcut with SNMP4J as well, add the following
method to the UsmTimeTable class:

  /**
   * Checks if the engine ID exists in the local cache. If not and
   * <code>discoveryAllowed</code> is true, the engine ID will be added
   * to the cache with the given engineBoots and -Time (both zero by 
default).
   *
   * @param securityEngineID
   *    the engine ID to check.
   * @param discoveryEnabled
   *    true if this method might add the engine ID to the local cache
   *   (side-effect).
   * @param engineBoots
   *    the number of engine boots for the engine ID (zero by default).
   * @param engineTime
   *    the engine time for the engine ID (zero by default).
   * @return
   *    SNMPv3_USM_OK if the engine ID is known by the local cache or has
   *    been added, {@link SnmpConstants#SNMPv3_USM_UNKNOWN_ENGINEID}
   *    otherwise.
   * @since 1.11.2
   */
  public int checkEngineID(OctetString securityEngineID,
                           boolean discoveryAllowed, int engineBoots,
                           int engineTime) {
    if (table.get(securityEngineID) != null) {
      return SnmpConstants.SNMPv3_USM_OK;
    }
    else if (discoveryAllowed) {
      addEntry(new UsmTimeEntry(securityEngineID, engineBoots, engineTime));
      return SnmpConstants.SNMPv3_USM_OK;
    }
    return SnmpConstants.SNMPv3_USM_UNKNOWN_ENGINEID;
  }
}

Then change the USM class in line 554 and call the new method with:
    if ((securityEngineID.length() == 0) ||
        (timeTable.checkEngineID(securityEngineID,
                                 isEngineDiscoveryEnabled(),
         usmSecurityParameters.getAuthoritativeEngineBoots(),
         usmSecurityParameters.getAuthoritativeEngineTime()) !=
         SnmpConstants.SNMPv3_USM_OK)) {

This should do the trick.

Best regards,
Frank

Mackay, Scott schrieb:
> Hi, related to my notInTimeWindow question....
>
> Wiresharking the initial exchange I see a bit of an oddity when compared to a net-snmp get request.
>
> The first step for both seems ok, sending an empty get request, the engine sending a report back about unknown engined ids.
> The next step is send the actual get requested, with the engine id and the user...here is the difference though:
>    snmp4j - it sends the request with no boots or time values (0) even though those were send with that reply gotten
>    net-snmp - it fills out the boots and time entries.
> The result is that snmp4j gets rejected with a usmStatsNotInTimeWindows, fills in the values and then finally sends that and gets accepted.
>
> all of this is within the library's handshaking, not user code.
>
> Is there any reason/flag to make snmp4j fill in those fields in step 2 instead of requiring that additional step?
>
> -Scott
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
>   





More information about the SNMP4J mailing list