Thank you for the suggestions. Based on your suggestion, we were trying
different things and figured out a way to make it work.
One of the first things we did was, remove all the warnings since there
were a lot. Then we saw that the compiler was telling us that there are
more than 255 variables which is more than the vp->magic variable can store.
One of the other thing we tested was, if we can see all the OIDs with
"name" variable with the following code:
// Find the OID to match
memset(tmpsql,0, sizeof(tmpsql));
memset(buf,0, sizeof(buf));
for (z = 0; z < *length; z++)
{
res = snprintf(buf, sizeof(buf), "%u",name[z]);
strcat(tmpsql, buf);
if(z < *length - 1)
{
strcat(tmpsql, ".");
}
}
// tmpsql contains the OID, match it in a switch case
for (size_t i = 0; i < NUM_ENTRIES; i++)
{
if (strcmp(oidlookupTable[i].oid, tmpsql) == 0)
{
matched_code = oidlookupTable[i].device_type;
break;
}
}
And we thought, we can use the OIDs to match up all the data points and
that's what we used in the switch statement. We added a struct as follows
and defined all our variables, which uses the previously defined variables
in header file.
typedef struct OidEntry {
const char *oid;
int device_type;
} OidEntry;
This solution seems to work for us and now we can add as many variables as
we want. I hope this solution can help someone else as well.
And again, thank you for your response Craig.
- Neeraj
On Fri, 11 Oct 2024 at 00:16, Craig Small <csm...@dropbear.xyz> wrote:
> Hi,
> You can definitely have more than 255 custom OIDs, the trick is you only
> have 255 values for magic. I'm surprised hacking the magic value didn't
> crash it before.
>
> There's probably a few options; the good, the bad and the ugly.
>
> Good
> Rebuild the MIB and functions so each type of variable uses a different
> accessor function, so testboard_var becomes testboard_load,
> testboard_temperature etc.
> As long as you don't have 256 temperature sensors or load sensors or same
> things this works. If you have different ways of getting values, it also
> means the
> functions are simpler/smaller because the temperature getter has no code
> for working out system load and vice-versa. It also means you're not
> bothering to fetch the
> temperature when you want to get the load too.
>
> Bad
> Keep the mib as it is, but have several accessor functions which have a
> different magic which you add to the parameters passed to the real accessor.
> Your testboard_var() will need a new parameter, say mymagic which is
> something larger than u_char
>
> testboard_var1(vp, other variables)
> return (testboard_var(vp->magic, vp, other variables)
> testboard_var2(vp, other_variables)
> return (testboard_var(vp->magic+256, vp, other_variables)
> testboard_var3(vp, other_variables)
> return (testboard_var(vp->magic+512, vp, other_variables)
> In your variables array the ones that use 1-255 use testboard_var1,
> 256-511 use testboard_var2 (but use magic-256) etc.
>
> Ugly
> Overload or ignore the magic and match on the OID directly, which is
> called vp->name. There's a reason why this is the ugly option.
>
> - Craig
>
>
> On Sat, 21 Sept 2024 at 05:24, Neeraj Bansal <neerajbansal54...@gmail.com>
> wrote:
>
>> That makes sense Craig. Thank you for your input.
>>
>> To summarize the issue, we are unable to use more than 255 OID entries
>> and would love to get any help on this issue.
>>
>> Is there another way to use more than 255 custom OID's?
>>
>> Thank You to anyone looking into this matter.
>>
>> - Neeraj
>>
>> On Mon, 29 Jul 2024 at 14:26, Craig Small <csm...@dropbear.xyz> wrote:
>>
>>> On Fri, 12 Jul 2024 at 08:31, Neeraj Bansal <neerajbansal54...@gmail.com>
>>> wrote:
>>> > We recompile everything and install no problem, but instead of fixing
>>> our problem it caused net-snmp-5.9.3 to not be able to start. The error it
>>> gives is: Bad user id, which could be a red herring. example below:
>>> > [root@testboard: /root# /etc/init.d/S59netsnmp restart
>>> > Stopping SNMP daemon: [OK]
>>> > Starting SNMP daemon: Bad user id: snmp
>>> I think it is a red herring, that error is from the -u option.
>>>
>>> # /usr/sbin/snmpd -u blah
>>> Bad user id: blah
>>>
>>> I know that is not solving your main issue, but its got rid of one thing.
>>>
>>> - Craig
>>>
>>>
>>>
>>> > [root@testboard: /root#
>>> >
>>> > So, we take our patches out and recompile and install, and it works
>>> again but still has the 255 custom oid limitation.
>>> >
>>> > A snippet from our header file. Too big to paste it all.
>>> >
>>> > #define TEMPC 1
>>> > #define TEMPF 2
>>> > #define UPTIME_STR 3
>>> > #define SERIALNUMBER 4
>>> > #define ALLOFIT 5
>>> > #define ROOTFSBUILD 6
>>> > #define KERNELBUILD 7
>>> > #define OSINFO 8
>>> > ......
>>> > #define PRODUCT_ID 250
>>> > #define RUNSCRIPT 251
>>> > #define TIMER1 252
>>> > #define TIMER2 253
>>> > #define TIMER3 254
>>> > #define TIMER4 255
>>> > #define TIMER5 256 <- This outpts an error because it wraps around and
>>> 0 is not defined.
>>> > #define TIMER6 257 <- This outputs TEMPC value instead of TIMER6.
>>> > #define TIMER7 258
>>> > #define TIMER8 259
>>> > #define TIMER9 260
>>> > #define TIMER10 261
>>> >
>>> > #define EXAMPLETIMETICKS 3333
>>> > #define EXAMPLEIPADDRESS 4444
>>> > #define EXAMPLECOUNTER 7777
>>> > #define EXAMPLEGAUGE 8888
>>> > #define EXAMPLETRIGGERTRAP 9999
>>> > #define EXAMPLETRIGGERTRAP2 1000
>>> >
>>> > Notice the example defines above that were provided in the example C
>>> header file, those magic numbers would have never worked because of the
>>> u_char (8-bit) magic variable limitation.
>>> >
>>> > This is a code snippet from our custom mib C file.
>>> >
>>> > struct variable4 testboard_variables[] = {
>>> > {ROOTFSBUILD, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var,
>>> 2, {7, 1}},
>>> > {KERNELBUILD, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var,
>>> 2, {7, 2}},
>>> > {OSINFO, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2, {7,
>>> 3}},
>>> > {PRODUCT_ID, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, etestboard_var,
>>> 2, {7, 4}},
>>> > {UPTIME_STR, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2,
>>> {5, 1}},
>>> > {SERIALNUMBER, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var,
>>> 2, {5, 2}},
>>> > {TEMPC, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2,
>>> {6,1}},
>>> > {TEMPF, ASN_OCTET_STR, NETSNMP_OLDAPI_RONLY, testboard_var, 2,
>>> {6,2}},
>>> >
>>> > We have poured over the souce code looking for any other instance of
>>> u_char magic that we may have missed, but they are only defined in the two
>>> files mentioned above.
>>> >
>>> > We need some help with this. What else do we need to do in the 5.9
>>> versions to make the magic number not wrap around to zero after 255 and not
>>> crash when we do that?
>>> >
>>> > Thanks,
>>> >
>>> > Neeraj Bansal
>>> > _______________________________________________
>>> > 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
