On 3/20/2012 12:58 PM, Charlie Martin wrote:
...
> Ah, hell. You know, trying to figure this stuff out from a standing
> start is like spending two months reading stereo instructions.
>
Amen to that. I'm in the same boat over here. It seems an order of
magnitude more complex than it should be.
On 20 March 2012 16:58, Charlie Martin wrote:
> Ah, hell. You know, trying to figure this stuff out from a standing start
> is like spending two months reading stereo instructions.
Which is why I tend to encourage people to walk for a while
(use the existing SNMP agent, and get a feel for how it
On 03/19/2012 02:46 AM, Dave Shield wrote:
> Though I'm not convinced that the MIB you are walking is valid.
> If these are a series of scalar objects, then the OIDs should all end in .0
> If they are part of a table, then all the values for a particular column
> object should be of the same type.
On 16 March 2012 22:03, Charlie Martin wrote:
> Now I try an snmpwalk
>
> 1006 $ snmpwalk -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1.2
> .1.3.6.1.4.1.59.1.5.3.1.1.2 = STRING: "91"
>
> Observe that it gets back only one reply
Yes - that is correct.
Snmpwalk says "give me everything start
Le 19.03.2012 00:12, Charlie Martin a écrit :
> Okay, one more case I want to be sure of. Let's assume that
> 1.3.6.1.4.1.59.1.5.3.1.1.10 is the numerically (as opposed to
> lexicographically) highest OID in the 1.3.6.1.4.1.59.1.5.3.1.1
> subgroup. How should the agent respond to
>
> $ snmpwalk /
Okay, one more case I want to be sure of. Let's assume that
1.3.6.1.4.1.59.1.5.3.1.1.10 is the numerically (as opposed to
lexicographically) highest OID in the 1.3.6.1.4.1.59.1.5.3.1.1
subgroup. How should the agent respond to
$ snmpwalk /*args*/ 1.3.6.1.4.1.59.1.5.3.1.1.10
and
$ snmpgetnex
Yup, I think that is it, merci beaucoup!
On 03/17/2012 03:24 AM, Vincent Bernat wrote:
>> snmpgetnext -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1
> You should get 1.3.6.1.4.1.59.1.5.3.1.1.1 = 9 (if I remember correctly)
>
> Maybe you don't handle this last bit in your pass_persist script:
OoO En cette nuit nuageuse du samedi 17 mars 2012, vers 00:02, Charlie
Martin disait :
>> Use:
>> snmpwalk -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1
> 1020 $ snmpwalk -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1
> .1.3.6.1.4.1.59.1.5.3.1.1 = No Such Instance currently exists a
On 03/16/2012 04:52 PM, Vincent Bernat wrote:
> Use:
> snmpwalk -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1
1020 $ snmpwalk -On -v 2c -c copan psmdev1 1.3.6.1.4.1.59.1.5.3.1.1
.1.3.6.1.4.1.59.1.5.3.1.1 = No Such Instance currently exists at this OID
Which actually corresponds to the o
OoO La nuit ayant déjà recouvert d'encre ce jour du vendredi 16 mars
2012, vers 23:03, Charlie Martin disait :
> Okay, so I've implemented a sub-agent using the pass_persist mechanism
> in net-SNMP. Testing with snmpget, I can get the values expected.
> Testing with snmpgetnext, I get the
Okay, so I've implemented a sub-agent using the pass_persist mechanism
in net-SNMP. Testing with snmpget, I can get the values expected.
Testing with snmpgetnext, I get the value of the "next" OID. Here's a
sample, slightly anonymized:
1004 $ snmpget -On -v 2c -c xxx dev1 1.3.6.1.4.1.59.1.5.
11 matches
Mail list logo
