[prev in list] [next in list] [prev in thread] [next in thread] 

List:       net-snmp-coders
Subject:    Using opaque type
From:       Leo Cacciari <leo.cacciari () gmail ! com>
Date:       2011-05-31 10:07:48
Message-ID: 4DE4BDF4.20905 () gmail ! com
[Download RAW message or body]

Hi,
  I asked the same question on the user list, but I got (almost) no answer, hoping it \
was due to the bad choice of the list to post to, I ask it again here.

  I'm writing a SNMP (sub)agent which would provide access using SNMP to some data, \
defined and held by  an 'out-of-my-control' system (out-of-my-control in the sense I \
have no way to change anything to its specification and/or implementation.) Besides \
data easily mapped on SNMP data types (such various length integers or floats) there \
are user defined types and sequences, both of basic and user-defined types. 

I can agree that SNMP may not be the right approach to accessing these data, but that \
was decided by the powers that be. )As we say in Italy "donkeys should be tied where \
the master want..." ;) )

Although rfc2578 says that "The Opaque type is provided solely for \
backward-compatibility, and shall not be used  for newly-defined object types." it \
seems to me that using this type is the only logical approach, seen that (still  the \
same rfc speaking) "The Opaque type supports the capability to pass arbitrary ASN.1 \
syntax". 

If I understand correctly the documentation and the code, with this approach I would \
have to write routines for encoding/decoding the application data types into a buffer \
accordingly to some ASN.1 encoding scheme (presumably BER or CER). 

For sending a value, I  should then use the relevant encoder function and pass the \
buffer, its length and a type of ASN_OPAQUE to  snmp_set_var_typed_value for setting \
the output variable. 

Conversely, upon reception, a value for a variable (either from the agent side or the \
client one) would have var->type == ASN_OPAQUE while var->val.string would point to a \
buffer of length var->val_length holding an octet string whose content (in ASN.1 \
sense) would in turn be my data... (ouf...).  
My question to the collective wisdom is thus two fold:

First, am I talking sense above? :) 

Second, how about using the internal asn_* routines to implements encoders/decoders? \
Is this ok or are they too "internals" for safe use in a production application? Or \
are there other reasons why I shouldn't use them?

Thanks in advance to anyone providing help..

-- 
Leo Cacciari
Aliae nationes servitutem pati possunt populi romani est propria libertas


------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


[prev in list] [next in list] [prev in thread] [next in thread]