Hi,
Suppose you try to create a subagent using the output from "smidump -f netsnmp".
In the header file you get definitions like
typedef struct yourMib { uint32_t *foo; void *_clientData; uint32_t __foo; } yourMib_t
Now take a look a the switch statement that takes care of returned the correct value to the master agent (switch based on vp's magic number). It looks like this:
static yourMib_t yourMib; // ... return (unsigned char *) &yourMib.foo;
However, what the master agent is actually expecting is a pointer to the value, not a pointer to the pointer to the value. Looks nice in those snmpwalk outputs, such memory addresses :-)
Is this a problem with libsmi or am I overlooking something?
On a sidenote, what I am supposed to use *_clientData and __foo in the example above for?
Thanks,
Remco.
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Remco van de Meent writes:
Remco> Suppose you try to create a subagent using the output from Remco> "smidump -f netsnmp".
Remco> In the header file you get definitions like
[...]
Remco> Now take a look a the switch statement that takes care of Remco> returned the correct value to the master agent (switch based on Remco> vp's magic number). It looks like this:
[...]
Remco> However, what the master agent is actually expecting is a Remco> pointer to the value, not a pointer to the pointer to the Remco> value. Looks nice in those snmpwalk outputs, such memory Remco> addresses :-)
Remco> Is this a problem with libsmi or am I overlooking something?
It is a problem with the netsnmp output driver. If you grab the latest version from CVS, you will notice that the generated API has already changed. I expect even more changes to this output driver in the future to make it really useful.
Remco> On a sidenote, what I am supposed to use *_clientData and __foo Remco> in the example above for?
The __foo's and the pointers are gone in the current version (but they might come back ;-). The original idea was to always use pointers to the data so that NULL pointers can be used to identify non-existing objects (holes in tables). I am using this approach on the manager side in the stools stub code and it works fine. On the agent side, you frequently want to have the required storage available without doing malloc's. So the idea in the version you are looking at was to provide some private __foo's which you can point to and which you to not have to allocate.
The _clientData is a field which can hold a pointer and allows you to bind your private data structure to a compiler generated data structure.
Note that we now have a student who is going to improve the netsnmp code generator. So changes will be likely - but things will also get much better designed and tested.
/js
Juergen Schoenwaelder wrote:
It is a problem with the netsnmp output driver. If you grab the latest version from CVS, you will notice that the generated API has already changed. I expect even more changes to this output driver in the future to make it really useful.
Just updated my local tree, and it looks 'better' now.
[snap]
Thanks for your explanation about the __foo and _clientData structures, it's all clear now :)
Note that we now have a student who is going to improve the netsnmp code generator. So changes will be likely - but things will also get much better designed and tested.
Great! I assume he's (she?) following this list as well?
By the way, it's probably known already, but just to mention it - it seems that when using the Counter64 type in a MIB, the output from the netsnmp libsmi driver creates something like
CASE FOO: /* add code here */
CASE BLAH: return &bar;
Obvously this results in the agent returning the value for the wrong object, which is IMHO worse than returning zero or something like that.
I'll keep my local tree in sync with the IBR tree and for the time being focus on other parts of my implementation and get everything synchronized again when the API is more or less stabilized again. If you want me to test things or so, please let me know.
cheers, Remco.
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Remco van de Meent writes:
Remco> By the way, it's probably known already, but just to mention it Remco> - it seems that when using the Counter64 type in a MIB, the Remco> output from the netsnmp libsmi driver creates something like
Remco> CASE FOO: /* add code here */
Remco> CASE BLAH: return &bar;
Remco> Obvously this results in the agent returning the value for the Remco> wrong object, which is IMHO worse than returning zero or Remco> something like that.
Correct. I will fix that.
Remco> I'll keep my local tree in sync with the IBR tree and for the Remco> time being focus on other parts of my implementation and get Remco> everything synchronized again when the API is more or less Remco> stabilized again. If you want me to test things or so, please Remco> let me know.
The fix should appear as soon as the anon CVS is syncornized with the real CVS repository.
/js
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
participants (2)
-
Juergen Schoenwaelder -
Remco van de Meent