Hi,
I encountered that the request-id of some protocols/elements goes into negative (I assume a integer overflow).
The related device answers with a "normal" positive request-id.
I assume, that the dataminer cannot match this response to the request it send, so the element goes into timeout.
In the past a restart of the element in the dataminer was a possible workaround to reset the ID.
Not sure if it is now not longer possible with the dataminer version (10.1.0.0-10049-CU1) we are using or if it is driver related.
So the question is, how can i prevent the usage of "unnormal" negative request-id's, to get rid of the root problem without a workaround? As I don't write protocols, is the request-id handling specified in the protocol or in the dataminer core software? Where do i need to look for this?
-> get-request
-> get-respond
Best Regards
Thomas
A request ID can be negative, but you also have to be careful how Wireshark translates this to a number in the UI because it's two's complement and Wireshark doesn't always handle this correctly. To be sure, we would need to see the actual bytes representing the request ID. Would it be possible to add a screenshot of the bytes view of the packet with the request ID selected for both the get and the set? You can edit your question and add more images.
The problem Ben mentioned had to do with two's complement. We send a request with trailing zeros and the device removed the trailing zeros, or it added trailing zeros, so that the request ID doesn't match anymore and the element goes in timeout. It seems to be a similar problem here...
And when converting both decimal request IDs in your screenshot to hex, you both have ED801F. So, most probably the device is again adding or removing trailing zeros, which is not allowed since the request IDs no longer match when doing this. This would be a bug in the firmware of the device and there is unfortunately no workaround for this problem. You would need to contact the vendor...
DataMiner increments the request ID for each request, at a certain number those devices don't handle the ID correctly anymore. As far as I know, the only way to reset this number again, is to restart DataMiner and this has always been like this...
Hi Thomas,
As Ben mentioned this is a known issue. According to RFC1157, the request ID is defined as integer. A valid Request-ID value must be in the range -2^31 to 2^31. The SNMP agent running on the device should support negative request IDs.
I'm not an expert on this, and it seems to be unrelated (as it seems to be the opposite if I understand correctly), but in the past we experienced some problems with equipment from certain vendors that had an SNMP stack with a bug that caused their ID to go negative (which is not in line with the SNMP standard). I don't recall all the details, but just wanted to mention it here to make sure that this is not related. I believe we encountered this starting a long time ago with Tandberg products (and they fixed that problem, but I believe then it resurfaced again in new firmware release). Just in case this could be relevant information.