Hi Mario,
Take a look at RFC1155, particularly at section 4.2, it has an example
of how objects can be put together in a table.
The basic overview, removing iso.3.6.1.4.1. for brevity, using the
example below is like this:
enterprise_oid (26381)
objects_oid (1)
table_oid (1)
table_entry_oid (1) [a SEQUENCE type defining what objects
are in the conceptual row]
table_index_object_oid (1) [INTEGER]
table_data_object_oid (2) [STRING]
In a visual form with data:
Index | 26381.1.1.1.1 | 26381.1.1.1.2
_____________________________________________________________________________
1 | [26381.1.1.1.1.1] INTEGER: 11 | [26381.1.1.1.2.1] STRING: "0.txt"
2 | [26381.1.1.1.1.2] INTEGER: 22 | [26381.1.1.1.2.2] STRING: "1.txt"
3 | [26381.1.1.1.1.3] INTEGER: 33 | [26381.1.1.1.2.3] STRING: "2.txt"
4 | [26381.1.1.1.1.4] INTEGER: 44 | [26381.1.1.1.2.4] STRING: "3.txt"
In your example the last number in the OID is the index. Objects that
are not part of a table by convention are accessed with .0 appended to
the OID, see RFC1067, 3.2.6.3. Identification of Object Instances. A
table should never have an index of 0 for the reason it would not be
distinguishable from a non table object.
You can have multiple indexes in a table, for example you could have an
IP address and a port number as indexes, although in the case of an IP
address as an index an extra .4 would proceed the IP address in the OID,
to specify the length in octets.
Hopefully that helps and I have not just added confusion.
David
On 06/11/2019 15:25, Mário Luzeiro wrote:
Hello all,
I was testing the SNMP private example:
lwip/contrib/examples/snmp/snmp_private_mib/
and I got this
iso.3.6.1.4.1.26381.1.1.1.1.1 = INTEGER: 11
iso.3.6.1.4.1.26381.1.1.1.1.2 = INTEGER: 22
iso.3.6.1.4.1.26381.1.1.1.1.3 = INTEGER: 33
iso.3.6.1.4.1.26381.1.1.1.1.4 = INTEGER: 44
iso.3.6.1.4.1.26381.1.1.1.2.1 = STRING: "0.txt"
iso.3.6.1.4.1.26381.1.1.1.2.2 = STRING: "1.txt"
iso.3.6.1.4.1.26381.1.1.1.2.3 = STRING: "2.txt"
iso.3.6.1.4.1.26381.1.1.1.2.4 = STRING: "3.txt"
iso.3.6.1.4.1.26381.1.2.0 = INTEGER:
I noticed that the source code the TABLE is created with Columns
however, it looks that from my specification (the private MIB I must implement)
it is defined as Rows.
Would it be possible ?
so I will get something instead:
iso.3.6.1.4.1.26381.1.1.1.1 = INTEGER: 11
iso.3.6.1.4.1.26381.1.1.1.2 = STRING: "0.txt"
iso.3.6.1.4.1.26381.1.1.2.1 = INTEGER: 22
iso.3.6.1.4.1.26381.1.1.2.2 = STRING: "1.txt"
iso.3.6.1.4.1.26381.1.1.3.1 = INTEGER: 33
iso.3.6.1.4.1.26381.1.1.3.2 = STRING: "2.txt"
iso.3.6.1.4.1.26381.1.1.4.1 = INTEGER: 44
iso.3.6.1.4.1.26381.1.1.4.2 = STRING: "3.txt"
iso.3.6.1.4.1.26381.1.2.0 = INTEGER:
Another question, it looks Table is creating a new node in between:
iso.3.6.1.4.1.26381.1.1.1.1.1 = INTEGER: 11
iso.3.6.1.4.1.26381.1.2.0 = INTEGER:
and I was expecting it with less one node in the hierarchy:
iso.3.6.1.4.1.26381.1.1.1.1 = INTEGER: 11
iso.3.6.1.4.1.26381.1.2.0 = INTEGER:
I am also completely new to SNMP so I have no idea if it should be columns or
rows or what about this extra node if it is expected.
Anyone could clarify me ?
Mario Luzeiro
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
