On Thu, 16 Feb 2006, Juergen Schoenwaelder wrote:
On Wed, Feb 15, 2006 at 05:16:28PM +0000, Jasper Wallace wrote:
The patch is attached. I had problems with the mib[1] - it uses PhysAddress as the index to a couple of the tables, but since PhysAddress has no length associated with it the code generated by smidump breaks.
I worked around it by replacing PhysAddress with MacAddress from SNMPv2-TC, but if there's a way of saying to smidump that in this mib PhysAddresses are 6 bytes, that would be better.
Thanks for the patch. I would be interested to know why the usage of PhysAddress causes problems. The code generator should be able to deal with variable-length octet strings.
In unpack_wirelessClient it does:
{ guint8 idx = 13; guint16 i, len;
if (vb->oid_len < idx) return -1; len = vb->oid[idx++]; if (len > 115) return -1; if (vb->oid_len < idx + len) return -1; for (i = 0; i < len; i++) { wirelessClient->wirelessPhysAddress[i] = vb->oid[idx++]; } wirelessClient->_wirelessPhysAddressLength = len; if (vb->oid_len > idx) return -1; return 0; }
the problem is "len = vb->oid[idx++];", the 1st byte of the mac address is not it's length! (and it's 0x00 on most machines here). The responces you get from the box are like:
.1.3.6.1.4.1.63.501.3.2.2.1.4.0.17.36.45.42.196=515621
where 0.17.36.45.42.196 == 00:11:24:2d:2a:c4
the "if (vb->oid_len < idx + len)" test would then fail.
Early on i tried writing generic table display code, since the _attr[] stuff tells you all you need to know in order to render a table, but since the table structs have all the column names as variables you have to write table specific code.
By looking at the link, a nasty questions comes up:
Is it legal to include the MIB stubs in the scli distribution?
If by 'stubs' you mean the generated code, then i think so. If you mean the mib file you can download from that url, then no, we can't inclue it.
Heck, with a strict reading of the licence I can't even look at it since I don't own a mac!
If I take the license agreement literally, then probably the answer is no. We seem to have this issue in general with vendor MIB modules and I am not sure how to deal with it. Any ideas/comments?
We could try contacting apple and asking for then to change the license on the mib file.