I am creating a series of simulated agent and have a set list of OIDS my client application will poll for each. I’ve followed along pretty well on how to register regular MOScalar oids. MOScalar mo = new MOScalar(new OID"1.3.6.1.4.1.73.17.1.8.6.1.3.1.4.116.105.1.7479"),MOaccessImpl.ACCESS_READ_WRITE, new OctetString("This is a test")); server.register(mo, new OctetString("public")).
However, I am having a hard time following though the Snmp4jHeartbeatMib example on how to implement a MOTable.
Given the tables can I get some further explanation on how to define, implement, and register these OIDS?
These OIDs do not belong to the same table. Reverse engineering the MIB table definition from a list of OIDs is difficult and maybe impossible.
Normally, you would need to get the MIB module definition of the table. Then it is easy. AgenPro can generate the simulation agent for you, for example.
When you have a dump of an existing agent (list of OIDs with corresponding values), it is easier to treat all OIDs as scalars. and register scalars only. You can do this efficiently with the StaticMOGroup.
Hey thanks for the input. I beleive those OIDS to be the root addresses and the X’s will represent the table indexes that follow. I am needing these MOs to have read/write access, it does now look like StaticMOGroup allows for this. Is there a way to register these OIDS as dynamic scalar objects?
MOScalar mo2 = new MOScalar(new OID"1.3.6.1.4.1.73.17.1.8.6.1.3.1.4.116.105.1.7479"),MOaccessImpl.ACCESS_READ_WRITE, new OctetString("This is a test")); server.register(mo1, new OctetString("public"))
MOScalar mo1 = new MOScalar(new OID"1.3.6.1.4.1.73.17.1.8.6.1.3.1.4.116.105.1.7479"),MOaccessImpl.ACCESS_READ_WRITE, new OctetString("This is a test")); server.register(mo2, new OctetString("public"))
If I were to do this I get the DuplicateRegistrationException. Other form posts have told me that I should just append a .0 to the OID. The only problem is that the client no longer knows how to find that oid.
Bear in mind that my organization uses SNMP4j 2.3.1, so its not exactly the most up to date (it’s a long process to get new software approved)… Anyways I was thinking about a work around for this problem. I could just do what you had suggested and register all of the OIDS that my client will be searching for as scalars i.e. (1.3.6.1.4.1.73.1.8.3.1.1.1.x.x.0). Then when the client requests a tabular OID address, intercept the packet in the defaultTransportUDP class or just in the PDU class itself and append a “.0” to the end.
This seems kinda hack-y, but I suspect it’ll work this this particular project. Just wondering if you could suggest a “more correct” approach .
p.s. I had a hard time setting up a build to compile my code changes back into a snmp4j.jar file (never really used Maven before). My workstation is not network enabled, so i just had to rip out all of the Maven stuff. It works for the most part, but I keep getting annoying IDE specific errors. Whenever I type a statement followed by the ‘.’ operator it barks at me about some kind of java nature issue (I disabled the Maven Natures). Just wondering if there were any write ups on how to get one of these snmp4j projects set up?
I still recommend using MOStaticGroup for a primitive simulation agent. Why haven’t you tried it yet? Where do you expect problems with using MOStaticGroup?
Read-write operations are supported there too.
However, you will not be able to create new rows in tables, but for that you will need to know the SMI table definition, particularly the INDEX clause and the definition of the objects listed therein. Without that a working table cannot be implemented. But this won’t change by using MOScalar for table cell objects.
If you have that MIB module SMI definition, then AgenPro can fully generated a simulation agent as code or during runtime.
Regarding Maven: You can simply ignore Maven and compile with standard javac command line calls. Maven is not mandatory at all.
The StaticMOGroup can be used to easily implement static (read-only) managed objects.
Note: Dynamic variables (see Variable.isDynamic()) cannot be used to when using default VariableBindings since Variables are cloned when added to them. In order to use dynamic objects (i.e., objects that may change their value when being accessed), a sub-class of VariableBinding needs to be used that overwrites its VariableBinding.setVariable(org.snmp4j.smi.Variable) method.
I went ahead and tried implementing it as you suggested.
protected void registerManagedObjects() {
getSNmpv2MIB().unregisterMOs(server,getContext(getSnmpv2MIB()));
OID root = new OID("1.3.6.1.4.1");
VariableBinding[] array = {new VariableBinding(new OID("1.3.6.1.4.1.73.17.1.8.6.1.3.1.4.116.105.1.7479"), new OctetString("This is a test")), new VariableBinding(new OID("1.3.6.1.4.1.73.17.1.8.6.1.3.1.4.116.105.1.7480"), new OctetString("This is a test")) };
StaticMOGroup group = new StaticMOGroup(root,array);
server.register(group, new OctetString("public"))
}
Everything registers just fine and i can do SNMPGET calls, but I cannot make SNMPSET calls. When i try to set a value to the OID I get error status 2, “noSuchName: There is no such variable name in this MIB.”.
So I guess I need to go and extend a new subsclass from VariableBinding and Overwrite the setVariable method?
public void setVariable(Variable variable) {
if (variable == null) {
throw new IllegalArgumentException(
"Variable of a VariableBinding must not be null");
}
this.variable = (Variable) variable.clone();
}
How should i overwrite this to enable the use for dynamic objects?
Overwriting the setVariable method of VariableBinding will not help.
Instead create a subclass of StaticMOGroup and overwrite prepare, commit, undo, and cleanup methods to implement the SET operation.
Awesome! Great help Frank! I’ll definitely give that ago. I was also thinking about just making a subclass of MOScalar and overwriting the get and setValue methods to have append a “.0” to the end if it doesn’t already have one. I’ll probably look into over writing StaticMOGroup 's prepare,comit,undo,and cleanup methods first though.
.