noAuthNoPriv user-only

[Hafler]

I am attempting to work with a device that has snmpv3 configured, but only accepts a username. I can test the device just fine with the following

snmpwalk -v3 -l noAuthNoPriv -u <snmp_user> <ip> sysContact.0                                                                                                                                                                                           (1s 919ms)
SNMPv2-MIB::sysContact.0 = STRING:

My init looks like this:

  Net::SNMP::Session.open(
    peername: @params[:ip_address],
    port: @params[:port].blank? ? 161 : @params[:port],
    version: '3',
    security_level: Net::SNMP::Constants::SNMP_SEC_LEVEL_NOAUTH,
    username: @params[:username],
    auth_protocol: nil,
    auth_password: nil,
    priv_password: nil,
    priv_protocol: nil
  )

When I attempt to poll, i get a snmp_synch error. After some investigation, it appears that the username is not passed. I believe I found where it does this:

unless @sess.securityLevel == Constants::SNMP_SEC_LEVEL_NOAUTH
  options[:auth_password] ||= options[:password]  # backward compatability
  if options[:username].nil? or options[:auth_password].nil?
    raise Net::SNMP::Error.new "SecurityLevel requires username and password"
  end
  if options[:username]
    @sess.securityName = FFI::MemoryPointer.from_string(options[:username])
    @sess.securityNameLen = options[:username].length
  end

How would I process a device access method like this?

[Jed-Giblin]

To elaborate, this isn't a bug. The SNMP RFC explicitly enforces that passphrases contain at least 8 characters.

https://tools.ietf.org/html/rfc3414

Appendix A describes an algorithm for mapping a user "password" to a
   16/20 octet value for use as either a user's authentication key or
   privacy key (or both).  Note however, that using the same password
   (and therefore the same key) for both authentication and privacy is
   very poor security practice and should be strongly discouraged.
   Passwords are often generated, remembered, and input by a human.
   Human-generated passwords may be less than the 16/20 octets required
   by the authentication and privacy protocols, and brute force attacks
   can be quite easy on a relatively short ASCII character set.
   Therefore, the algorithm is Appendix A performs a transformation on
   the password.  If the Appendix A algorithm is used, SNMP
   implementations (and SNMP configuration applications) must ensure
   that passwords are at least 8 characters in length.  Please note that
   longer passwords with repetitive strings may result in exactly the
   same key.  For example, a password 'bertbert' will result in exactly
   the same key as password 'bertbertbert'.

This is actually a bug on the end device for allowing it.

[Jed-Giblin]

I was able to dive back in and understand that the problem is actually with net-snmp2 and how it determines which properties to set using the C wrapper. This is fixed by #6