Hi,
After updating to 5.x i got problems with snmp request to pppoe sessions.
My programm checks the session OIDs if a client is connected or not. (I’m using the SharpSnmpLib for my program)
The snmp packets seems to corrupted, but this only happens in 50%. In the other cases it works fine.
The problems came with the upgrade from 4.x to 5.x
It occurs with 5.14, 5.17, 5.18 and 5.21
I found some threads related to this topic but none of them could help me, now i hope you can.
Thanks in advance
Simon
edit: ok, i analyzed the snmp pakets with wireshark. Every paket that seemed to be corrupted got one byre too muvh between the GetRequest command and the requestID. In a normal paket getrequest was displayed with 02 04 in the “corrupted” ones it was displayed with 02 05 ff . Due to the one byte more the paket could not be resolved.
Is this a bug?
Hey, thanks for your reply.
The problem comes from snmp-walk ^^
I resolved the problem to the request-id
The problem occurs if the request id is too big, for example:
“52 ed 5d 40”(hex) as id works fine
but “91 56 78 6b” occurs as a problem, because:
91(hex) = 1001 0001
First bit = 1, this results in making the os think that this is a negativ integer.
And for no reason it now answers the request with a new request id: “ff 91 57 78 6b”, containing 40bits
But snmp standards says it has to be a 32bit integer, so my client can not resolve it, due to the one byte more that is now in the package.
It worked fine with version 4.x have you changed integer de/encodings??
Our client tells us that there is a problem with integer decoding.
And of course we get no snmp error, because reading out the snmp error needs the packet to be resolved and as i said before this is not possible.
It would be great if you could tell your programmer who wrote the snmp agent what i wrote at Jan.09 5:24pm. This is the exact definition of the problem!
snmp v1 requestID is INTEGER(1 - 2147483647) and if you are sending bigger number which will make it negative you are violating RFC.
snmp v2 requestID is Integer32 (-2147483648 - 2147483647) is encoded using BER encoding in two’s complement form and in case of negative number it has to be prepended with ff which is stripped off while decoding.
Hey, thanks.
I still have no idea where to find the part which says it should add ff.
RFC says you use ASN.1, which says:
10.4.6 A minimum octet 2’s-complement-binary-integer encoding of the whole number has a field-width that is a
multiple of eight bits and also satisfies the condition that the leading nine bits of the field shall not all be zero and shall
not all be ones.
If you add FF to a negativ integer, the first nine bits are all ones. Which would violate this, so i guess you use another standard.
I really can’t find the ff part
Are there more exceptions that i have to handle except the one with the FF for negativ integers?
I should really check for further deviations between my client and your agents de/encodings, before getting into the clients source code.
