On 10/5/05, Jeff 'japhy' Pinyan <[EMAIL PROTECTED]> wrote:
> On Oct 5, Bobby Jafari said:
>
> > 1 $result = $session->set_request (
> > 2 -varbindlist => [ "${secPvcBulkModeOid}.${nextVcatIndex}" ,
> > INTEGER, "1",
> [...]
> > 9# "${secPvcUpdateTimeOid}.${nextVcatIndex}" ,
> > OCTET_STRING, '# 0x0C 0x01'
> > 10# "${secPvcUpdateTimeOid}.${nextVcatIndex}" ,
> > OCTET_STRING, "$keyUpdateTime"
> > 11 "${secPvcRowStatusOid}.${nextVcatIndex}" ,
> > INTEGER, "4" ] );
> >
> > The line with OCTET_STRING as the data type, is giving me grief.
> > According to the MIB definition, it should be in the form of # 0xHH
> > 0xMM Where HH and MM are hour and minutes in Hex format. My guess is
> > that the set-request is expecting a string but somehow PERL is passing
> > it as ASCI characters or ...
>
> Try sending it as "# 10 1" and see if it works. The Net::SNMP docs only
> show ONE example of using OCTET_STRING, and I'm not really sure what its
> rules about using "0x.." are. If that fails, try "# \x0c \x01", which is
> using actual hexadecimal escape sequences to produce character 10 and
> character 1.
>
I think this is the likely culprit. Net::SNMP may do some kind of
internal translation, but a single-quoted string '0x0C 0x01' may very
well be getting passed along as
'\0060\0170\0060\0103\0040\0060\0170\0060\0061', or something similar.
Also, keep in mind that 0x00 notation is hex notation in Perl, so even
if it is being translated, it's probably being translated incorrectly.
See Perlfaq4 'Why isn't my octal data interpreted correctly'
(http://perldoc.perl.org/perlfaq4.html#Why-isn't-my-octal-data-interpreted-correctly%3f).
If it were me, I'd try passing sprintf "%o" or "%O" formatted strings
and see if that didn't work better.
HTH,
--jay
--------------------------------------------------
This email and attachment(s): [ ] blogable; [ x ] ask first; [ ]
private and confidential
daggerquill [at] gmail [dot] com
http://www.tuaw.com http://www.dpguru.com http://www.engatiki.org
values of β will give rise to dom!
