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 <[EMAIL PROTECTED]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
