net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: How to enable logging with verbose and log rations in net-snmp daemon in snmpd.conf for

[Suresh <skj...@ho...>]

Hi Anyone able enable logging with verbose and log rotations in net-snmp daemon.
from snmpd.conf
________________________________
From: Suresh <skj...@ho...>
Sent: Tuesday, March 15, 2022 7:48 PM
To: net...@li... <net...@li...>; net...@li... <net...@li...>
Subject: How to enable logging with verbose and log rations in net-snmp daemon in snmpd.conf for

Hello
I'm using net-snmp version:  5.9.1 service with extended my enterprise specific mibs for snmpwalk/get/set
I want enable logs with rotation policy and verbose  level.

Example
Log file name  rataiotn with date_time and verbose leve debug, error level or info level.

What parameter i need to set in snmpd.conf or any other way programmatically or using configuration
i try to run snmpd.exe with  -Lf D:\snmplog\snmpd.log

But want to know how i rotate log file if log file size reach say 1 MB.
like snmd_15_3_2022_18.30.log size exceed 1 MB.

Also which parameter to set in snmpd.conf for verbose level and log file size.


Thanks
Suresh

How to enable logging with verbose and log rations in net-snmp daemon in snmpd.conf for

[Suresh <skj...@ho...>]

Hello
I'm using net-snmp version:  5.9.1 service with extended my enterprise specific mibs for snmpwalk/get/set
I want enable logs with rotation policy and verbose  level.

Example
Log file name  rataiotn with date_time and verbose leve debug, error level or info level.

What parameter i need to set in snmpd.conf or any other way programmatically or using configuration
i try to run snmpd.exe with  -Lf D:\snmplog\snmpd.log

But want to know how i rotate log file if log file size reach say 1 MB.
like snmd_15_3_2022_18.30.log size exceed 1 MB.

Also which parameter to set in snmpd.conf for verbose level and log file size.


Thanks
Suresh

Fwd: journalctl error | tcpConnectionTable insert (-1)

[Ricky C. <ric...@pu...>]

I am wondering if there is a solution to my problem described below. Currently I've had to completely disable snmpd on a production server and use a different form of monitoring. 


From: "Ricky Cousins" <ric...@pu...> 
To: "Paul Herring" <pau...@gm...> 
Cc: "net-snmp-users" <net...@li...> 
Sent: Friday, February 25, 2022 3:10:11 PM 
Subject: Re: journalctl error | tcpConnectionTable insert (-1) 

I have reduced the logging level with -LS3d and am still seeing a flood of errors. This causes a flickering in our monitoring system causing it to think the system is down. 


From: "Paul Herring" <pau...@gm...> 
To: "Ricky Cousins" <ric...@pu...> 
Cc: "net-snmp-users" <net...@li...> 
Sent: Thursday, February 24, 2022 4:38:50 PM 
Subject: Re: journalctl error | tcpConnectionTable insert (-1) 

Are you logging debug messages? 

