Hello, I am seeing some odd behavior with an SNMP enabled Brother laser printer that I have (model MFC-9440cn). When I do an snmp walk on it's enterprise mib space, some tables that normally return a string type are instead returning the only hex character 0x0c, yet they identify the oid type as string instead of hex string.
Based on other data in the table being properly returned as a string, I am thinking that they are possibly using this to signal that the table "row" is null. Unfortunately, I am storing the SNMP data into an XML file, and since net-snmp is identifying it as a string rather than a hex-string, this makes my XML file invalid (you can't insert unprintable characters into an XML document, so reading it back with standard DOM parsers fails). So, my question is: Has anyone else seen this kind of behavior? Is there some kind of standard that I am unaware of that if an oid returns a type of string but the only thing returned is hex char 0x0c, that this is a "null string" identifier? Or, is this a "bug" in the SNMP implementation on the printer? Or, is it possible that net-snmp is not handling this properly and should be identifying the oid as a hex-string type? I am seeing this behavior with the latest net-snmp library, 5.4.1. Here is an example of a walk that is returning this (I replaced the unprintable 0x0c character, which in a command box shows up as a female symbol (presumably an IBM ASCII character), as "(female symbol)": C:\usr\bin>snmpwalk -c public -v 1 10.222.22.103 .1.3.6.1.4.1.2435.2.4.3.99.3.1. 2.1.2 SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.1 = STRING: "IN TRAY [2 TABLES] " SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.2 = STRING: " NAME TYPE SIZE ID MAX REMAIN " SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.3 = STRING: " TRAY1 STD A4 0 250 0 " SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.4 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.5 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.6 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.7 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.8 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.9 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.10 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.11 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.12 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.13 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.14 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.15 = STRING: "(female symbol)" SNMPv2-SMI::enterprises.2435.2.4.3.99.3.1.2.1.2.16 = STRING: "(female symbol)" Thanks for any insight, -------------------------------------------------------------- Bradley Navarro Senior Application Architect InControl Technology, Inc. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
