Bug #27819 for Net-SNMP: message.pm mac address problem

Fri Jun 29 18:49:10 2007 mike [...] digg.com - Ticket created

Subject:	message.pm mac address problem
Date:	Fri, 29 Jun 2007 15:48:25 -0700
To:	bug-net-snmp [...] rt.cpan.org
From:	mike newton <mike [...] digg.com>

i noticed recently that some of my mac addresses weren't getting translated from octet-strings. i finally decided to take some time and figure it out and found that the function "_process_octet_string" in Message.pm seems to be using a character class to check against the 5th octet. unfortunately, this character class isn't matching a couple of my newer machines. the current match is on "/[\x01-\x08\x0b\x0e-\x1f\x7f-\xff]/g" and the 2 macs i have that aren't working right now are 00:30:48:79:2c:2e and 00:30:48:79:2c:36. clearly 2c won't match the char class since nothing between 20 and 7e are matched. is there a good reason for the fancy matching and not just matching on [0-9a-f]? thx +m -- mike newton digg.com

Sat Jun 30 08:40:42 2007 dtown [...] cpan.org - Correspondence added 1 min

The translation functionality of Net::SNMP attempts to make a best guess at presenting the received data in the most usable format. For OCTET STRINGs the trigger for translation was based on the definition of a DisplayString in RFC 2679: DisplayString ::= TEXTUAL-CONVENTION - the graphics characters (32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854 This is were the pattern match comes from. From the documentation: When the object decodes the GetResponse-PDU that is returned in response to a SNMP message, certain values are translated into a more ``human readable'' form. By default the following translations occur: * OCTET STRINGs and Opaques containing non-printable ASCII characters are converted into a hexadecimal representation prefixed with ``0x''. NOTE: The following ASCII control characters are considered to be printable by the module: NUL(0x00), HT(0x09), LF(0x0A), FF(0x0C), and CR(0x0D). If you know the "type" of the value to you will be querying, I usually recommend to users that they disable translation and do their own. ==== ($session, $error) = Net::SNMP->session( ... -translate => [-octetstring => 0x0], ... ); ... $oid = "<your OID>"; $response = $session->get_request(-varbindlist => [$oid]); printf("%s: %s\n", $oid, _format($response->{$oid})); ... sub _format { sprintf('0x%s', unpack('H*', $_[0])); } ==== -David

Sat Jun 30 08:40:44 2007 The RT System itself - Status changed from 'new' to 'open'

Sat Jun 30 08:40:45 2007 dtown [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Jun 30 08:40:48 2007 dtown [...] cpan.org - Given to DTOWN