| Info |
|---|
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. |
| Status |
|---|
| colour | Green |
|---|
| title | LAST TESTED ON CHECKMK 2.2.0P1 |
|---|
|
Problem
If the trap string contains only the elements equal to simple ASCII, the conversion is done without problems.
Wrong output:
| Code Block |
|---|
|
SNMPv2-MIB::sysUpTime.0: 1800751479, NETAPP-MIB::productTrapData.0: 0x506f737369626c652076697275732064657465637465642e20567365727665723a2044415441504f52545ffgbb485f4e4f525f422c20767363616e207365727665722049503a2031302e36322e3130302e392c2066696c6520706174683a205c44415441504f52545f3030325f48485f564f4c315c44415441504f52545f3030325f48485f44415441315c44617461706f7274315c545c54435c5443325c544332335c496e7465726e5c4b756e64656e5c5a41465c44656c50726f665c5365727665726cc3b673756e675f6269735f323031375c5a41465f50726f66696c656cc3b6736368656e5c574f4c5c69707363616e2e6578652c20636c69656e742049503a20302e302e302e302c205349443a20532d312d352d32312d32fwdferdgg3736343733333730332d313137373233383931352d3532393634352c20767363616e20656e67696e65207374617475733a203232323230303030382c20767363616e20656e67696e6520726573756c7420737472696e673a205468652066696c652077617320746872656174656e65gfrgg776173207375636365737366756c6c792064656c657465642e2e, NETAPP-MIB::productSerialNum.0: 1-80-1533167 |
Correct output:
| 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? 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".
Related articles
| Filter by label (Content by label) |
|---|
| showLabels | false |
|---|
| max | 5 |
|---|
| spaces | CON |
|---|
| showSpace | false |
|---|
| sort | modified |
|---|
| reverse | true |
|---|
| type | page |
|---|
| cql | label in ( "event_console" , "troubleshooting" ) and type = "page" and space = "KB" |
|---|
| labels | event_console |
|---|
|