Dave Shield wrote:
Proposals from the top of my head:
test-mibsupport
How about (aiming a little lower!):
make test-mibs
If this doesn't add to the ubiquitous confusion between MIBs and MIB
*implementations* (probably not significantly): yes.
Also, README.agent-mibs should tell about
On Mon, 2005-09-05 at 13:35 +0200, Thomas Anders wrote:
> Dave Shield wrote:
> > My inclination would be to have a separate make target.
> > So
> > make test
> > would check whether the suite was behaving properly,
> > and
> > make test-mibII
> > would report what ob
Dave Shield wrote:
My inclination would be to have a separate make target.
So
make test
would check whether the suite was behaving properly,
and
make test-mibII
would report what objects the agent implemented.
Agreed in principle, but I find "test-mibII"
On Tue, 2005-08-30 at 11:41 -0400, Robert Story wrote:
> On Tue, 23 Aug 2005 10:03:25 +0100 Dave wrote:
> DS> The problem with the RFC1213 tests is that they blindly assume
> DS> that all the objects being tested will be available (on every
> DS> architecture). So a missing object (which is *known
On Tue, 23 Aug 2005 10:03:25 +0100 Dave wrote:
DS> The problem with the RFC1213 tests is that they blindly assume
DS> that all the objects being tested will be available (on every
DS> architecture). So a missing object (which is *known* to be
DS> missing on a particular system) will cause the test
Johannes Schmidt-Fischer wrote:
> >I'd vote for a separate probably optional test block which tests the
> >availability of most (or all) mib-II variables and maybe also other MIB
> >variables (like the host MIB). This test block should in no case stop
> >the build process, but it could become part
On Mon, 2005-08-22 at 20:15 +0200, Johannes Schmidt-Fischer wrote:
> Dave Shield wrote:
> > In general, we've tended to regard each test as completely independent
> > of the others. In principle, it'd be perfectly possible to run *just*
> > tests 48 and 49 (without running 47 first) So I'd be r
Bruce Shaw wrote:
> I'm not sure what you're asking for.
>
> I've already got a HOST-RESOURCES-MIB test in CVS Main and 5.1.
I meant to remove the tests 47, 48 and 49 from the standard test runs
and to build a separate test "package" which checks what mib-II
variables are available for any platfo
I'm not sure what you're asking for.
I've already got a HOST-RESOURCES-MIB test in CVS Main and 5.1.
>I'd vote for a separate probably optional test block which tests the
>availability of most (or all) mib-II variables and maybe also other MIB
>variables (like the host MIB). This test block shou
Dave Shield wrote:
>>Due to what you wrote running the tests the way they're done at present
>>might be right or slightly wrong. They're right in that all OID's that
>>are expected to exist will be treated as failed in test 47 and that in
>>the tests 48 and 49 these OID's need not be handled as fai
> Due to what you wrote running the tests the way they're done at present
> might be right or slightly wrong. They're right in that all OID's that
> are expected to exist will be treated as failed in test 47 and that in
> the tests 48 and 49 these OID's need not be handled as failed again.
H.
Dave Shield wrote:
> On Mon, 2005-08-22 at 16:19 +0200, Johannes Schmidt-Fischer wrote:
>
>
>>The snmpget command seems to have two problems (or errors):
>>
>>a) for SNMPv1 snmpget returns an error code 2 when the given OID doesn't
>>exist, but for SNMPv2c and SNMPv3 snmpget returns an exit code
On Mon, 2005-08-22 at 16:19 +0200, Johannes Schmidt-Fischer wrote:
> The snmpget command seems to have two problems (or errors):
>
> a) for SNMPv1 snmpget returns an error code 2 when the given OID doesn't
> exist, but for SNMPv2c and SNMPv3 snmpget returns an exit code 0 whether
> the given OID
Hello,
in building net-snmp 5.1.2.1 I found some strange behaviour when running
the tests (which happens implicitly when using dist/nsb-package btw).
There is an OID (ipRoutingDiscards.0) which I know isn't available for
e.g. HP-UX 10.20, 11.0 and 11i. As I saw in the tests this OID is
checked us
14 matches
Mail list logo
