snmpsim icon indicating copy to clipboard operation
snmpsim copied to clipboard

mib2dev.py: automatic values hit ConstraintsIntersection

Open mbonnier-gv opened this issue 5 years ago • 5 comments

While generating a data set, mib2dev.py, I got the error:

 *** Inconsistent value: <ConstraintsIntersection .... '<ConstraintsUnion object at 0x7fd9feb73438 consts <SingleValueConstraint object at 0x7fd9feb73400 consts 1, 2, 3>  .... # Scalar PROFLINE-STARG2-MIB::starg2SetClockLockTo (type LockToSourceModes)

Processing this MIB entry:

starg2SetClockLockTo OBJECT-TYPE
   SYNTAX          LockToSourceModes
   MAX-ACCESS      read-write
   STATUS          current
   DESCRIPTION     "Lock the internal clock to the time received from an external source.
                    1 = off
                    2 = sntp over mgmt
                    3 = ntp over mpe"
   ::= { starg2SetClock 2 }

Since the script suggest me the proper values, is it possible to add an option so that the generator just pick one of them (randomly) ?

Is the option: [--automatic-values=<max-probes>] is the one used for that ?

EDIT: After I tried 15 MIBs from different companies, 8 cannot be synthesized ... mainly because of ConstraintsIntersection, or "invalid literal for int() with base 10" (generated value is a string 'kept Jaded...'

Thanks for this project,

mbonnier-gv avatar Mar 05 '19 19:03 mbonnier-gv

is it possible to add an option so that the generator just pick one of them (randomly) ?

Depending on the underlying type of LockToSourceModes, you may try --unsigned-range=<min,max> or --integer32-range=<min,max> option to set the range of all values of this type for the MIB you are simulating.

Once you have the initial .snmprec file, you could edit it by hand to adjust the values.

There is currently no option to limit the values of specific MIB objects, but it could be added.

etingof avatar Mar 05 '19 21:03 etingof

The --XXX-range options can't be used since they affects all the value.

The best would be to add the option, since the possible values are present in the error message.

One problem is that we don't want to go interactive - an interim solution would be to add an option to: output the variable name (as MIB::var) that can't be generated on stdout and continue.

The idea here is to generate some data ASAP when we develop. an SNMP driver.

mbonnier-gv avatar Mar 05 '19 23:03 mbonnier-gv

That seems doable. Let me see if I get a bit of time to work on this.

etingof avatar Mar 06 '19 07:03 etingof

That seems doable. Let me see if I get a bit of time to work on this.

Well, not quite, apparently. Trouble is that whenever we fail on SNMP table index, we effectively fail on the whole table row... There is a good chance that, for some tightly constrained table indices, we are unlikely to ever pick the right value. That leads to skipping the whole table, what makes this tool next to being useless.

That makes me think that the better course of action would be to "reverse" the constraints meaning the ability to generate samples out of constraints.

That would be the reflective operation in the sense that what we currently have is that we feed a value to the constraints tree to see if the value fits the constraints. What we'd need, I think, is given the constraints tree we produce a value which would satisfy the constraints.

etingof avatar Mar 07 '19 09:03 etingof

Indeed, that would the best solution and a more architecturally sound solution. Thanks. Still, the option to "not got interactive and just log the OID that cannot be resolved" would be an easy and quick way so that the script continue to run as long as possible.

mbonnier-gv avatar Mar 07 '19 16:03 mbonnier-gv