Hi Ajdin,

I have to make an edit to the original response, since we just discovered a quirk in SLSNMPManager that we weren’t aware of.

SLSNMPManager needs to parse the received bytes to appropriate types, for which it uses a buffer of 10240 bytes. With the current implementation, we can read up to 10239 bytes for a single OID value of the type octets, bits, or opaque (these may be called differently in the protocol xml’s SNMP type element).

However, theoretically (original response):

I believe SNMP can’t split parameters over multiple SNMP responses. Each SNMP response is a UDP/IP packet that can only be 65535 bytes long (the length field is 2 bytes). The SNMP, UDP and IP headers need some room, which seems to leave 65453 bytes for a single parameter when the OID is 1.3.6.1.4.1.8813.50.24.2.6.0.

However, larger OIDs seem to leave less room for data, for example, I only managed to send 64876 bytes when my OID was 1.3.(4294967295){117}.0 (i.e., 117 times the largest OID sub-identifier).

That being said, this may also depend on the device’s firmware. It may only provision a buffer of 64kB for example.