Hi
I’m getting the following error while doing SNMP get with SNMPv3: “Response PDU Too Big”.
For SNMPv2, I don’t get that error, but the data I get is incomplete, which leads me to the conclusion that it’s the same issue for both SNMPv3 and SNMPv2, but with different behavior. SNMPv2 doesn’t see it as a problem, but it’s still there: incomplete data because the response was too big.
Right after the error, there is a message “Continuing get…”, as shown below.
Get for param() had error : snmp->get() failed: SNMP: Response PDU Too Big, duration: 2407 ms
Continuing get for param()
The parameter in question is a standalone parameter, the only parameter in the group, so it’s not using MultipleGet.
When using SNMPv2, I can see the incomplete data I receive, which has 10239 characters before it’s abruptly cut. As I understand it, it’s less than the amount of data that should cause this issue, which would be 65535 bytes. That doesn’t mean that the total amount of data that should be received will be able to fit in that amount of bytes, because I don’t know how large a response can get.
What does this mean, and is there a way to resolve this? Is it possible to buffer these chunks of data I get until I have a complete response?
Resolved.
SLSNMPManager needs to parse the received bytes to appropriate types, for which it uses a buffer of 10240 bytes. With the current implementation, it 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).
Response in question had more data than buffer allowed.
Hi Ajdin,
Not sure, but I have the feeling the problem might be located in the device or system you are integrating, and then you won’t be able to work around that.
Maybe you can check with another SNMP tool if you can effectivity get this OID correctly. Or maybe you can check with Wireshark what goes back and forward on the wire. If you only get one OID, and the Response contains a SNMP error ‘PDU too big’, then there is a problem on the device or system and you would need to contact the vendor.
Bert
Thanks for answering, Bert.
Here are the findings from the Wireshark capture:
The response from the device is 37479 bytes long, so the response is fragmented into multiple frames due to the maximum allowed UDP package size. Those frames are then reassembled again.
Looking at the reassembled bytes in ASCII, I can see that it is a complete response. Based on that, I figured that device was able to successfully send that amount of data, but as far as I know, DataMiner is able to receive and handle more than that amount of bytes which is causing an issue in this case. Is that correct?
Using third-party SNMP tool GET was successful both for SNMPv2 and SNMPv3.