5

While I am learning about SNMP, I have some questions on SNMP string operations:

  • What is the maximum size of the string?
  • If we have read permission on string how can you determine the size?
  • The string can basically accept all types of character (like #$%^& etc). How can they be restricted?
Burhan Ali
  • 2,258
  • 1
  • 28
  • 38
Mallikarjunarao Kosuri
  • 1,023
  • 7
  • 25
  • 52

4 Answers4

4

In SNMP there is no string concepts. OCTET STRING is not a real string (compared to high level programming languages such as Java and C#), as this data structure has nowhere to store encoding information. Well, this is really horrible.

The maximum string size is only limited by SNMP network packet size, so you should go to TCP/IP protocol for an answer. No SNMP RFC defines a maximum length.

I personally consider OCTET STRING as an array of bytes, so any characters can be stored in it. If you want to restrict them, you should do it in your SNMP agent/engine implementation. When an "invalid" character is found, you can return an SNMP error. Details can be found in RFC 3416 4.2.1. or RFC 1157, 4.1.5.

Lex Li
  • 60,503
  • 9
  • 116
  • 147
3

An OCTET STRING may contain any sequence of octets, so there is no guarantee that they are printable characters.

Many other "types" are based on OCTET STRING, by adding restrictions. IpAddress, for example, is simply an OCTET STRING restricted to four bytes. This is defined in a Textual Convention definition in a MIB module. RFC1155-SMI contains the definition for IpAddress.

If you're trying to choose the type of a variable, such as when designing a MIB module, you should try to be as restrictive as possible, because this is more informative to the user of the MIB module.

Particularly, don't use OCTET STRING if you know the string should be printable. Instead choose SnmpAdminString (for almost all purposes) or DisplayString (if you are absolutely sure that the data will only contain ASCII characters, and no extended characters like accents & non-roman characters). Both are restricted to 255 octets, which is reasonable for most network management purposes. If you want to transfer larger amounts of data than this, maybe you are trying to do something that SNMP was not designed to facilitate.

Jolta
  • 2,620
  • 1
  • 29
  • 42
  • Both DisplayString and SnmpAdminString are defined like this: DisplayString ::= OCTET STRING So it's just an OCTET STRING – Andrew Komiagin Mar 24 '15 at 14:22
  • Do you have a source for that statement? I base my answer on RFC-1213, section 3.2, which says: "In the past, there have been misinterpretations of the MIB as to when a string of octets should contain printable characters, meant to be displayed to a human. As a textual convention in the MIB, the datatype `DisplayString ::= OCTET STRING` is introduced. A `DisplayString` is restricted to the NVT ASCII character set, as defined in pages 10-11 of [6]." – Jolta Mar 25 '15 at 15:36
  • That's true. I'm saying that both both DisplayString and SnmpAdminString are BER-encoded as OCTET STRING on packet level. So there is no difference between those on implementation level. – Andrew Komiagin Mar 25 '15 at 15:41
  • That is also true. My answer is about how the types should be _used_, which is not, strictly speaking, related to how they are encoded. In particular, a program receiving an unrestricted OCTET STRING should take great care to properly handle non-printable characters. Likewise, a program whose MIB claims it will send a DisplayString, must be designed to not transmit non-ASCII characters. – Jolta Mar 25 '15 at 18:36
  • I'd use DisplayString for MIB object definition where you deal with printable stuff. But you have to keep in mind that SNMP library does not care about your MIB definition, it will treat it as OCTET STRING. – Andrew Komiagin Mar 25 '15 at 18:41
  • The library, no, surely not, but your application code _certainly_ should care about the MIB definition, and make sure not to send non-printable data in a DisplayString. If not, you're doing SNMP wrong. Others will trust your MIB declarations, and you _will_ break their integrations if you don't follow the types you've declared. (Which should be easy to do, anyway, so why not?) – Jolta Mar 25 '15 at 18:43
  • Totally agree. Also the application should take DisplayHint into account – Andrew Komiagin Mar 25 '15 at 18:44
-2

The OCTET STRING does not have any size limitations. The only limitation here is that SNMP uses UDP as transport protocol. So the MTU=1500. That's you max size.

Andrew Komiagin
  • 6,446
  • 1
  • 13
  • 23
  • 3
    You are thinking of the maximum size of an Ethernet frame. UDP packets may be fragmented across multiple Ethernet frames. – Michael Kirkham Aug 07 '17 at 13:28
  • Sure they will be fragmented, but there is no guarantee that they will be assembled due to unreliable nature of UDP. – Andrew Komiagin Aug 07 '17 at 17:46
  • Yes. But that still doesn't impose a fundamental limit on OCTET STRING size, only a practical one, under conditions that would make a non-fragmented UDP packet just as likely to be dropped, unless there's a hop along the way that doesn't support fragmentation, and you are also assuming UDP. UDP is not the only transport for SNMP. SNMPv3 itself specifies msgMaxSize range is (484..2147483647). 2147483647 is a fair bit larger than 1500. – Michael Kirkham Aug 07 '17 at 18:03
  • There *is* a fundamental limit to an OCTET STRING size *if* the OCTET STRING is to be used as an INDEX, as SNMP limits OBJECT IDENTIFIERS to 128 subidentifiers. – Michael Kirkham Aug 07 '17 at 18:08
  • True, but in real life the UDP is used as transport protocol in 99.99999% of all existing SNMP agents. – Andrew Komiagin Aug 07 '17 at 18:09
  • 1
    There are quite a few IETF standard MIBs that define data types with OCTET STRING SIZEs > 255, and some > 1500. ADSL2-LINE-MIB, VSDL2-LINE-MIB, SNMP-TLS-MIB, several others with SIZE up to 1024, for example. DOCS-IETF-BPI2-MIB up to 4096. etc. – Michael Kirkham Aug 07 '17 at 18:16
-2

The only limitation is that SNMP uses UDP as transport protocol - I agree. However, MTU for UDP is 64k. Refer to https://en.wikipedia.org/wiki/User_Datagram_Protocol. MTU=1500 is for Ethernet standard packets. So, in this case max size is 64k.

Marcin Nowakowski
  • 1
  • This does not seem the answer any of the three questions in the Q. UDP is not the only permissible transport for SNMP. – Jolta Aug 08 '17 at 08:16