Yixiong,

I have some OID parse errors for InetAddress. I realize that you have
patch 841625 updated. I am not sure whether I am using the old patch or
updated one. Could you please pass me the updated one.

I have a problem to get this updated patch from Net-SNMP site. In the
following link, I tried to click "Download", it gives the file in some
html format, which is hard to see the code (no line break). Could you
please, send me one or teach me how to get it. I am in hurry to fix this
one.

Thanks,

Fong



-----Original Message-----
From: Zou, Yixiong [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 20, 2003 6:14 PM
To: Fong Tsui; [EMAIL PROTECTED]
Subject: RE: PATCH: OID encoding display for iNetAddress 

Here's the link to the updated patch.  Sorry for sending two emails for
this. 

http://sourceforge.net/tracker/index.php?func=detail&aid=841625&group_id
=12694&atid=312694

------------------------------------------------------------------------
Yixiong Zou ([EMAIL PROTECTED])
(503) 677-4988

All views expressed in this email are those of the individual sender.  

> -----Original Message-----
> From: Fong Tsui [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 20, 2003 5:50 PM
> To: Zou, Yixiong; [EMAIL PROTECTED]
> Cc: Dave Shield
> Subject: RE: PATCH: OID encoding display for iNetAddress
> 
> 
> Tried this patch. It works. Thanks!
> 
> Fong
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Zou,

> Yixiong
> Sent: Wednesday, November 12, 2003 11:47 PM
> To: [EMAIL PROTECTED]
> Cc: Dave Shield
> Subject: PATCH: OID encoding display for iNetAddress
> 
> 
> Hi Dave,
> 
> I made this patch that seems to fix the problem of displaying 
> iNetAddress in a OID, though I am not 100% sure.
> 
> Basically, here's what I did:
> 
> if (tree_node -> tc_index == iNetAddress) and if (tree_node -> 
> next_peer -> tc_index == iNetAddressType)
>     then handle_using_iNetAddress_format; else
>     normal_handling
> 
> All this is happening inside mib.c::_get_realloc_symbol(). 
> 
> There are two assumptions that I made: 
> 
> 1) tree_node -> next_peer -> tc_index == iNetAddressType. 
> 
> If this is not the case, then I don't do anything.  So at least I am 
> not make any damages.  In all my test cases, the node that has the 
> token 'iNetAddressType' always showed up as the "next_peer" node of 
> the 'iNetAddress', which is great.  But I have no idea why this is 
> happening and I am not sure if this will always be the case.
> 
> 2) I assumed the iNetAddressType is always the node that's right in 
> front of the iNetAddress.  So far in all the mibs this is the case.
> So I got the iNetAddressType using *(objid - 1).  It will be better if

> this iNetAddressType can be correlated using that 
> tree_node->next_peer, but I couldn't find any relationship.
> 
> I did some basic testing and a IPv4 address showed up as: 
> ...3.ipv4."172.16.1.0"....
> and IPv6 address showed up as ...3.ipv6."3f:fe:ff:ff:01:00:f1..."...
> I left the "" around because I think that is the way it should be, 
> based on the Display hint of these types.  But if not the case, I can 
> quickly change them.
> 
> Hope this helps.  
> 
> --------------------------------------------------------------
> ----------
> Yixiong Zou ([EMAIL PROTECTED])
> (503) 677-4988
> 
> All views expressed in this email are those of the individual sender.
> 
> > -----Original Message-----
> > From: Dave Shield [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, November 11, 2003 2:37 AM
> > To: Zou, Yixiong
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Help needed on OID encodings for InetAddressType
> > 
> > Yes - because InetAddress is simply defined as a string (with no 
> > further DISPLAY-HINTs)
> > 
> > You need to distinguish between the OID value, and how it is 
> > displayed.
> > It's up to the agent to return the correct OID value.
> > I.e. with InetAddressType and InetAddress length subidentifiers, 
> > followed by the individual subidentifiers from the address value 
> > itself.
> > (Plus whatever the other index objects were).
> > 
> > That's separate from how the management application (snmpwalk) will 
> > display this OID.  Whether it tries to interpret the
> indexes, and how
> > it does so.
> >    The Net-SNMP toolkit does not recognise
> InetAddressType/InetAddress
> > as anything special, so doesn't have any special processing
> hardcoded
> > in. Unfortunately, the correct representation of such
> values cannot be
> > handled purely from the MIB syntax definitions.  It needs to take 
> > account of the textual description - i.e. the semantics of the
> type, not just
> > the bare syntax.
> > 
> >   Without this special handling (which we don't have), then
> snmpwalk
> > doesn't know how to interpret the value, so makes the best guess it 
> > can (i.e. treats an octet string as a printable string).
> > 
> > As has been suggested, the -Ob option won't try to interpret index 
> > values at all.
> > 
> > Dave
> > 
> > 
> 



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to