On 17/04/07, Lothar Werzinger wrote:
> > I probably need to sit down with the AgentX and SNMP
> > specs, and work through exactly how these value
> > ought to be encoded, and what is going wrong.
> >
> > But can you please try the same exercise using the
> > command-line option "-Ddump"



OK - I'm beginning to see what might be going wrong.
>From the dump you sent me, there are two significant

fragments:

Apr 17 15:44:07 zaphod snmpd[10347]: dumph_recv: AgentX Header
Apr 17 15:44:07 zaphod snmpd[10347]: dumph_recv: Version
Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_recv: 01
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv: Version: 1
Apr 17 15:44:07 zaphod snmpd[10347]: dumph_recv: Command
Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_recv: 12
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv: Command: 18 (Response)
Apr 17 15:44:07 zaphod snmpd[10347]: dumph_recv: Flags
Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_recv: 00
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv: Flags: 0x0
Apr 17 15:44:07 zaphod snmpd[10347]: dumph_recv: Reserved Byte
Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_recv: 00
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv: Reserved: 0x0

Note that Flags is 0x0, so according to RFC 2741, section 6.1:

The NETWORK_BYTE_ORDER bit applies to all multi-byte integer
values in the entire AgentX packet, including the remaining
header fields. If set, then network byte order (most
significant byte first; "big endian") is used. If not set,
then least significant byte first ("little endian") is used.

this packet should be using "little endian" encoding.


Then later in the dump, after

Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv:
OID SNMPv2-SMI::enterprises.424242.1.2.1.0

comes

Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_recv: 00 00 00 00
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv: Integer:^I0 (0x00)
Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_recv: 92 10 00 00
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_recv:
Integer:^I4242 (0x1092)

which is the value of this counter.
The second four octets contain the desired value (4242),
but remember that we're working in 'little endian' order, so
these actually represent the upper 32-bits of a 64-bit value.
The full value is therefore 0x 00001092 00000000
i.e. 18219251269632

which is exactly the value being returned by the master agent:

Apr 17 15:44:07 zaphod snmpd[10347]: dumph_send: PDU-RESPONSE
Apr 17 15:44:07 zaphod snmpd[10347]: dumph_send: VarBind
Apr 17 15:44:07 zaphod snmpd[10347]: dumph_send: Value
Apr 17 15:44:07 zaphod snmpd[10347]: dumpx_send: 46 06 10 92 00 00
Apr 17 15:44:07 zaphod snmpd[10347]: dumpv_send: U64: 0 18219251269632


So the problem lies with the subagent, in the encoding of the response.
It's got the two halves of the counter64 value the wrong way round.

I've looked at the code for encoding Counter64 values (in agentx/protocol.c)
and at first glance it looks OK.

Can you try setting the same '-Ddump' debugging flag for your AgentX
subagent, and report what this displays when sending this response?
(Don't bother zipping up the log - raw text should be fine.)

Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users