I'm using SNMP4J to read info of devices with SNMP. Now I found some devices which represent the system name (OID iso.3.6.1.2.1.1.5.0) as a Hex-STRING instead of a STRING.
To show the system name I use the following code:
Variable var = response.getVariable(new OID(".1.3.6.1.2.1.1.5.0"));
System.out.println(var.toString());
Where response is a PDU object.
If the system name is represented as a STRING value, this goes as I expected. When it is represented as a Hex-STRING, it just prints the Hex value.
Example:
Take the name of the system as "SYSTEM NAME".
With STRING it prints "SYSTEM NAME".
With Hex-STRING it prints "53:59:53:54:45:4d:20:4e:41:4d:45"
Now with snmpwalk in command line I can just use the -Oa flag. This makes all Hex-STRING values show as STRING. Is it possible to use this flag in SNMP4J or is there a similar option?
I'm not sure where you're getting the term "Hex-STRING" from. SNMP does not define such a data type. I suggest you read through the relevant RFC documents, they are publicly available from IETF. The wikipedia article for SNMP (http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol#References) has an excellent reference list, you can start with browsing the ones marked as "STD".
In SNMP, all strings are subtypes (or in a different word, "restrictions") of OCTET-STRING, a byte string of indeterminate length. It may contain any data, even non-printable stuff, representing a jpeg image or whatever.
Some textual-conventions have been defined, which restrict the data to some specific byte range, or length. A DisplayString is defined to only contain bytes from the NVT ASCII character set, so the user may trust it to be printable.
In fact, sysName is defined to be a DisplayString with a max length of 255 characters.
sysName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
Since a good SNMP manager is aware of RFC1213-MIB, which defines both sysName and DisplayString, the manager should assume that the data received is printable ASCII characters.
When you say "When it is represented as a Hex-STRING", what do you mean? "Represented" where, on the agent or in your Java code or when using the net-snmp "snmpwalk" command?
The var.toString() call should convert the contents of the variable into something that could be safely printed in a terminal, so it's possible that SNMP4j is converting any binary string to a hex string.
Related
I need clarity related MAC SNMP oid .1.3.6.1.2.1.2.2.1.6.
The oid is retrieving data in two formats - octet string and hex string. Ex:
1) octet string .1.3.6.1.2.1.2.2.1.6.2 STRING: 00:01:80:5c:df:1c
2) hex string. .1.3.6.1.2.1.2.2.1.6.1 STRING: 30:30:3a:30:30:3a:30:30:3a:30:30:3a:30:30:3a:30:30
Hence while writing code logic, we need to handle both variety. But How to identify the retrieving data is octet string or hex string? Is this related to little endian or big endian concept? Any OID will provide us inform type of data. Kindly help.
This is specified in the relevant MIB. You should work with MIBs, not just numerical OIDs out of context. An OID just tells you which object is being referred to, but there is so much more information in the MIB about those objects, including their type and how they ought to be interpreted.
In fact there is no such thing as a HEX STRING; these are usually OCTET STRINGs with a display-hint that they should be shown to the user in hex-pair notation.
OCTET STRINGs don't have endianness; they're strings. Sequences.
Does PySNMP support Unicode for sending snmptrap. I sent trap with unicode character in it but I get the result in hex. Is there any work around to get the value in Unicode. e.g. Here is my snmp trap command
sudo snmptrap -v2c -c public 192.168.2.162 '' .1.2.3.4.5.6.7.8.9
ifIndex i 2 ifAdminStatus i 1 1.3.6.1.4.1.9.9.599.1.3.1.1.1.0 s "विवेक
सुवेदी"
But in the place of "विवेक सुवेदी", I got 0xe0a4b5e0a4bfe0a4b5e0a587e0a49520e0a4b8e0a581e0a4b5e0a587e0a4a6e0a580
. Is there any way to get unicode?
AFAIK, to properly render UTF-8 strings, MIB object (1.3.6.1.4.1.9.9.599.1.3.1.1.1.0) should be typed as some TEXTUAL-CONVENTION having DISPLAY-STRING="255t" that indicates UTF-8 string.
If that is not the case, SNMP will treat it as a binary string and will not attempt to render it properly. The same happens if you do not use MIB resolution (what converts pure ASN.1/SNMP types into MIB-defined subtypes) and deal with pure ASN.1 objects.
In the latter case a hackerish solution is to skip .prettyPrint()-ing values through SNMP and use them as-is via .asOctets:
>>> print(OctetString(u'кириллица'.encode('utf-8')).asOctets())
кириллица
The problem here is that you might have to programmatically apply this logic to specific OIDs -- this is what MIB is designed for. ;)
I have searched many a page on wikipedia, the official GS1 specifications, but have yet to find a definite answer to the question
What is the actual HEX / binary value of the GS1 FNC1 character?
There is much information about how to use the GS1 identifiers, how to print the barcodes with ZPL and how to encode the FNC1, but I want to know the actual HEX value of that character.
The special function characters such as FNC1 through FNC4 belong to the class of "non-data characters" that can be encoded within various barcode symbologies but with do not have any direct ASCII representation in the decoded data stream. Each symbology that supports such characters has a different scheme for encoding them in its internal representation quite distinct from any byte-orientated character data.
The FNC characters serve both as flag characters (indicating something special to the reader) and as formatting characters (modifying the meaning of the encoded data). As such they are not intended to be transmitted directly in the data received by the host system from a basic barcode reader, although in both cases they may have an "effect" on the transmitted message.
The usual purpose of each of the FNC characters are as follows:
FNC1 - Structured Data flag character indicating GS1 and AIM formatting AND group separator formatting character, amongst other uses.
FNC2 - Message Append flag character for buffering the data in groups of symbols for a single read.
FNC3 - Reader Programming flag character for device configuration purposes.
FNC4 - Extended ASCII formatting character for encoding characters with ordinals 128-255.
Be aware that they may not all be available in certain barcode symbologies and may even be specified in different, non-typical or overloaded ways.
Encoding an FNC character in a symbol's internal data is accomplished via an "escape mechanism" that is specific to the encoding software. Each library has a different way of accepting these non-data characters within their input. For example, to use FNC1 in its typical GS1 structured data role for the data "(01)00312345678906(21)123456789012(30)0144" you might see the FNC1 characters escaped as {FNC1} so that the input looks like {FNC1}010031234567890621123456789012{FNC1}300144.
Some libraries will even use a set of regular or extended ASCII characters as placeholders for the FNC characters, but these are arbitrary representations and it is a mistake to consider them to be actual ASCII values for these non-data characters.
Upon scanning a barcode the symbol's internal data is typically decoded then transmitted to the host over a basic channel (e.g. keyboard wedge) as a sequence of bytes to be interpreted according to the Latin-1 character encoding. The FNC characters cannot be represented in such a manner and are excluded from the data stream, however their formatting effect on the data remains.
For instance, the standards for most symbologies specify that when an FNC1 character is being used in its role as a field separator in data conforming to GS1 Application Identifier Standard Format it should be decoded and transmitted as GS (ASCII 29). Explicitly stated, the formatting effect of a FNC1 character used as a GS1 Application Identifier separator is to place a GS character at the end of the variable-length field. But in other roles (such as when FNC1 is used in "first/second position" as a flag character and with non-GS1 formatted data) there is no formatting effect on the carried data and therefore no ASCII representation during decoding.
Another instance of the special function characters having a formatting effect on the data is with symbologies that use FNC4 to extend their reach from 7-bit ASCII into extended ASCII as described in this answer.
A subtle technical point is that the data transferred to the host is often prefixed with a short symbol indicator header known as a "symbology identifier" which denotes the type and usage of the symbol from which the data is being read. This is often modified by the presence of otherwise invisible flag characters within the symbol data, for example to indicate the presence of GS1 formatted data with "FNC1 in first" or to indicate reader programming mode when FNC3 appears anywhere in the symbol. The details are symbology specific.
Aside: In addition to FNC non-data characters, there are other non-data characters commonly supported by barcode symbologies that have no direct ASCII representation but affect the overall message. These include macro characters (that wrap the message data in an "envelope"), and ECI indicators that require the use of a transmission protocol beyond the typical "basic channel" mode but which enable the use of extended character sets amongst other enhancements.
Important is to know (and to setup a scanner properly) that the FNC1 character at the first position is translated to a symbology identifier according ISO/IEC 15424. The modifier m of the symbology identifier shows if there was a FNC1 or not. If this is not done the application cannot see anymore if a GS1 Structure was intended or not. Other structures are identified by e.g. Macro 06 in a data matrix code (ISO/IEC 16022, ISO/IEC 15434). Its required to figure our the difference to take the correct action to process the data.
Is it possible to detect the user's string's char set?
If not, how about the next question..
Are there reliable built-in PHP functions that can accurately tell if the user supplied string ( be it supplied thru get/post/cookie etc), are in a UTF-8 or not? In other words, can I do something like
is_utf8($_GET['first_name'])
Is there anyway this function could produce a TRUE where in reality the first_name was not in UTF-8?
Regarding 1:
You can give mb_detect_encoding a try, but it's pretty much a shot in the dark. An "encoded" string is just a bunch of bytes. Such byte sequences are often equally valid in any number of different encodings. It's therefore by definition not possible to detect an unknown encoding reliably, you can only guess. For this reason there exist meta information such as HTTP headers which should communicate the encoding of the transferred content. Check those if available.
Regarding 2:
mb_check_encoding($var, 'UTF-8') will tell you whether the string is a valid UTF-8 string. As far as I've seen, in recent versions of PHP it does what it says on the tin. That still doesn't mean the string is necessarily really a UTF-8 string, it just means the byte sequence is in an order that is valid in UTF-8.
Does anyone know the format of the MAPI property PR_SEARCH_KEY?
The online documentation has this to say about it:
The search key is formed by
concatenating the address type (in
uppercase characters), the colon
character ':', the e-mail address in
canonical form, and the terminating
null character.
And the exchange document MS-OXOABK says this:
The PidTagSearchKey property of type
PtypBinary is a binary value formed by
concatenating the ASCII string "EX: "
followed by the DN for the object
converted to all upper case, followed
by a zero byte value.
However all the MAPI messages I've seen with this property have it as some sort of binary 16 byte sequence that looks like a GUID. Does anyone else have any more information about it? Is it always 16 bytes?
Thanks!
I believe that the property PR_SEARCH_KEY will be of different formats for different objects (as alluded to by Moishe).
A MAPI message object will have a unique value assigned on creation for PR_SEARCH_KEY, however if the object is copied this property value is copied also. I presume when you reply to an e-mail, Exchange will assign the PR_SEARCH_KEY value to be the original message's value.
You will need to inspect each object type to understand how the PR_SEARCH_KEY is formed but I doubt if it's always 16 bytes for all MAPI types.
This link USENET discussion has a good discussion with Dmitry Streblechenko involved who is an expert on Extended MAPI.
The sentence before the ones you quoted from the online docs reads, "MAPI uses specific rules for constructing search keys for message recipients" which makes me think that it's talking about the PR_SEARCH_KEY property on MAPI_MAILUSER objects -- or at least not on MAPI_MESSAGE objects.