[ https://github.com/net-snmp/net-snmp/blob/7fe7a78eb113fa752c224b358b931b6ef8530e29/snmplib/container.c#L347 | https://github.com/net-snmp/net-snmp/blob/7fe7a78eb113fa752c224b358b931b6ef8530e29/snmplib/container.c#L347 ] 

If so, on a production system you should probably reduce the amount of logging that's happening. 



On Thu, Feb 24, 2022 at 2:31 PM Ricky Cousins < [ mailto:ric...@pu... | ric...@pu... ] > wrote: 



Greetings, 

I currently have a situation where we have many TCP connections at once and seem to get many errors related to 'tcpConnectionTable'. It seems the connection table gets full and I would like to resolve this. If I am not mistaken, I cannot simply disable this specific piece of the MIB. 

Below is the error: 
$ journalctl --unit=snmpd.service -n 20
--- snip ---
(host.domain) snmpd[27055]: error on subcontainer 'tcpConnectionTable' insert (-1)
--- snip --- 

_______________________________________________ 
Net-snmp-users mailing list 
[ mailto:Net...@li... | Net...@li... ] 
Please see the following page to unsubscribe or change other options: 
[ https://lists.sourceforge.net/lists/listinfo/net-snmp-users | https://lists.sourceforge.net/lists/listinfo/net-snmp-users ] 





-- 
PJH 



_______________________________________________ 
Net-snmp-users mailing list 
Net...@li... 
Please see the following page to unsubscribe or change other options: 
https://lists.sourceforge.net/lists/listinfo/net-snmp-users 

Re: SNMPv3 context details are not removing from cache

[chandrasekharreddy c. <cha...@ho...>]

Hi team,

Did you get a chance to look at the mail thread.

Get Outlook for Android<https://aka.ms/ghei36>
________________________________
From: chandrasekharreddy chinnapareddygari <cha...@ho...>
Sent: Wednesday, February 16, 2022 7:29:52 PM
To: Net...@li... <Net...@li...>; net...@li... <net...@li...>
Subject: SNMPv3 context details are not removing from cache

Hi all,

I have a requirement not to restart snmpd for SNMP config changes.
Am using the SIGHUP signal to reread for any snmp configuration changes.
I was facing two issues while using SIGHUP.
1. The issue was existing snmpv3 details that were not updating the net-snmp cache. used clear_user_list() to clear users details. The patch is in attachments. Is this the correct way?
2. SNMP context details are not removed from the net-snmp cache after deleting context details.
do we have any API to clear SNMPv3 context details from cache?

Please share API or any other way to solve this problem.


Thanks,
Chandra.




























Thanks

Chandra Sekhar

SNMPv3 context details are not removing from cache

[chandrasekharreddy c. <cha...@ho...>]

Hi all,

I have a requirement not to restart snmpd for SNMP config changes.
Am using the SIGHUP signal to reread for any snmp configuration changes.
I was facing two issues while using SIGHUP.
1. The issue was existing snmpv3 details that were not updating the net-snmp cache. used clear_user_list() to clear users details. The patch is in attachments. Is this the correct way?
2. SNMP context details are not removed from the net-snmp cache after deleting context details.
do we have any API to clear SNMPv3 context details from cache?

Please share API or any other way to solve this problem.


Thanks,
Chandra.




























Thanks

Chandra Sekhar

Re: Node Sub-Agent on Windows

[Ian C <mc...@ya...>]

 UPDATE
Turns out that I am able to query from the cmd shell snmpwalk, but not from Manage Engine GUI.  So leads me to suspect it is ok after all.

Thanks,


    On Wednesday, February 9, 2022, 12:45:34 p.m. EST, Ian C via Net-snmp-coders <net...@li...> wrote:  
 
 
I'm using the node net-snmp package  to create a simple subagent but I cannot query its only table provider (Error in packet... No such variable name in MIB).  I have installed net-snmp and registered it, I am able to  query simple things such as uptime:
C:\usr\etc\snmp>snmpwalk -v1 -c public 127.0.0.1  .1.3.6.1.2.1.1.3
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (306196) 0:51:01.96

So, at least I know the snmpd is running and responding.
My snmpd.conf:rwcommunity  public  
master agentx
agentXSocket tcp:localhost:705load  12 12 12
Any thoughts would be greatly appreciated.
thanksIan in Ottawa


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
net-snmp

JavaScript implementation of the Simple Network Management Protocol (SNMP). Latest version: 3.5.8, last publishe...
 |

 |

 |


Test table query:C:\usr\etc\snmp>snmpget -v1 -c public 127.0.0.1 1.3.6.1.4.1.8072.9999.9999.2
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: NET-SNMP-MIB::netSnmpPlaypen.2



Js subagent:let snmp = require("net-snmp");

export class SNMPServer {  private static instance: SNMPServer;  subagent: null | any  mib: null | any  private constructor() {    this.subagent = snmp.createSubagent(suboptions);  }  public static getInstance(): SNMPServer {    if (!SNMPServer.instance) {        SNMPServer.instance = new SNMPServer();    }    return SNMPServer.instance;  }
  public openSubAgent() {    this.subagent.open( this.openCallback );  }

  openCallback = ( error: any, data: any ) => {    if ( error ) {        console.error('subagent.open() ERROR:' +error);    } else {        console.log('subagent.open() OK...'+data)        this.subagent.registerProvider (myTableProvider, registerProviderCallback);        this.mib = this.subagent.getMib();        if (this.mib != null) {            this.mib.addTableRow ("smallIfTable", [1, "IAN", 12]);            console.log("SNMP Server: SubAgent-MIB Invoked");        } else {            console.error ("Subagent Get MIB failure");        }    }  }
  public closeSubAgent() {    this.subagent.unregisterProvider(myTableProvider, ()=>{} );    this.subagent.close (() => {});  }}
// Default suboptionsvar suboptions = {    debug: true,    master: "localhost",    masterPort: 705,    timeout: 0,    description: "Node net-snmp AgentX sub-agent"};
var registerProviderCallback = function (error: any, data: any) {    if ( error ) {        console.error ('CREATE SUBAGENT ERROR '+error);    } else {        console.log ('OK SNMP CREATE SUBAGENT '+JSON.stringify(data, null, 2));    }};
var myTableProvider = {    name: "smallIfTable",    type: snmp.MibProviderType.Table,    oid: "1.3.6.1.4.1.8072.9999.9999.2",    tableColumns: [        {            number: 1,            name: "CampField1",            type: snmp.ObjectType.Integer        },        {            number: 2,            name: "CampField2",            type: snmp.ObjectType.OctetString        },        {            number: 3,            name: "CampField3",            type: snmp.ObjectType.Integer        }    ],    tableIndex: [        {            columnName: "CampField1"        }    ],    handler: function (mibRequest: any) {        console.log('MibRequest!')        // e.g. can update the table before responding to the request here        mibRequest.done();    }};



_______________________________________________
Net-snmp-coders mailing list
Net...@li...
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
  

Node Sub-Agent on Windows

[Ian C <mc...@ya...>]

I'm using the node net-snmp package  to create a simple subagent but I cannot query its only table provider (Error in packet... No such variable name in MIB).  I have installed net-snmp and registered it, I am able to  query simple things such as uptime:
C:\usr\etc\snmp>snmpwalk -v1 -c public 127.0.0.1  .1.3.6.1.2.1.1.3
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (306196) 0:51:01.96

So, at least I know the snmpd is running and responding.
My snmpd.conf:rwcommunity  public  
master agentx
agentXSocket tcp:localhost:705load  12 12 12
Any thoughts would be greatly appreciated.
thanksIan in Ottawa


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
net-snmp

JavaScript implementation of the Simple Network Management Protocol (SNMP). Latest version: 3.5.8, last publishe...
 |

 |

 |


Test table query:C:\usr\etc\snmp>snmpget -v1 -c public 127.0.0.1 1.3.6.1.4.1.8072.9999.9999.2
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: NET-SNMP-MIB::netSnmpPlaypen.2



Js subagent:let snmp = require("net-snmp");

export class SNMPServer {  private static instance: SNMPServer;  subagent: null | any  mib: null | any  private constructor() {    this.subagent = snmp.createSubagent(suboptions);  }  public static getInstance(): SNMPServer {    if (!SNMPServer.instance) {        SNMPServer.instance = new SNMPServer();    }    return SNMPServer.instance;  }
  public openSubAgent() {    this.subagent.open( this.openCallback );  }

  openCallback = ( error: any, data: any ) => {    if ( error ) {        console.error('subagent.open() ERROR:' +error);    } else {        console.log('subagent.open() OK...'+data)        this.subagent.registerProvider (myTableProvider, registerProviderCallback);        this.mib = this.subagent.getMib();        if (this.mib != null) {            this.mib.addTableRow ("smallIfTable", [1, "IAN", 12]);            console.log("SNMP Server: SubAgent-MIB Invoked");        } else {            console.error ("Subagent Get MIB failure");        }    }  }
  public closeSubAgent() {    this.subagent.unregisterProvider(myTableProvider, ()=>{} );    this.subagent.close (() => {});  }}
// Default suboptionsvar suboptions = {    debug: true,    master: "localhost",    masterPort: 705,    timeout: 0,    description: "Node net-snmp AgentX sub-agent"};
var registerProviderCallback = function (error: any, data: any) {    if ( error ) {        console.error ('CREATE SUBAGENT ERROR '+error);    } else {        console.log ('OK SNMP CREATE SUBAGENT '+JSON.stringify(data, null, 2));    }};
var myTableProvider = {    name: "smallIfTable",    type: snmp.MibProviderType.Table,    oid: "1.3.6.1.4.1.8072.9999.9999.2",    tableColumns: [        {            number: 1,            name: "CampField1",            type: snmp.ObjectType.Integer        },        {            number: 2,            name: "CampField2",            type: snmp.ObjectType.OctetString        },        {            number: 3,            name: "CampField3",            type: snmp.ObjectType.Integer        }    ],    tableIndex: [        {            columnName: "CampField1"        }    ],    handler: function (mibRequest: any) {        console.log('MibRequest!')        // e.g. can update the table before responding to the request here        mibRequest.done();    }};

Re: Re-registering sysContact and sysLocation with subagent

[Winston G. <wg...@en...>]

It turns out I never did have it working.  I'm trying to reregister sysContact and/or sysLocation from my subagent running under a master agent.  I think reregistering a system oid via a subagent is impossible.

I set up a sample subagent project in c as described here:  http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_Subagent.  I set up debugging.  When I try to unregister an object using unregister_mib(), it eventually calls unregister_mib_context() with null context, which calls netsnmp_subtree_find().  This returns a subtree with a single oid {1,}, or this plus a subtree consisting of the newly registered element in the sample code, if I register the sample element first.  It tries to find the sysLocation node to unregister in this tree, which fails, since the returned tree only consists of objects I've registered in the subagent.  If I replace sysLocation with nstAgentSubagentObject (the newly registered element from the example code) it does successfully unregister.

I turned on debugging in snmpd for register_mib, to verify that sysLocation and sysContact are being registered in null context by the master agentx:

register_mib:
Feb 08 09:01:25 emma snmpd[169114]: registering "mibII/sysLocation" at
Feb 08 09:01:25 emma snmpd[169114]: iso.3.6.1.2.1.1.6
Feb 08 09:01:25 emma snmpd[169114]:  with context "(null)"

I don't think it's possible to unregister or reregister sysLocation or sysContact from a subagent, if the node was initially registered in the master agentx.

     Winston




________________________________
From: Winston Gadsby <wg...@en...>
Sent: Wednesday, February 2, 2022 1:29 PM
To: Magnus Fromreide <ma...@ly...>
Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
Subject: Re: Re-registering sysContact and sysLocation with subagent

You're right.  It looks like it's expecting an unsigned long array (c_oid_p in the python wrapper).  Here's what I did in python.  First, I defined the unregister_mib arguments for the ctypes translation:

$ libnsa.unregister_mib.argtypes = [c_oid_p, ctypes.c_size_t]
$ libnsa.unregister_mib.restype = ctypes.c_int

Then I defined the oid vars:

$ oid = (c_oid * MAX_OID_LEN)()
$ oid_len = ctypes.c_size_t(MAX_OID_LEN)

c_oid is the ctypes definition for oid, ctypes.c_ulong.  Then c_oid_p is a pointer to it.  Then I used read_objid to translate from the text to the unsigned long format:

$ libnsa.read_objid(b"SNMPv2-MIB::sysContact", ctypes.cast(ctypes.byref(oid), c_oid_p), ctypes.byref(oid_len))

The result looks correct:  [1, 3, 6, 1, 2, 1, 1, 4, ...].  Then I used this oid and oid_len in unregister_mib, translating the args appropriately:

$ result = libnsa.unregister_mib(ctypes.cast(ctypes.byref(oid), c_oid_p), oid_len)

The result is still always -1 (MIB_NOSUCHREGISTRATION).  However, it looks like it works, at least for sysContact.  If I ignore the error and reregister sysContact with my subagent it works.  I can change it in my program and see the change in a mib browser.

The very strange thing is I'm doing this with two separate, similar variables - sysContact and sysLocation.  SysContact always works, with the exception of the above error.  SysLocation always gives me another error when I start the agent:  registering pdu failed 263, and I am unable to change its value in my application.  When I started all this, and didn't do any unregister_mib calls, I'd get two of the "registering pdu failed 263" errors, I'm assuming one for sysContact and one for sysLocation.  So it looks like sysContact is now working, but sysLocation is still registered with the master agent.  I'm tracing this out and hoping it is a simple typo somewhere with sysLocation.

What type of agentx library did you have in mind?

Thanks again.

     Winston




________________________________
From: Magnus Fromreide <ma...@ly...>
Sent: Tuesday, February 1, 2022 8:56 PM
To: Winston Gadsby <wg...@en...>
Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
Subject: Re: Re-registering sysContact and sysLocation with subagent

On Tue, Feb 01, 2022 at 02:58:14PM +0000, Winston Gadsby wrote:
> Hi,
> Thanks for the replies.  I'm working on trying to unregister the oid according to the link given below, using unregister_mib(oid, len).  I'm assuming the oid can be specified as a byte-string or integer array.  The difficulty I'm having is probably related to the ctypes translation mechanism from python.  Here's what I'm using in python.  The ctypes module enables the translation from the C libraries to python and imports the net-snmp space as libnsa:
>
> import ctypes
> from netsnmpapi import *
> import netsnmpvartypes
> libnsa = ctypes.cdll.LoadLibrary(ctypes.util.find_library("netsnmpagent"))
> ...
> {code that registers oids from new mib}
> ...
> {start subagent}
> print(libnsa.unregister_mib(b("SNMPv2-MIB::sysContact"), len("SNMPv2-MIB::sysContact"))
>
> This always returns -1, whether I unregister before starting the agent or after.  I've also tried unregistering some objects from my mib that were previously registered with the same result.

This looks like you are calling the unregister_mib c function in a dlopened
version of netsnmp.

That function takes a parameter of type array of oid, what exact type oid is
depends on how your netsnmp library was built but it usually is unsigned long.
That array should contain the numerical OID value, in your case that would be
{ 1, 3, 6, 1, 2, 1, 1, 4 } but honestly I think an agentx library would serve
you better.

/MF



>      Winston
> ________________________________
> From: Larry Hayes <lh...@gm...>
> Sent: Friday, January 28, 2022 4:48 PM
> To: Winston Gadsby <wg...@en...>
> Cc: net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
>
> Someone just this month asked about taking control of the system description.  I would suspect that sysContact and sysLocation would follow the same way.
>
> Their solution was to unregister the OID then register your own handler.
>
>
> unregister_mib() API.
>
> https://sourceforge.net/p/net-snmp/mailman/message/37598495/
>
>
> It is a hassle, but you can also control the values of those inside of a snmpd.local.conf file.
>
> syscontact Nobody <no...@de...ll>
>
> Your  agent would write the values to that file then SIGHUP the snmpd to pick up the changes.
>
>
> On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...<mailto:wg...@en...>> wrote:
> Hi,
> I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.
>
> I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.
>
> How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.
>
> Is there perhaps a better way of going about doing this?
>
> I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,
>
> Winston
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...<mailto:Net...@li...>
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Re-registering sysContact and sysLocation with subagent

[Winston G. <wg...@en...>]

Thank you - that seems to have worked.

     Winston
________________________________
From: Magnus Fromreide <ma...@ly...>
Sent: Tuesday, February 8, 2022 12:47 PM
To: Winston Gadsby <wg...@en...>
Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
Subject: Re: Re-registering sysContact and sysLocation with subagent

On Tue, Feb 08, 2022 at 02:28:57PM +0000, Winston Gadsby wrote:
> It turns out I never did have it working.  I'm trying to reregister sysContact and/or sysLocation from my subagent running under a master agent.  I think reregistering a system oid via a subagent is impossible.

It is quite possible.

You should just set the priority.

The attached files can be compiled using

gcc netsnmptmp.348085.c sysContact.c -o sysContact -lnetsnmpagent -lnetsnmp

and then run like

./sysContact -f -Lo -Dagentx

(the arguments are just to make it run in the foreground and log agentx
 interactions)

The important part - as I said last week - is to use a lower priority than
the one the agent uses so the magic line is sysContact.c:27.

/MF

> I set up a sample subagent project in c as described here:  http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_Subagent.  I set up debugging.  When I try to unregister an object using unregister_mib(), it eventually calls unregister_mib_context() with null context, which calls netsnmp_subtree_find().  This returns a subtree with a single oid {1,}, or this plus a subtree consisting of the newly registered element in the sample code, if I register the sample element first.  It tries to find the sysLocation node to unregister in this tree, which fails, since the returned tree only consists of objects I've registered in the subagent.  If I replace sysLocation with nstAgentSubagentObject (the newly registered element from the example code) it does successfully unregister.
>
> I turned on debugging in snmpd for register_mib, to verify that sysLocation and sysContact are being registered in null context by the master agentx:
>
> register_mib:
> Feb 08 09:01:25 emma snmpd[169114]: registering "mibII/sysLocation" at
> Feb 08 09:01:25 emma snmpd[169114]: iso.3.6.1.2.1.1.6
> Feb 08 09:01:25 emma snmpd[169114]:  with context "(null)"
>
> I don't think it's possible to unregister or reregister sysLocation or sysContact from a subagent, if the node was initially registered in the master agentx.
>
>      Winston
>
>
>
>
> ________________________________
> From: Winston Gadsby <wg...@en...>
> Sent: Wednesday, February 2, 2022 1:29 PM
> To: Magnus Fromreide <ma...@ly...>
> Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
>
> You're right.  It looks like it's expecting an unsigned long array (c_oid_p in the python wrapper).  Here's what I did in python.  First, I defined the unregister_mib arguments for the ctypes translation:
>
> $ libnsa.unregister_mib.argtypes = [c_oid_p, ctypes.c_size_t]
> $ libnsa.unregister_mib.restype = ctypes.c_int
>
> Then I defined the oid vars:
>
> $ oid = (c_oid * MAX_OID_LEN)()
> $ oid_len = ctypes.c_size_t(MAX_OID_LEN)
>
> c_oid is the ctypes definition for oid, ctypes.c_ulong.  Then c_oid_p is a pointer to it.  Then I used read_objid to translate from the text to the unsigned long format:
>
> $ libnsa.read_objid(b"SNMPv2-MIB::sysContact", ctypes.cast(ctypes.byref(oid), c_oid_p), ctypes.byref(oid_len))
>
> The result looks correct:  [1, 3, 6, 1, 2, 1, 1, 4, ...].  Then I used this oid and oid_len in unregister_mib, translating the args appropriately:
>
> $ result = libnsa.unregister_mib(ctypes.cast(ctypes.byref(oid), c_oid_p), oid_len)
>
> The result is still always -1 (MIB_NOSUCHREGISTRATION).  However, it looks like it works, at least for sysContact.  If I ignore the error and reregister sysContact with my subagent it works.  I can change it in my program and see the change in a mib browser.
>
> The very strange thing is I'm doing this with two separate, similar variables - sysContact and sysLocation.  SysContact always works, with the exception of the above error.  SysLocation always gives me another error when I start the agent:  registering pdu failed 263, and I am unable to change its value in my application.  When I started all this, and didn't do any unregister_mib calls, I'd get two of the "registering pdu failed 263" errors, I'm assuming one for sysContact and one for sysLocation.  So it looks like sysContact is now working, but sysLocation is still registered with the master agent.  I'm tracing this out and hoping it is a simple typo somewhere with sysLocation.
>
> What type of agentx library did you have in mind?
>
> Thanks again.
>
>      Winston
>
>
>
>
> ________________________________
> From: Magnus Fromreide <ma...@ly...>
> Sent: Tuesday, February 1, 2022 8:56 PM
> To: Winston Gadsby <wg...@en...>
> Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
>
> On Tue, Feb 01, 2022 at 02:58:14PM +0000, Winston Gadsby wrote:
> > Hi,
> > Thanks for the replies.  I'm working on trying to unregister the oid according to the link given below, using unregister_mib(oid, len).  I'm assuming the oid can be specified as a byte-string or integer array.  The difficulty I'm having is probably related to the ctypes translation mechanism from python.  Here's what I'm using in python.  The ctypes module enables the translation from the C libraries to python and imports the net-snmp space as libnsa:
> >
> > import ctypes
> > from netsnmpapi import *
> > import netsnmpvartypes
> > libnsa = ctypes.cdll.LoadLibrary(ctypes.util.find_library("netsnmpagent"))
> > ...
> > {code that registers oids from new mib}
> > ...
> > {start subagent}
> > print(libnsa.unregister_mib(b("SNMPv2-MIB::sysContact"), len("SNMPv2-MIB::sysContact"))
> >
> > This always returns -1, whether I unregister before starting the agent or after.  I've also tried unregistering some objects from my mib that were previously registered with the same result.
>
> This looks like you are calling the unregister_mib c function in a dlopened
> version of netsnmp.
>
> That function takes a parameter of type array of oid, what exact type oid is
> depends on how your netsnmp library was built but it usually is unsigned long.
> That array should contain the numerical OID value, in your case that would be
> { 1, 3, 6, 1, 2, 1, 1, 4 } but honestly I think an agentx library would serve
> you better.
>
> /MF
>
>
>
> >      Winston
> > ________________________________
> > From: Larry Hayes <lh...@gm...>
> > Sent: Friday, January 28, 2022 4:48 PM
> > To: Winston Gadsby <wg...@en...>
> > Cc: net...@li... <net...@li...>
> > Subject: Re: Re-registering sysContact and sysLocation with subagent
> >
> > Someone just this month asked about taking control of the system description.  I would suspect that sysContact and sysLocation would follow the same way.
> >
> > Their solution was to unregister the OID then register your own handler.
> >
> >
> > unregister_mib() API.
> >
> > https://sourceforge.net/p/net-snmp/mailman/message/37598495/
> >
> >
> > It is a hassle, but you can also control the values of those inside of a snmpd.local.conf file.
> >
> > syscontact Nobody <no...@de...ll>
> >
> > Your  agent would write the values to that file then SIGHUP the snmpd to pick up the changes.
> >
> >
> > On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...<mailto:wg...@en...>> wrote:
> > Hi,
> > I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.
> >
> > I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.
> >
> > How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.
> >
> > Is there perhaps a better way of going about doing this?
> >
> > I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,
> >
> > Winston
> >
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...<mailto:Net...@li...>
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>
>
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Please remove me from this mailing list

[Robi G. <ro...@ma...>]

Re: Re-registering sysContact and sysLocation with subagent

[Magnus F. <ma...@ly...>]

On Tue, Feb 08, 2022 at 02:28:57PM +0000, Winston Gadsby wrote:
> It turns out I never did have it working.  I'm trying to reregister sysContact and/or sysLocation from my subagent running under a master agent.  I think reregistering a system oid via a subagent is impossible.

It is quite possible.

You should just set the priority.

The attached files can be compiled using

gcc netsnmptmp.348085.c sysContact.c -o sysContact -lnetsnmpagent -lnetsnmp

and then run like

./sysContact -f -Lo -Dagentx

(the arguments are just to make it run in the foreground and log agentx
 interactions)

The important part - as I said last week - is to use a lower priority than
the one the agent uses so the magic line is sysContact.c:27.

/MF

> I set up a sample subagent project in c as described here:  http://www.net-snmp.org/wiki/index.php/TUT:Writing_a_Subagent.  I set up debugging.  When I try to unregister an object using unregister_mib(), it eventually calls unregister_mib_context() with null context, which calls netsnmp_subtree_find().  This returns a subtree with a single oid {1,}, or this plus a subtree consisting of the newly registered element in the sample code, if I register the sample element first.  It tries to find the sysLocation node to unregister in this tree, which fails, since the returned tree only consists of objects I've registered in the subagent.  If I replace sysLocation with nstAgentSubagentObject (the newly registered element from the example code) it does successfully unregister.
> 
> I turned on debugging in snmpd for register_mib, to verify that sysLocation and sysContact are being registered in null context by the master agentx:
> 
> register_mib:
> Feb 08 09:01:25 emma snmpd[169114]: registering "mibII/sysLocation" at
> Feb 08 09:01:25 emma snmpd[169114]: iso.3.6.1.2.1.1.6
> Feb 08 09:01:25 emma snmpd[169114]:  with context "(null)"
> 
> I don't think it's possible to unregister or reregister sysLocation or sysContact from a subagent, if the node was initially registered in the master agentx.
> 
>      Winston
> 
> 
> 
> 
> ________________________________
> From: Winston Gadsby <wg...@en...>
> Sent: Wednesday, February 2, 2022 1:29 PM
> To: Magnus Fromreide <ma...@ly...>
> Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
> 
> You're right.  It looks like it's expecting an unsigned long array (c_oid_p in the python wrapper).  Here's what I did in python.  First, I defined the unregister_mib arguments for the ctypes translation:
> 
> $ libnsa.unregister_mib.argtypes = [c_oid_p, ctypes.c_size_t]
> $ libnsa.unregister_mib.restype = ctypes.c_int
> 
> Then I defined the oid vars:
> 
> $ oid = (c_oid * MAX_OID_LEN)()
> $ oid_len = ctypes.c_size_t(MAX_OID_LEN)
> 
> c_oid is the ctypes definition for oid, ctypes.c_ulong.  Then c_oid_p is a pointer to it.  Then I used read_objid to translate from the text to the unsigned long format:
> 
> $ libnsa.read_objid(b"SNMPv2-MIB::sysContact", ctypes.cast(ctypes.byref(oid), c_oid_p), ctypes.byref(oid_len))
> 
> The result looks correct:  [1, 3, 6, 1, 2, 1, 1, 4, ...].  Then I used this oid and oid_len in unregister_mib, translating the args appropriately:
> 
> $ result = libnsa.unregister_mib(ctypes.cast(ctypes.byref(oid), c_oid_p), oid_len)
> 
> The result is still always -1 (MIB_NOSUCHREGISTRATION).  However, it looks like it works, at least for sysContact.  If I ignore the error and reregister sysContact with my subagent it works.  I can change it in my program and see the change in a mib browser.
> 
> The very strange thing is I'm doing this with two separate, similar variables - sysContact and sysLocation.  SysContact always works, with the exception of the above error.  SysLocation always gives me another error when I start the agent:  registering pdu failed 263, and I am unable to change its value in my application.  When I started all this, and didn't do any unregister_mib calls, I'd get two of the "registering pdu failed 263" errors, I'm assuming one for sysContact and one for sysLocation.  So it looks like sysContact is now working, but sysLocation is still registered with the master agent.  I'm tracing this out and hoping it is a simple typo somewhere with sysLocation.
> 
> What type of agentx library did you have in mind?
> 
> Thanks again.
> 
>      Winston
> 
> 
> 
> 
> ________________________________
> From: Magnus Fromreide <ma...@ly...>
> Sent: Tuesday, February 1, 2022 8:56 PM
> To: Winston Gadsby <wg...@en...>
> Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
> 
> On Tue, Feb 01, 2022 at 02:58:14PM +0000, Winston Gadsby wrote:
> > Hi,
> > Thanks for the replies.  I'm working on trying to unregister the oid according to the link given below, using unregister_mib(oid, len).  I'm assuming the oid can be specified as a byte-string or integer array.  The difficulty I'm having is probably related to the ctypes translation mechanism from python.  Here's what I'm using in python.  The ctypes module enables the translation from the C libraries to python and imports the net-snmp space as libnsa:
> >
> > import ctypes
> > from netsnmpapi import *
> > import netsnmpvartypes
> > libnsa = ctypes.cdll.LoadLibrary(ctypes.util.find_library("netsnmpagent"))
> > ...
> > {code that registers oids from new mib}
> > ...
> > {start subagent}
> > print(libnsa.unregister_mib(b("SNMPv2-MIB::sysContact"), len("SNMPv2-MIB::sysContact"))
> >
> > This always returns -1, whether I unregister before starting the agent or after.  I've also tried unregistering some objects from my mib that were previously registered with the same result.
> 
> This looks like you are calling the unregister_mib c function in a dlopened
> version of netsnmp.
> 
> That function takes a parameter of type array of oid, what exact type oid is
> depends on how your netsnmp library was built but it usually is unsigned long.
> That array should contain the numerical OID value, in your case that would be
> { 1, 3, 6, 1, 2, 1, 1, 4 } but honestly I think an agentx library would serve
> you better.
> 
> /MF
> 
> 
> 
> >      Winston
> > ________________________________
> > From: Larry Hayes <lh...@gm...>
> > Sent: Friday, January 28, 2022 4:48 PM
> > To: Winston Gadsby <wg...@en...>
> > Cc: net...@li... <net...@li...>
> > Subject: Re: Re-registering sysContact and sysLocation with subagent
> >
> > Someone just this month asked about taking control of the system description.  I would suspect that sysContact and sysLocation would follow the same way.
> >
> > Their solution was to unregister the OID then register your own handler.
> >
> >
> > unregister_mib() API.
> >
> > https://sourceforge.net/p/net-snmp/mailman/message/37598495/
> >
> >
> > It is a hassle, but you can also control the values of those inside of a snmpd.local.conf file.
> >
> > syscontact Nobody <no...@de...ll>
> >
> > Your  agent would write the values to that file then SIGHUP the snmpd to pick up the changes.
> >
> >
> > On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...<mailto:wg...@en...>> wrote:
> > Hi,
> > I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.
> >
> > I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.
> >
> > How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.
> >
> > Is there perhaps a better way of going about doing this?
> >
> > I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,
> >
> > Winston
> >
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...<mailto:Net...@li...>
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
> 
> 
> > _______________________________________________
> > Net-snmp-coders mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
> 

Re: Re-registering sysContact and sysLocation with subagent

[Winston G. <wg...@en...>]

You're right.  It looks like it's expecting an unsigned long array (c_oid_p in the python wrapper).  Here's what I did in python.  First, I defined the unregister_mib arguments for the ctypes translation:

$ libnsa.unregister_mib.argtypes = [c_oid_p, ctypes.c_size_t]
$ libnsa.unregister_mib.restype = ctypes.c_int

Then I defined the oid vars:

$ oid = (c_oid * MAX_OID_LEN)()
$ oid_len = ctypes.c_size_t(MAX_OID_LEN)

c_oid is the ctypes definition for oid, ctypes.c_ulong.  Then c_oid_p is a pointer to it.  Then I used read_objid to translate from the text to the unsigned long format:

$ libnsa.read_objid(b"SNMPv2-MIB::sysContact", ctypes.cast(ctypes.byref(oid), c_oid_p), ctypes.byref(oid_len))

The result looks correct:  [1, 3, 6, 1, 2, 1, 1, 4, ...].  Then I used this oid and oid_len in unregister_mib, translating the args appropriately:

$ result = libnsa.unregister_mib(ctypes.cast(ctypes.byref(oid), c_oid_p), oid_len)

The result is still always -1 (MIB_NOSUCHREGISTRATION).  However, it looks like it works, at least for sysContact.  If I ignore the error and reregister sysContact with my subagent it works.  I can change it in my program and see the change in a mib browser.

The very strange thing is I'm doing this with two separate, similar variables - sysContact and sysLocation.  SysContact always works, with the exception of the above error.  SysLocation always gives me another error when I start the agent:  registering pdu failed 263, and I am unable to change its value in my application.  When I started all this, and didn't do any unregister_mib calls, I'd get two of the "registering pdu failed 263" errors, I'm assuming one for sysContact and one for sysLocation.  So it looks like sysContact is now working, but sysLocation is still registered with the master agent.  I'm tracing this out and hoping it is a simple typo somewhere with sysLocation.

What type of agentx library did you have in mind?

Thanks again.

     Winston




________________________________
From: Magnus Fromreide <ma...@ly...>
Sent: Tuesday, February 1, 2022 8:56 PM
To: Winston Gadsby <wg...@en...>
Cc: Larry Hayes <lh...@gm...>; net...@li... <net...@li...>
Subject: Re: Re-registering sysContact and sysLocation with subagent

On Tue, Feb 01, 2022 at 02:58:14PM +0000, Winston Gadsby wrote:
> Hi,
> Thanks for the replies.  I'm working on trying to unregister the oid according to the link given below, using unregister_mib(oid, len).  I'm assuming the oid can be specified as a byte-string or integer array.  The difficulty I'm having is probably related to the ctypes translation mechanism from python.  Here's what I'm using in python.  The ctypes module enables the translation from the C libraries to python and imports the net-snmp space as libnsa:
>
> import ctypes
> from netsnmpapi import *
> import netsnmpvartypes
> libnsa = ctypes.cdll.LoadLibrary(ctypes.util.find_library("netsnmpagent"))
> ...
> {code that registers oids from new mib}
> ...
> {start subagent}
> print(libnsa.unregister_mib(b("SNMPv2-MIB::sysContact"), len("SNMPv2-MIB::sysContact"))
>
> This always returns -1, whether I unregister before starting the agent or after.  I've also tried unregistering some objects from my mib that were previously registered with the same result.

This looks like you are calling the unregister_mib c function in a dlopened
version of netsnmp.

That function takes a parameter of type array of oid, what exact type oid is
depends on how your netsnmp library was built but it usually is unsigned long.
That array should contain the numerical OID value, in your case that would be
{ 1, 3, 6, 1, 2, 1, 1, 4 } but honestly I think an agentx library would serve
you better.

/MF



>      Winston
> ________________________________
> From: Larry Hayes <lh...@gm...>
> Sent: Friday, January 28, 2022 4:48 PM
> To: Winston Gadsby <wg...@en...>
> Cc: net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
>
> Someone just this month asked about taking control of the system description.  I would suspect that sysContact and sysLocation would follow the same way.
>
> Their solution was to unregister the OID then register your own handler.
>
>
> unregister_mib() API.
>
> https://sourceforge.net/p/net-snmp/mailman/message/37598495/
>
>
> It is a hassle, but you can also control the values of those inside of a snmpd.local.conf file.
>
> syscontact Nobody <no...@de...ll>
>
> Your  agent would write the values to that file then SIGHUP the snmpd to pick up the changes.
>
>
> On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...<mailto:wg...@en...>> wrote:
> Hi,
> I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.
>
> I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.
>
> How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.
>
> Is there perhaps a better way of going about doing this?
>
> I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,
>
> Winston
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...<mailto:Net...@li...>
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Re-registering sysContact and sysLocation with subagent

[Magnus F. <ma...@ly...>]

On Tue, Feb 01, 2022 at 02:58:14PM +0000, Winston Gadsby wrote:
> Hi,
> Thanks for the replies.  I'm working on trying to unregister the oid according to the link given below, using unregister_mib(oid, len).  I'm assuming the oid can be specified as a byte-string or integer array.  The difficulty I'm having is probably related to the ctypes translation mechanism from python.  Here's what I'm using in python.  The ctypes module enables the translation from the C libraries to python and imports the net-snmp space as libnsa:
> 
> import ctypes
> from netsnmpapi import *
> import netsnmpvartypes
> libnsa = ctypes.cdll.LoadLibrary(ctypes.util.find_library("netsnmpagent"))
> ...
> {code that registers oids from new mib}
> ...
> {start subagent}
> print(libnsa.unregister_mib(b("SNMPv2-MIB::sysContact"), len("SNMPv2-MIB::sysContact"))
> 
> This always returns -1, whether I unregister before starting the agent or after.  I've also tried unregistering some objects from my mib that were previously registered with the same result.

This looks like you are calling the unregister_mib c function in a dlopened
version of netsnmp.

That function takes a parameter of type array of oid, what exact type oid is
depends on how your netsnmp library was built but it usually is unsigned long.
That array should contain the numerical OID value, in your case that would be
{ 1, 3, 6, 1, 2, 1, 1, 4 } but honestly I think an agentx library would serve
you better.

/MF



>      Winston
> ________________________________
> From: Larry Hayes <lh...@gm...>
> Sent: Friday, January 28, 2022 4:48 PM
> To: Winston Gadsby <wg...@en...>
> Cc: net...@li... <net...@li...>
> Subject: Re: Re-registering sysContact and sysLocation with subagent
> 
> Someone just this month asked about taking control of the system description.  I would suspect that sysContact and sysLocation would follow the same way.
> 
> Their solution was to unregister the OID then register your own handler.
> 
> 
> unregister_mib() API.
> 
> https://sourceforge.net/p/net-snmp/mailman/message/37598495/
> 
> 
> It is a hassle, but you can also control the values of those inside of a snmpd.local.conf file.
> 
> syscontact Nobody <no...@de...ll>
> 
> Your  agent would write the values to that file then SIGHUP the snmpd to pick up the changes.
> 
> 
> On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...<mailto:wg...@en...>> wrote:
> Hi,
> I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.
> 
> I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.
> 
> How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.
> 
> Is there perhaps a better way of going about doing this?
> 
> I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,
> 
> Winston
> 
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...<mailto:Net...@li...>
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Re-registering sysContact and sysLocation with subagent

[Winston G. <wg...@en...>]

Hi,
Thanks for the replies.  I'm working on trying to unregister the oid according to the link given below, using unregister_mib(oid, len).  I'm assuming the oid can be specified as a byte-string or integer array.  The difficulty I'm having is probably related to the ctypes translation mechanism from python.  Here's what I'm using in python.  The ctypes module enables the translation from the C libraries to python and imports the net-snmp space as libnsa:

import ctypes
from netsnmpapi import *
import netsnmpvartypes
libnsa = ctypes.cdll.LoadLibrary(ctypes.util.find_library("netsnmpagent"))
...
{code that registers oids from new mib}
...
{start subagent}
print(libnsa.unregister_mib(b("SNMPv2-MIB::sysContact"), len("SNMPv2-MIB::sysContact"))

This always returns -1, whether I unregister before starting the agent or after.  I've also tried unregistering some objects from my mib that were previously registered with the same result.

     Winston
________________________________
From: Larry Hayes <lh...@gm...>
Sent: Friday, January 28, 2022 4:48 PM
To: Winston Gadsby <wg...@en...>
Cc: net...@li... <net...@li...>
Subject: Re: Re-registering sysContact and sysLocation with subagent

Someone just this month asked about taking control of the system description.  I would suspect that sysContact and sysLocation would follow the same way.

Their solution was to unregister the OID then register your own handler.


unregister_mib() API.

https://sourceforge.net/p/net-snmp/mailman/message/37598495/


It is a hassle, but you can also control the values of those inside of a snmpd.local.conf file.

syscontact Nobody <no...@de...ll>

Your  agent would write the values to that file then SIGHUP the snmpd to pick up the changes.


On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...<mailto:wg...@en...>> wrote:
Hi,
I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.

I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.

How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.

Is there perhaps a better way of going about doing this?

I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,

Winston

_______________________________________________
Net-snmp-coders mailing list
Net...@li...<mailto:Net...@li...>
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Re-registering sysContact and sysLocation with subagent

[Magnus F. <ma...@ly...>]

On Fri, Jan 28, 2022 at 09:21:04PM +0000, Winston Gadsby wrote:
> Hi,
> I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.
> 
> I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.
> 
> How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.
> 
> Is there perhaps a better way of going about doing this?
> 
> I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,

If I were to do this I would look at the PRIORITY argument to
agentx-register-PDU.

/MF

Re: Re-registering sysContact and sysLocation with subagent

[Larry H. <lh...@gm...>]

Someone just this month asked about taking control of the system
description.  I would suspect that sysContact and sysLocation would follow
the same way.

Their solution was to unregister the OID then register your own handler.

unregister_mib() API.

https://sourceforge.net/p/net-snmp/mailman/message/37598495/

It is a hassle, but you can also control the values of those inside of
a snmpd.local.conf file.

syscontact Nobody <no...@de...ll>

Your  agent would write the values to that file then SIGHUP the snmpd
to pick up the changes.



On Fri, Jan 28, 2022 at 3:37 PM Winston Gadsby <wg...@en...>
wrote:

> Hi,
> I'm running a subagent based on python-netsnmpagent, along with the
> distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using
> the version of snmpd that comes default with the distribution - 5.7.3.  I
> have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the
> python-netsnmpagent example.  Through the standard snmp command line
> commands I am able to read and write to the standard MIB defined OIDs, and
> to the new OIDs in my MIB, without issue.
>
> I would like to also be able to take over management of sysContact and
> sysLocation through my subagent.  This makes it easier to control these
> variables through my outside gui.  I've tried registering
> SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx
> socket, but receive error 263 - duplicate registration.  It seems the
> primary agent has already registered these variables and won't give up
> control.
>
> How does the agent know which variables the subagent can register and
> which it cannot?  Is my error due to another cause?  My custom MIB is
> located in the same directory as the rest of the system MIBs, in the search
> path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the
> master agent accepts it.  When I attempt to register sysContact or
> sysLocation it is denied.  If all the MIBs are stored together, how does it
> know my SIMPLE-MIB objects can be registered, but the others cannot?  Is
> there configuration somewhere else that determines which MIB variables I
> can register and which I cannot?  Am I only able to register variables in
> the new MIB?  How does it know which MIBs are custom and which are
> standard?  I've checked the snmpd.conf file, and it looks like I can define
> OID trees that trigger external programs, but there doesn't appear to be
> configuration for which OIDs are under master control and which can be
> controlled by the subagent, for normal snmp command line access.
>
> Is there perhaps a better way of going about doing this?
>
> I've gone through the mail lists and haven't been able to find an answer
> to this question.  Any help/pointers on this would be much appreciated.
> Thank you,
>
> Winston
>
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
>

Re-registering sysContact and sysLocation with subagent

[Winston G. <wg...@en...>]

Hi,
I'm running a subagent based on python-netsnmpagent, along with the distribution snmpd (net-snmp) agent on a Debian embedded system.  I'm using the version of snmpd that comes default with the distribution - 5.7.3.  I have a custom MIB for my new variables, similar to SIMPLE-MIB.txt in the python-netsnmpagent example.  Through the standard snmp command line commands I am able to read and write to the standard MIB defined OIDs, and to the new OIDs in my MIB, without issue.

I would like to also be able to take over management of sysContact and sysLocation through my subagent.  This makes it easier to control these variables through my outside gui.  I've tried registering SNMPv2-MIB::sysContact and SNMPv2-MIB::sysLocation through the agentx socket, but receive error 263 - duplicate registration.  It seems the primary agent has already registered these variables and won't give up control.

How does the agent know which variables the subagent can register and which it cannot?  Is my error due to another cause?  My custom MIB is located in the same directory as the rest of the system MIBs, in the search path - /usr/share/snmp/mibs.  When I register a variable from my MIB, the master agent accepts it.  When I attempt to register sysContact or sysLocation it is denied.  If all the MIBs are stored together, how does it know my SIMPLE-MIB objects can be registered, but the others cannot?  Is there configuration somewhere else that determines which MIB variables I can register and which I cannot?  Am I only able to register variables in the new MIB?  How does it know which MIBs are custom and which are standard?  I've checked the snmpd.conf file, and it looks like I can define OID trees that trigger external programs, but there doesn't appear to be configuration for which OIDs are under master control and which can be controlled by the subagent, for normal snmp command line access.

Is there perhaps a better way of going about doing this?

I've gone through the mail lists and haven't been able to find an answer to this question.  Any help/pointers on this would be much appreciated.  Thank you,

Winston

Re: Do NetSNMP support CreateAndWait

[Magnus F. <ma...@ly...>]

On Thu, Dec 09, 2021 at 09:45:38PM +0530, Feroz wrote:
> In the NetSNMP sample code I see the following block.
> I would like to understand if NetSNMP support "CreateAndWait"
> 
> File: ipAddressTable.c
> 
>     if (ROWSTATUS_CREATEANDWAIT == ipAddressRowStatus_val) {
>         DEBUGMSGTL(("ipAddressTable", "createAndWait not supported\n"));
>         return MFD_NOT_VALID_EVER;
>     }
> 
> If I remove the above block from the generated Code, will I be able to
> perform CreateAndWait?

Net-SNMP supports CreateAndWait - it is after all just one of the
possible values one can give to a variable of type RowStatus.

ipAddressTable.c - which implements ipAddressTable - does not support
CreateAndWait as the above code shows.

If you remove that check CreateAndWait support won't magically appear,
instead you will most likeley end up with timeouts and/or broken internal
state as it presumably isn't prepared for that input value - that is why
the check is there in the first place.

/MF

> -- 
> Regards,
> Feroz Ahmed


> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Do NetSNMP support CreateAndWait

[Feroz <fer...@gm...>]

In the NetSNMP sample code I see the following block.
I would like to understand if NetSNMP support "CreateAndWait"

File: ipAddressTable.c

    if (ROWSTATUS_CREATEANDWAIT == ipAddressRowStatus_val) {
        DEBUGMSGTL(("ipAddressTable", "createAndWait not supported\n"));
        return MFD_NOT_VALID_EVER;
    }

If I remove the above block from the generated Code, will I be able to
perform CreateAndWait?
-- 
Regards,
Feroz Ahmed

Skip setting asp->index if already set in function netsnmp_wrap_up_request

[Nishant N. <nis...@or...>]

Hi,
    I would like to discuss the issues which I faced with snmpget.

Issue 1 :
Description - In net-snmp(version 1), the value of errorindex is always getting set to the position of
last OID variable instead of pointing to the proper variable which caused the error response.

Test case:-

$ snmpget -v1 -c cmty_remotehost1 localhost SNMPv2-MIB::sysName.1 SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysObjectID.0
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-MIB::sysObjectID.0

Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-MIB::sysDescr.0

Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: SNMPv2-MIB::sysName.1

In the above command "SNMPv2-MIB::sysName.1" is the incorrect OID but "sysObjectID.0"( last variable ) is marked
as incorrect , and eventually all variables are marked incorrect in subsequent requests.

The above behavior is occurring only in v1 proxy mode.

Cause - netsnmp_wrap_up_request has asp->pdu->variables->type set as 129 (nosuchinstance) for all
the requested variables when response is received by proxy. 'While loop' inside netsnmp_wrap_up_request
function marks every variable incorrect incrementally and ends up setting errorindex as the position
of last variable.

Fix - When response is received by proxy, the function netsnmp_request_set_error_idx sets the
request->status = error_value to the request( variable ) which caused error response.
The corresponding request->index(position of variable) is assigned as asp->index, which is passed to netsnmp_wrap_up_request.
When asp->index > 0 , skip the while loop as we already have position of the incorrect variable
as asp->index.

Issue 2 :
Fix netsnmp_request_set_error_idx function to point to indicated varbind.

Description - Function netsnmp_request_set_error_idx which is used to set the error status of
the varbind which caused error response is not pointing to correct varbind.
Example - Consider the value of idx (pdu->errindex) to be 3, then the for loop conditions will make req
pointer to point to position 2, hence request at position 2 will be marked with error_value(pdu->errstat).

Fix - changed 'i<idx' to 'i<=idx' to point to indicated varbind.

Patch/Changeset - https://github.com/net-snmp/net-snmp/pull/379/commits/2b2e67e947e2d227a09c00cbade5911828c76989
Pull request - https://github.com/net-snmp/net-snmp/pull/379


Regards
Nishant

Re: using net-snmp at scale with one process and one socket

[Neil M. <nei...@gm...>]

I'm happy to share the changes I made to the library,  but they were
minimal.  Really just:

(a)  adding this hook to snmp_api.c to allow response packets to be
fed back in...

// add hook to allow this to be called from outside
void snmp_sess_receive_packet(void *sessp, u_char *packet, int length,
struct sockaddr *from, int from_len)
{
  struct session_list *slp = (struct session_list *) sessp;
  if(slp) {
    netsnmp_session *sp = slp->session;
    struct snmp_internal_session *isp = slp->internal;
    netsnmp_transport *transport = slp->transport;
    if(transport && transport->sock > 0 && sp && isp && isp->requests) {
      // The opaque is expected to be malloc'd by the transport
receive fn
      // because it is then freed by _sess_process_packet() later.
      void *from2 = malloc(from_len);
      memcpy(from2, from, from_len);
      int rc = _sess_process_packet(sessp, sp, isp, transport, from2,
from_len, packet, length);
      if(rc && sp->s_snmp_errno) SET_SNMP_ERROR(sp->s_snmp_errno);
    }
  }
}

(b) In snmpusm.c,  declaring usm_build_probe_pdu() as a global
function (by removing "static").

(c) reworking snmpusm.c to use a hash-table of lists,  instead of just
one (struct usmUser *) list.  This was a bigger change,  but it was
also a _breaking_ change because there is an SNMP v3 agent table that
expects a certain ordering here.  I think the right compromise might
be to use a tree-structure so that lookups are efficient while
ordering is preserved,  or better still just use a hash table and
change the agent code to comb through the table any time it wants a
GET_NEXT.  But either way that is a big change for such an obscure
benefit,  and extra care would need to be taken - especially in the
presence of multiple threads.

Unfortunately the other code I wrote to interface between the rest of
the application and the library is too intertwined with product code
to share just as it is.  But I'd be happy to discuss choices if
someone were to look at this.  For now I can share this psuedo code
outline below, which is probably more helpful anyway.

Notes:
(1)  I used a red-black-tree for the retry-timeout collection when it
might have been more appropriate to use a binary-heap(?)
(2)  I had to maintain separate hash lookups keyed by reqid and msgid
so that processing SNMPv3 responses could work the same way as for
SNMPv2.  For v3 responses the msgid appears unencrypted, while the
reqid only emerges after decryption is successful.
(3) Since a response might come in for a request that has already been
retried the request-pdu needs to keep the list of all attempts made so
far. Those requests are kept in an ordered list by the pdu and only
deleted when the pdu life-cycle is complete.
(4) It might have worked better to make the Request object be the
callback magic pointer, rather than the more persistent "Target"
object,  which then needs yet another hash table lookup to get to the
original request that matches the pdu.  I think this was to make sure
it was OK to delete a request at any time,  but in practice the
lifecycle is clear so maybe there is one indirection too many in this
scheme.

The cast of characters here are:
snmp - one persistent object representing this wrapper
  \_target - one mostly-persistent object for each remote target IP
      \_pdu - query and response objects
         |_request - individual attempt

// the callback function given to the library.  Called after
snmp_timeout() or snmp_sess_receive_packet()
SNMP_callback(int op, netsnmp_session *ss, int reqid, netsnmp_pdu
*pdu, void *magic) {
  target = (target)magic;
  req = removeFromHashTable(target->requestsByReqid, pdu->reqid)
  // process Pdu/error and call back to client
  // now we can finally clean up
  for(req in pdu->requests) {
     // make sure req is removed from all 5 collections:
     removeFromList(pdu->requests, req)
     removeFromTree(snmp->timeoutTree, req)
     removeFromHashTable(target->requestsByReqid, pdu->reqid)
     removeFromHashTable(snmp->requestsByReqId, req->reqid)
     removeFromHashTable(snmp->requestsByMsgId, req->msgid)
     delete(req)
  }
}

// sending a request
SNMP_sendRequest(pdu, target) {
  long reqid = snmp_sess_async_send(target->sessp, pdu, SNMP_callback, target)
  req = newRequest(target, pdu, reqid)
  // req goes in up to 5 collections:
  addToList(pdu->requests,req)
  addToHashTable(target->requestsByReqId, reqid)
  addToTree(snmp->timeoutTree, req)
  addToHashTable(snmp->requestsByReqId, reqid, req);
  if(pdu->version == 3)
     addToHashTable(snmp->requestsByMsgId, pdu->msgid, req);
}

// this is called every 100mS or so
SNMP_timeout(snmp) {
     while((req = timedOutRequest(snmp)) != NULL) {
        removeReqFromTimeoutTree(req);
        snmp_sess_timeout(req->target->sessp);
     }
}

// this is called when a response packet appears on the socket as a
result of select() or poll()
SNMP_response(snmp, socket, msg) {
     Request req=NULL;
     long version=0,msgid=0,reqid=0;
     snmp_parse_version_msgid(msg, &version, &msgid, &reqid);
     if(version==3)
        req = removeFromHashTable(snmp->requestsByMsgId, msgid);
     else
        req = removeFromHashTable(snmp->requestsByReqId, reqid);
     if(req) {
        removeFromTree(snmp->timeoutTree, req);
        snmp_sess_receive_packet(req->target->sessp, msg->buf,
msg->len, (struct sockaddr *)&msg->peer, msg->peer_len);
     }
}

On Fri, Oct 22, 2021 at 9:07 AM Wes Hardaker
<har...@us...> wrote:
>
> Neil Mckee <nei...@gm...> writes:
>
> > You are very welcome. Let me know if you want to discuss any of the
> > particulars.
>
> Well, the biggest question in my mind is: are you willing to contribute
> the patches back?
>
> It's unclear if any of them break backwards compatability (which we
> always strive for), but certainly many of them would not.
>
> > Adding or importing your favorite tree implementation to the library
> > would be a lot of new code
>
> Well, there's one issue: lots of new code means bigger applications and
> we do strive to be small to run on small devices.  That being said, the
> sliding definition of "small" has certainly increased in size over time
> with the continued increase of storage/memory availability in even the
> smallest devices.
>
>
> --
> Wes Hardaker
> Please mail all replies to net...@li...

Re: [FIX][PATCH] snmp-bridge-mib

[Wes H. <har...@us...>]

Charles Polisher <ch...@ch...> writes:

> I found a bug in snmp-bridge-mib that causes incorrect results
> when the number of bridge ports exceeds one digit, because a
> string compare is used on numeric data.

Thanks, applied!
-- 
Wes Hardaker
Please mail all replies to net...@li...

[FIX][PATCH] snmp-bridge-mib

[Charles P. <ch...@ch...>]

Hello,

I found a bug in snmp-bridge-mib that causes incorrect results
when the number of bridge ports exceeds one digit, because a
string compare is used on numeric data. The fix, tested, is below.
I hope this helps!

Best regards, and thanks to all the maintainers,
-- 
Charles Polisher

$ diff -u snmp-bridge-mib snmp-bridge-mib.fixed
--- snmp-bridge-mib     2016-02-27 08:24:22.000000000 -0800
+++ snmp-bridge-mib.ckp.fixed   2021-11-02 08:53:44.949074091 -0700
@@ -998,7 +998,7 @@

         opendir(DIR, $brifdir) or return -1;
         my @interfaces = readdir(DIR);
-       next if ($#interfaces lt 2);
+       next if ($#interfaces < 2);
         foreach my $if (@interfaces) {
                 next if $if eq ".";
                 next if  $if eq "..";

Re: When exactly the response is received from node 2 ?

[Bill F. <fe...@gm...>]

On Tue, Nov 2, 2021 at 8:17 AM Nishant Nayan <nay...@gm...>
wrote:

> Hi,
>     Is there a way to track all function calls along with this
> "-Ddumpv,dumph"?
> I would like to track function calls made by 'snmpd' when I run snmpget to
> query OIDs from other snmp abled device.
>

You could try -DALL.  That doesn't quite track all function calls, but at
least it tracks all places where there is any debugging specified.

  Bill


> On Mon, 6 Sept 2021 at 19:26, Bill Fenner <fe...@gm...> wrote:
>
>> On Sun, Sep 5, 2021 at 9:59 AM Nishant Nayan <nay...@gm...>
>> wrote:
>>
>>> My aim is to know how various parameters like errorstat and errindex
>>> etc. are set from response.
>>>
>>> For an example command :
>>> snmpget -v1 -c cmty_remotehost1 localhost SNMPv2-MIB::sysName.1
>>> SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysObjectID.0
>>>
>>> SNMPv2-MIB::sysName.1 being an incorrect oid
>>>
>>
>> I like to add "-Ddumpv,dumph" to get details of the messages that are
>> being send and received.  Try running your get with that debugging to see
>> if the output helps you understand where each field comes from.  (You can
>> change it to just "-Ddump" to also get a hex dump, which you may be able to
>> compare with the data field you see in your debugger).
>>
>> Each field in the packet is encoded using ASN.1, which is more or less a
>> type/length/value encoding, but is fairly complex.  If you're trying to
>> create your own packets, please see if it's feasible to use an existing
>> ASN.1 encoder, because there have historically been many bugs in ASN.1
>> parsing and encoding so it's best to use a well-tested implementation.
>>
>> Also, if you want to know what the SNMP protocol is doing, as opposed to
>> what the helpful snmpget command is doing, you should add "-Cf" to the
>> snmpget command line - when snmpget gets an error like this, it'll strip
>> out the bad object and try again so that it gets the data that may exist,
>> but that is not how SNMP works per se - that is how snmpget works.
>>
>>   Bill
>>
>>

Re: When exactly the response is received from node 2 ?

[Nishant N. <nay...@gm...>]

Hi,
    Is there a way to track all function calls along with this
"-Ddumpv,dumph"?
I would like to track function calls made by 'snmpd' when I run snmpget to
query OIDs from other snmp abled device.

Thanks
Nishant

On Mon, 6 Sept 2021 at 19:26, Bill Fenner <fe...@gm...> wrote:

> On Sun, Sep 5, 2021 at 9:59 AM Nishant Nayan <nay...@gm...>
> wrote:
>
>> My aim is to know how various parameters like errorstat and errindex etc.
>> are set from response.
>>
>> For an example command :
>> snmpget -v1 -c cmty_remotehost1 localhost SNMPv2-MIB::sysName.1
>> SNMPv2-MIB::sysDescr.0 SNMPv2-MIB::sysObjectID.0
>>
>> SNMPv2-MIB::sysName.1 being an incorrect oid
>>
>
> I like to add "-Ddumpv,dumph" to get details of the messages that are
> being send and received.  Try running your get with that debugging to see
> if the output helps you understand where each field comes from.  (You can
> change it to just "-Ddump" to also get a hex dump, which you may be able to
> compare with the data field you see in your debugger).
>
> Each field in the packet is encoded using ASN.1, which is more or less a
> type/length/value encoding, but is fairly complex.  If you're trying to
> create your own packets, please see if it's feasible to use an existing
> ASN.1 encoder, because there have historically been many bugs in ASN.1
> parsing and encoding so it's best to use a well-tested implementation.
>
> Also, if you want to know what the SNMP protocol is doing, as opposed to
> what the helpful snmpget command is doing, you should add "-Cf" to the
> snmpget command line - when snmpget gets an error like this, it'll strip
> out the bad object and try again so that it gets the data that may exist,
> but that is not how SNMP works per se - that is how snmpget works.
>
>   Bill
>
>