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