Troubleshooting SNMP Trap UTF-String conversion problems in Event Console

Owned by Anastasios Thomaidis
Last updated: Dec 11, 2023 by Matthew Hierholzer
2 min read

NetApps delivers incorrect traps that 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.

LAST TESTED ON CHECKMK 2.2.0P1

Table of Contents

Problem

If the trap string contains only the elements equal to simple ASCII, the conversion is done without problems.

Wrong output:

SNMPv2-MIB::sysUpTime.0: 1800751479, NETAPP-MIB::productTrapData.0: 0x506f737369626c652076697275732064657465637465642e20567365727665723a2044415441504f52545ffgbb485f4e4f525f422c20767363616e207365727665722049503a2031302e36322e3130302e392c2066696c6520706174683a205c44415441504f52545f3030325f48485f564f4c315c44415441504f52545f3030325f48485f44415441315c44617461706f7274315c545c54435c5443325c544332335c496e7465726e5c4b756e64656e5c5a41465c44656c50726f665c5365727665726cc3b673756e675f6269735f323031375c5a41465f50726f66696c656cc3b6736368656e5c574f4c5c69707363616e2e6578652c20636c69656e742049503a20302e302e302e302c205349443a20532d312d352d32312d32fwdferdgg3736343733333730332d313137373233383931352d3532393634352c20767363616e20656e67696e65207374617475733a203232323230303030382c20767363616e20656e67696e6520726573756c7420737472696e673a205468652066696c652077617320746872656174656e65gfrgg776173207375636365737366756c6c792064656c657465642e2e, NETAPP-MIB::productSerialNum.0: 1-80-1533167


Correct output:

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

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:

          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? Nothing is defined in "DisplayString"; it could just as well be Latin-1 or a funny Windows code page.

If the device can send 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".