Hi,
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.
The code will leave some memory unfreed on exit - since wireless clients can come and go the number of entrys in the clients table will change, so keeping a simple mapping of table[i] <-> stats[i] for the monitor mode won't work, so i used a GHashTable instead.
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.
[1] http://docs.info.apple.com/article.html?artnum=120227
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.
The code will leave some memory unfreed on exit - since wireless clients can come and go the number of entrys in the clients table will change, so keeping a simple mapping of table[i] <-> stats[i] for the monitor mode won't work, so i used a GHashTable instead.
Yes, scli currently lacks a cleanup hook for such things.
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 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?
/js
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.
On Thu, Feb 16, 2006 at 12:31:18PM +0000, Jasper Wallace wrote:
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.
But that just means that the box is broken wrt. the MIB. The MIB says
INDEX { wirelessPhysAddress } INDEX { dhcpPhysAddress }
and both of them are of type PhysAddress, which is a variable length octet string. RFC 2578 section 7.7 explains how variable-length strings are encoded and that there is a leading length octet. If you replace PhysAddress with MacAddress, you get a fixed length encoding and then the length octet goes away.
If you are a proper Apple customer, you might want to report this bug so that they can simply fix their broken MIB module.
/js
On Thu, 16 Feb 2006, Juergen Schoenwaelder wrote:
If you are a proper Apple customer, you might want to report this bug so that they can simply fix their broken MIB module.
There's a feedback form on there website I used yesterday, it dosn't have a field for an email address unfortunatly, so i won't get any notification if they do decide to do something.
participants (2)
-
Jasper Wallace
-
Juergen Schoenwaelder