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...@lysator.liu.se>
Sent: Tuesday, February 1, 2022 8:56 PM
To: Winston Gadsby <wgad...@enginuitycom.com>
Cc: Larry Hayes <lhay...@gmail.com>; net-snmp-coders@lists.sourceforge.net
<net-snmp-coders@lists.sourceforge.net>
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 <lhay...@gmail.com>
> Sent: Friday, January 28, 2022 4:48 PM
> To: Winston Gadsby <wgad...@enginuitycom.com>
> Cc: net-snmp-coders@lists.sourceforge.net
> <net-snmp-coders@lists.sourceforge.net>
> 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 <nob...@dev.null>
>
> 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
> <wgad...@enginuitycom.com<mailto:wgad...@enginuitycom.com>> 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-snmp-coders@lists.sourceforge.net<mailto:Net-snmp-coders@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
> _______________________________________________
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
