...
| Info |
|---|
NetApps delivers incorrect traps which contain filenames in UTF-8 format. If these traps contain umlauts, |
...
the strings are displayed in HEX instead of string format, which is not RFC compliant. |
| Status |
|---|
| Table of Contents |
|---|
Problem
If the trap string contains only the elements equal to simple ASCII, the conversion is done without any problems.
Wrong output:
| Code Block | ||||
|---|---|---|---|---|
| ||||
SNMPv2-MIB::sysUpTime.0: 1800751479, NETAPP-MIB::productTrapData.0: 0x506f737369626c652076697275732064657465637465642e20567365727665723a2044415441504f52545ffgbb485f4e4f525f422c20767363616e207365727665722049503a2031302e36322e3130302e392c2066696c6520706174683a205c44415441504f52545f3030325f48485f564f4c315c44415441504f52545f3030325f48485f44415441315c44617461706f7274315c545c54435c5443325c544332335c496e7465726e5c4b756e64656e5c5a41465c44656c50726f665c5365727665726cc3b673756e675f6269735f323031375c5a41465f50726f66696c656cc3b6736368656e5c574f4c5c69707363616e2e6578652c20636c69656e742049503a20302e302e302e302c205349443a20532d312d352d32312d32fwdferdgg3736343733333730332d313137373233383931352d3532393634352c20767363616e20656e67696e65207374617475733a203232323230303030382c20767363616e20656e67696e6520726573756c7420737472696e673a205468652066696c652077617320746872656174656e65gfrgg776173207375636365737366756c6c792064656c657465642e2e, NETAPP-MIB::productSerialNum.0: 1-80-1533167 |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
SNMPv2-MIB::sysUpTime.0: 1800758647, NETAPP-MIB::productTrapData.0: Possible virus detected. Vserver: DATAPORT_002_HH_NOR_B, vscan server IP: 192.62.100.7, file path: \ABC_002_HH_VOL3\ABC_002_HH_XYZ\ABC\TEST\intern\V_07_Tools\PDFCreator\PDFCreator-1_7_1_setup.exe, client IP: 0.0.0.0, SID: S-1-5-21-2000478354-764733703-1177238915-529645, vscan engine status: 222200008, vscan engine result string: The file was threatened and was successfully deleted.., NETAPP-MIB::productSerialNum.0: 1-80-1235404 |
Solution
| Note |
|---|
| In a nutshell: The MIB is wrong, so either request a correct one from the manufacturer, build one yourself, or patch the existing one. Annoying, but unfortunately, this happens more often... |
There are several things wrong in the MIB or with the device (depending on how you look at it); in any case, they do not fit together. From the RFC 1213 (https://www.ietf.org/rfc/rfc1213.txt) RFC-1213-MIB.txt:
| Code Block | ||||
|---|---|---|---|---|
| ||||
DisplayString ::=
OCTET STRING
-- This data type is used to model textual information taken
-- from the NVT ASCII character set. By convention, objects
-- with this syntax are declared as having
--
-- SIZE (0..255) |
There you can see several things: A "DisplayString" can only contain ASCII and can be max . of 255 characters long. But the above example is 439 characters long and also includes a UTF-8 encoded "รถ" (2 bytes > 127). So the decoder has several reasons to reject the trap as invalid, but nicely it lets it pass, just in hex. Which encoding should it take? There Nothing is nothing defined in "DisplayString"; it could just as well be Latin-1 or a funny Windows code page.
If the device can send really long UTF-8 strings at this point, then there must be no "DisplayString" in the MIB, but something with a TEXTUAL-CONVENTION containing a DISPLAY-HINT of, e.g., "65535t".
...