snmpinform sends PDUs containing a GET request SNMP_MSG_GET

[Rudolf]

I am writing a Trap Receiver and was not able to receive an INFORM. I figured out that the command code contained in the PDU was not the 166 as it should be but I received 160.
I thought that maybe I did something wrong, but when i used another program (mibbrowser) to send an inform trap, i got the correct code of 166.
I then figured out, that this behaviour only happens when version 3 is used.
Maybe I am getting something wrong but I really think that this is a bug in the package shipped with Ubuntu and I think that should really not be the case.

#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0) /* a0=160 */
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1) /* a1=161 */
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2) /* a2=162 */
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3) /* a3=163 */
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5) /* a5=165 */
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6) /* a6=166 */
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7) /* a7=167 */

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: snmp 5.9.1+dfsg-1ubuntu2.6
ProcVersionSignature: Ubuntu 6.5.0-35.35~22.04.1-generic 6.5.13
Uname: Linux 6.5.0-35-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Fri May 24 12:42:33 2024
InstallationDate: Installed on 2022-08-17 (646 days ago)
InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1)
ProcEnviron:
 LANGUAGE=de_AT:de
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_AT.UTF-8
 SHELL=/bin/bash
SourcePackage: net-snmp
UpgradeStatus: No upgrade log present (probably fresh install)

[Sergio Durigan Junior (sergiodj)]

Hello Rudolf,

Thank you for this bug report. Would you be able to provide a small reproducer for the problem you're experiencing? This would make it much easier for us to understand the issue and try to find a fix for it.

Also, since you appear comfortable dealing with source code, would you mind taking a look at the upstream project and seeing if there's any similar bug reported?

I am going to set the status of this bug to Incomplete to reflect the fact that we're waiting on more information from your side; please set its status back to New once you've provided the requested data.

Thanks!

[Rudolf (rudolf97)]

Hello Sergio,

Thank you for your answer. I would also consider myself as being comfortable with source code. But to be honest, I am quite new to the net-snmp world and have very little experience, so maybe the blame is on me and I understand something wrong.

I setup a trap receiver similar to the snmptrapd (using netsnmp_transport_open_server and snmp_add):
For receiving traps the callback used is:
int process(int op, netsnmp_session* session, int reqid, netsnmp_pdu* rawPDU, void* magic);

When sending traps or informs using version 3 of the protocol, I can cleary see that something is processed in my pre_parse and post_parse functions containing a PDU with command 0 or 160.

Depending on the isAuthoritative value of the created session the PDU gets either passed to my process function or not.
But why am I receiving a GET PDU in the first place instead of a version 3 TRAP/INFORM ?
Is this correct and I am doing something wrong when it comes to receiving version 3 traps, or is this behavior wrong?

If I am wrong here, then sorry for wasting your time. Maybe someone could then tell me how to properly receive version 3 traps/informs.

Thanks in advance!

[Athos Ribeiro (athos-ribeiro)]

Hi Rudolf,

would you mind providing the actual reproducer with clear steps on how to run them so we can reproduce it locally and get a better understanding on the issue you have been facing?

This could be a short script/program we could run in a fresh jammy install that would result in reproducing the behavior you have been experiencing. It would also be nice to explicitly show what the expected outcome should be and what we are seeing instead.

Once you provide the requested data, please, move this bug status back to new.

Thank you!