[collectd] SNMP Sub-OID Question

[David Mitchell]

Florian Forster wrote:
> Hi David,
> 
> On Tue, Nov 24, 2009 at 08:05:31AM -0700, David Mitchell wrote:
>>> The Cisco AP's I have use a fairly long instance in this table which
>>> includes the MAC address.
> 
> not sure I understand this correctly: Is the MAC address part of the
> OID?
> 
> Anyways, collectd is using only the last number of the OID because
> that's how it's supposed to be. Unfortunately, many manufacturers don't
> understand SNMP (or let some intern write the MIB or something) and use
> multiple parts there. Using every part that's not specified as the
> "Values" option would probably simplify the case in which the instance
> is to be determined from the OID.
> 
>>> Collectd only seems to use the last single OID from the instance in
>>> the name of the value.
> 
> If no separate instance-OID is specified, yes.
> 
>>> In my case, this ends up being the last octet of the clients MAC
>>> address.
> 
> Oh, good $deity! Cisco is doing this, too? One does not encode
> information in the OID!
> 
>>> I quick perusal of the code seems to show that the single-value
>>> suboid seems fairly hard-coded in. Is there any workaround for this?
>>> Have others hit this issue? A search in the bug tracker didn't turn
>>> anything up.
> 
> Yeah, it's hard coded in. I could picture changing this like this: Image
> the user specifies the OID ".1.2.3.4". The GETNEXT request returns the
> OID ".1.2.3.4.5.6.127". Instead of using the last part of the OID, we
> use the difference: (5, 6, 127). The next problem is how to convert this
> to a string. For MAC addresses you'd want the "%02x" format for each
> value, but I've seen IPv4 addresses being encoded in the OID, too.
> 
> Letting the user specify a format string is a bit tricky because the
> number of values cannot be determined a priori. So maybe something like
> this would be in order:
>   InstanceOIDFormat "%02x"
>   InstanceOIDSeparator ":"
> This would format each value of the OID using "%02x" and concatenate
> them together using ":" as the separator. So the above (5, 6, 127) would
> become "05:06:7f".

That might be a workable config. It should be possible to make it work 
either with or without the Instance mapping. To be honest, I'm less 
particular about the exact formatting than I am in just having it be 
unique per instance.

>> I've been looking into this more. I found a similar issue when using
>> the Instance option. Our AP's do include an IP address for each client
>> which I can use to map the Instance. But it's returned in a raw format
>> of four octets. Collectd prints this to the value name as though it
>> was a string, resulting in unprintable characters in the filename.
> 
> Uh, yeah, that binary data in SNMP is a bit tricky to handle.
> 
>> I think both of these issues can be rectified by calling back into
>> net-snmp to let it do the formatting needed for the values.
> 
> Yeah, in case of the instance option this would probably be a good
> thing.
> 
>> I've begun trying to patch up a version which does this. Is this a
>> patch which is likely to be accepted?
> 
> Yes, definitely :)

Sounds good. I'll try to see what I can come up with.

> 
>> I imagine that in some instances it will cause changes in the
>> resulting value name. Is such a patch likely to be accepted? Do I need
>> to perhaps include some non-default configuration option to active it?
> 
> Yeah, backwards compatibility should remain, so introducing a config
> option for this is probably a very good idea.

OK. I'll need to dig into how the config is parsed.

> 
> Sorry if I sound a bit annoyed - it's not you, it's manufacturers who
> didn't understand SNMP.. And especially Cisco should know better..

Well, since RFC 1157 does exactly that in section 4.1.3.1 'Example of 
Table Traversal', their confusion is perhaps understandable ;-)

-David Mitchell

> 
> Regards,
> -octo