Yes, I did see such an example on the network, which is why I
tracked it down. We have an 'RMONster' PC package which turns a PC
into an RMON probe on loan, and it was rejecting my attempts to walk
it but would accept a sequence of 'getnext' requests to get the same
information.
Needless to say I only have a printed copy of the output of 'snmp
watch on', but I can type it all in if needed. The symptom is that
the FIRST request succeeds, but all further ones fail, e.g.
s0 walk i system { puts $i}
will return
{1.3.6.1.2.1.1.1.0 {OCTET STRING} {RMONster/e V1.1 SN# 123456}
and then get no response for any further requests, but
s0 getnext 1.3.6.1.2.1.1.1.0
will return
{1.3.6.1.2.1.1.2.0 {OBJECT IDENTIFIER} enterprises.536.3.1}
The two packets (the getnext from the walk and the standalone
getnext) are encoded as
3029 0201 0004 0670 7562 6c69 63a1 1c02
0463 857f @@02 0100 0201 ##30 0e30 0c06
082b 0601 0201 0101 0005 00
where the '@@' pair is '40' in the 'walk' and '41' in the 'getnext'
(which is expected, as this is the serial number of the request, and
so should change). The '##' is '10' in the 'walk' and '00' in the
'getnext', which is incorrect, as they are both SNMPv1 getnext
requests and so require this field to be zero.
Regards - Icarus