Hello net-snmp coders. I'm implementing a MIB that supports zoned IPv4
addresses, and I'm having an issue with the way the addresses are
displayed in the client programs. The textual convention for zoned
addresses states that the value should be represented as 8 bytes with
the zone being the last four bytes in network order. Looking at the
code in mib.c, it doesn't seem that that is what net-snmp is doing in
the case of decoding an OID - it requires that 8 nodes be present -
implying that each node of the zone should account for one byte of the
eventual integer, similar to how each octect of the ip address is
represented by one node. It instead assumes the entire integer is
stored in one node in network order, although it appears that by the
time the nodes have made it into the oid* objid, they are already in
host representation. Instead it seems like one byte should be copied
out of objid four times and put into an integer, which should then
have ntohl called on it. I've provided a patch for the way I think it
should work, as well as some more evidence below the patch. Thoughts?
thanks,
-b
--- snmplib/mib.c 2007-05-12 04:14:39.000000000 -0700
+++ snmplib/mib.c 2008-12-15 15:30:14.000000000 -0800
@@ -3815,7 +3824,7 @@
{
if (buf) {
int i, len;
- char intbuf[64], * p;
+ char intbuf[64], * p, * zc;
unsigned long zone;
memset(intbuf, 0, 64);
@@ -3833,7 +3842,9 @@
len = sprintf(p, "%lu.%lu.%lu.%lu", objid[0],
objid[1], objid[2], objid[3]);
p += len;
This assumes the address is contained in one
if (addr_type == IPV4Z) {
- zone = ntohl((long)objid[4]);
+ zc = &zone;
+ zc[0] = objid[4]; zc[1] = objid[5]; zc[2] =
objid[6]; zc[3] = objid[7];
+ zone = ntohl(zone);
len = sprintf(p, "%%%lu", zone);
p += len;
}
The textual convention on them seems pretty straightforward:
InetAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv4 network address, together
with its zone index:
Octets Contents Encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
So two examples from what I'm working on
.1.3.6.1.4.1.3375.2.1.2.8.1.2.1.2.3.8.172.27.13.41.0.0.0.1 =
Hex-STRING: AC 1B 0D 29 00 00 00 01
F5-BIGIP-SYSTEM-MIB::sysSelfIpAddr.ipv4z."172.27.13.41%0" =
Hex-STRING: AC 1B 0D 29 00 00 00 01
(I work for F5 - you would expect '%1', not '%0')
F5-BIGIP-SYSTEM-MIB::sysSelfIpAddrType.ipv4z."172.27.13.41%3333" =
INTEGER: ipv4z(3)
.1.3.6.1.4.1.3375.2.1.2.8.1.2.1.2.3.8.172.27.13.41.84738048.0.0.0 =
Hex-STRING: AC 1B 0D 29 00 00 00 01
(so you can get a number you want to print out there - but as you can
see you actually have to reverse the endian-ness of it in order to get
snmplib to flip it back again)
After the patch:
F5-BIGIP-SYSTEM-MIB::sysSelfIpAddr.ipv4z."172.27.13.41%1" =
Hex-STRING: AC 1B 0D 29 00 00 00 01
.1.3.6.1.4.1.3375.2.1.2.8.1.2.1.2.3.8.172.27.13.41.0.0.0.1 =
Hex-STRING: AC 1B 0D 29 00 00 00 01
And their corresponding MIB entry:
sysSelfIpEntry OBJECT-TYPE
SYNTAX SysSelfIpEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Columns in the sysSelfIp Table"
INDEX {
sysSelfIpAddrType,
sysSelfIpAddr
}
::= { sysSelfIpTable 1 }
SysSelfIpEntry ::=
SEQUENCE {
sysSelfIpAddrType InetAddressType,
sysSelfIpAddr InetAddress,
sysSelfIpNetmaskType InetAddressType,
sysSelfIpNetmask InetAddress,
sysSelfIpUnitId INTEGER,
sysSelfIpIsFloating INTEGER,
sysSelfIpVlanName LongDisplayString
}
--
"The true value of a human being is determined primarily by the
measure and the sense in which he has attained liberation from the
self" -- Albert Einstein
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
