Doubt regarding byte ordering in NetSNMP master agent and subagent

Hi,

I have a doubt regarding byte ordering in AgentX. I am using
NetSNMP-5-4-1. The snmpd process is my master agent which
communicates with subagent with a unix domain socket to retrieve data
from an external database. My low level routines are implemented using
mfd cache method.

I dumped the AgentX GET responses packets from my subagent coming in
and SNMP GET response packets going out of snmpd using "snmpd -f -d"
option, and noticed that my machine byte ordering is little endian.
All the AgentX data GET responses from my subagent is in little endian
format. And snmpd is converting this to big endian and then sending to
the manager. I tried this by getting a 4 byte value from the database
and it was appearing in little endian in AgentX response packet dump
and big endian in SNMP GET response dump.

But this conversion is not being done when I am doing a SNMP GET of
any ipaddress. I had an impression that the little-big endian
conversion would be done for any value as long as the NETWORK BYTE
ORDER bit flag in AgentX packet indicates little endian. So I did not
do any "htonl" when I loaded the container cache in
xxxTable_container_load() function. Does this mean that the subagent
has take care to do htonl before loading the container cache if the
variable type is ipaddress ? Or is it something master agent is
supposed to do and it is not doing for ip address alone ?

-rupa.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

On fre, 2008-05-30 at 10:35 +0530, Rupa P V wrote:
> Hi,
>
> I have a doubt regarding byte ordering in AgentX. I am using
> NetSNMP-5-4-1. The snmpd process is my master agent which
> communicates with subagent with a unix domain socket to retrieve data
> from an external database. My low level routines are implemented using
> mfd cache method.
>
> I dumped the AgentX GET responses packets from my subagent coming in
> and SNMP GET response packets going out of snmpd using "snmpd -f -d"
> option, and noticed that my machine byte ordering is little endian.
> All the AgentX data GET responses from my subagent is in little endian
> format. And snmpd is converting this to big endian and then sending to
> the manager. I tried this by getting a 4 byte value from the database
> and it was appearing in little endian in AgentX response packet dump
> and big endian in SNMP GET response dump.
>
> But this conversion is not being done when I am doing a SNMP GET of
> any ipaddress. I had an impression that the little-big endian
> conversion would be done for any value as long as the NETWORK BYTE
> ORDER bit flag in AgentX packet indicates little endian. So I did not
> do any "htonl" when I loaded the container cache in
> xxxTable_container_load() function. Does this mean that the subagent
> has take care to do htonl before loading the container cache if the
> variable type is ipaddress ? Or is it something master agent is
> supposed to do and it is not doing for ip address alone ?

IpAddress'es is encoded as an OCTET STRING(SIZE(4)) so there is no
conversion to be done, or, to quote the standard (rfc 2741):

- IpAddress, Opaque, and Octet String are all octet strings
and are encoded as described in section 5.3, "Octet
String", Octet String. Note that the octets used to
represent IpAddress are always ordered most significant to
least significant.

/MF


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

That means my little endian subagent has to take care of doing htonl
for ipaddress before sending out to the master ,as the master expects
it to be already in big endian format.
Thanks a lot for the reply.

On 5/30/08, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> On fre, 2008-05-30 at 10:35 +0530, Rupa P V wrote:
>> Hi,
>>
>> I have a doubt regarding byte ordering in AgentX. I am using
>> NetSNMP-5-4-1. The snmpd process is my master agent which
>> communicates with subagent with a unix domain socket to retrieve data
>> from an external database. My low level routines are implemented using
>> mfd cache method.
>>
>> I dumped the AgentX GET responses packets from my subagent coming in
>> and SNMP GET response packets going out of snmpd using "snmpd -f -d"
>> option, and noticed that my machine byte ordering is little endian.
>> All the AgentX data GET responses from my subagent is in little endian
>> format. And snmpd is converting this to big endian and then sending to
>> the manager. I tried this by getting a 4 byte value from the database
>> and it was appearing in little endian in AgentX response packet dump
>> and big endian in SNMP GET response dump.
>>
>> But this conversion is not being done when I am doing a SNMP GET of
>> any ipaddress. I had an impression that the little-big endian
>> conversion would be done for any value as long as the NETWORK BYTE
>> ORDER bit flag in AgentX packet indicates little endian. So I did not
>> do any "htonl" when I loaded the container cache in
>> xxxTable_container_load() function. Does this mean that the subagent
>> has take care to do htonl before loading the container cache if the
>> variable type is ipaddress ? Or is it something master agent is
>> supposed to do and it is not doing for ip address alone ?
>
> IpAddress'es is encoded as an OCTET STRING(SIZE(4)) so there is no
> conversion to be done, or, to quote the standard (rfc 2741):
>
> - IpAddress, Opaque, and Octet String are all octet strings
> and are encoded as described in section 5.3, "Octet
> String", Octet String. Note that the octets used to
> represent IpAddress are always ordered most significant to
> least significant.
>
> /MF
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders