Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Problem

NetApps delivers incorrect traps which contain filenames in UTF-8 format. If these traps contain umlauts, then the strings are displayed in HEX instead of string format, which is not RFC compliant.
If the trap string contains only the elements equal to simple ASCII, the conversion is done without any 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. 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 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".



Filter by label

There are no items with the selected labels at this time.



  • No labels