Il 06/02/2011 12:03 AM, Wes Hardaker ha scritto: >>>>>> On Tue, 31 May 2011 12:07:48 +0200, Leo Cacciari >>>>>> <[email protected]> said: > > LC> I asked the same question on the user list, but I got (almost) no > LC> answer, hoping it was due to the bad choice of > LC> the list to post to, I ask it again here. > > The people that volunteer their time to answer questions on the lists > can't always promise a rapid turn around for answers. Many do it in > their spare time, in fact, on weekends and in the evenings. That > combined with the fact that your question was about a topic not many > understand means a lot of waiting :-/
I was prepared to do the waiting, I'm also looking elsewhere for help, computer science gods are like all other ones: they help better those that help themselves :) > > LC> First, am I talking sense above? :) > > Yep. That's fundamentally it. Internally to the library and agent, the > data is treated as an arbitrary blob. In reality you actually just need > to return a string (char *) and the length of the string and say "it's > an opaque" and off it goes. Ditto on receiving it. > That's reassuring :) > LC> Second, how about using the internal asn_* routines to implements > LC> encoders/decoders? Is this ok or are they too "internals" for safe use > LC> in a production application? Or are there other reasons why I > LC> shouldn't use them? > > Yep, you can use them if you like. That's a fairly common way to do > things like what you're talking about. > Ok, I was scared to have the API change under my feet with, as they are all marked 'internal'. > There are actually some other mechanisms that use encoded BER inside of > a OCTET STRING instead. In fact the SNMPv3 security parameters field is > actually an OCTET STRING containing BER data, as is the (potentially > encrypted) SCOPED PDU. If I read the code (and the RFCs) correctly, this is exactly how the Opaque type is defined. In fact, in SNMPv2-SMI we have Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING All this however, brings me to another point: AFAIK, there is no way for the user of snmpset to specify a type of opaque, which would be kind of useful in testing my application. I'm not talking about parsing arbitrary data from the command line, this seems too much work for what is worth. What I'm thinking is adding a 'X' type flag meaning something like "the data is to be sent as 'opaque' and here it follows the data itself ber-encoded and written as an hex string." This, for instance, would be quite enough for my needs. If the people on the list thinks this is worth a try and if there is someone willing to revise a patch, I'm willing try and write it. Leo -- 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. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
