Bug 246597 - ASN.1 parse error in message (authPriv mode)
ASN.1 parse error in message (authPriv mode)
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: net-snmp (Show other bugs)
7
i686 Linux
low Severity low
: ---
: ---
Assigned To: Jan Safranek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-03 07:22 EDT by Henry Buerger
Modified: 2008-01-15 06:45 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-15 06:45:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Henry Buerger 2007-07-03 07:22:33 EDT
Hello,

I found a possible bug when authPriv mode (SNMPv3) is configured.
Any request to snmpd failed in this mode. After tuning on full debug output,
I found the following lines:

Jul  3 12:57:06 localhost snmpd[12660]: trace: 
Jul  3 12:57:06 localhost snmpd[12660]: _snmp_parse(): snmp_api.c, 4200: 
Jul  3 12:57:06 localhost snmpd[12660]: snmp_parse: 
Jul  3 12:57:06 localhost snmpd[12660]: Parsed SNMPv3 message (secName:secuRO,
secLevel:authPriv): ASN.1 parse error in message 
Jul  3 12:57:06 localhost snmpd[12660]: trace: 
Jul  3 12:57:06 localhost snmpd[12660]: _sess_process_packet(): snmp_api.c, 5177: 
Jul  3 12:57:06 localhost snmpd[12660]: sess_process_packet: 
Jul  3 12:57:06 localhost snmpd[12660]: parse fail 
Jul  3 12:57:06 localhost snmpd[12660]: trace: 
Jul  3 12:57:06 localhost snmpd[12660]: _sess_process_packet(): snmp_api.c, 5182: 
Jul  3 12:57:06 localhost snmpd[12660]: sess_process_packet: 
Jul  3 12:57:06 localhost snmpd[12660]: post-parse fail 
Jul  3 12:57:06 localhost snmpd[12660]: trace: 
Jul  3 12:57:06 localhost snmpd[12660]: _sess_read(): snmp_api.c, 5449: 
Jul  3 12:57:06 localhost snmpd[12660]: sess_read: 
Jul  3 12:57:06 localhost snmpd[12660]: not reading 5 (fdset 0xbfb87028 set 0) 
Jul  3 12:57:06 localhost snmpd[12660]: trace: 
Jul  3 12:57:06 localhost snmpd[12660]: snmp_sess_select_info(): snmp_api.c, 5875: 
Jul  3 12:57:06 localhost snmpd[12660]: sess_select: 
Jul  3 12:57:06 localhost snmpd[12660]: for all sessions: 
Jul  3 12:57:06 localhost snmpd[12660]: 10 
Jul  3 12:57:06 localhost snmpd[12660]: 5 

I've used the following RPMs:
net-snmp-utils-5.4-13.fc7
net-snmp-5.4-13.fc7
net-snmp-libs-5.4-13.fc7
net-snmp-perl-5.4-13.fc7

In order to reproduce the possible bug, authPriv mode has to be configured.
Here are the config lines I have used for this:
1. snmpd.conf
rwuser secu
createUser secu MD5 secu-passwd DES secu-passwd
group   secuROgroup    usm	    secuRO
view    enterprise    included   .1.3.6.1.4.1.2021
access  secuROgroup    ""  usm  priv  exact  enterprise none  all

2. ~/.snmp/snmp.conf
defVersion 3
defContext ""
defSecurityName secu
defSecurityLevel authPriv
defAuthType MD5
defPrivType DES
defAuthPassphrase secu-passwd
defPrivPassphrase secu-passwd

3. Query the snmpd:
snmpwalk localhost .1.3.6.1.4.1.2021
  
Actual results: Timeout: No Response from localhost

Expected results: snmpwalk output of the enterprise subtree

Additional info: All works fine if I configure authNoPriv
Comment 1 Jan Safranek 2007-07-31 07:12:04 EDT
I am not able to reproduce the bug in my environment. I have the config files
from step 1. and 2. (there is nothing else in these files) and snmpwalk works.
If I modify the password in ~/.snmp/snmp.conf, I get authentication failure (->
snmpwalk really uses the password from the file and snmpd really checks it). I
have tested it successfully on x86_64 and (virtualized) i386.

Could you please try newer net-snmp-5.4-14 and attach full content of
/etc/snmp/snmpd.conf? And did you modify anything else?
Comment 2 Jan Safranek 2008-01-15 06:45:11 EST
Closing due to reporter inactivity. Feel free to reopen the bug if you are able
to reproduce it and provide the required information.

Note You need to log in before you can comment on or make changes to this bug.