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?

Is the Problem already fixed?

Please make sure problem is not related to your SNMP program.
Run snmpwalk from any unix (linux, etc.) machine. Do you get any output?

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??

Thanks
Simon

Please post here exact command (commands), that are not working properly at v5.22

Hi,

We encountered that problem with the "get-next-request" snmp command.

Tell me if you want to see the WireShark Capturefiles.

mfg
Simon

Please post here exact command (commands), that are not working properly at v5.22

that include also errors you got with snmpwalk.

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!

up!

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 for your reply as it seems i have to change the source code of the snmp-client that I'm using, for fixing that "bug" on the client side.

But i'm a little bit confused because of 2 things:

1. I thought the integer-encoding is going with the X.690 standards? (Which you would violate)

2. Why did this problem never occur with the 4.x versions?

I would be thankful for a link, to the standards you are using. This would be a great help for changing the client.


mfg Simon

MikroTik SNMP is developed accordingly to RFC,
Standards: RFC 1157 RFC 3414 RFC 3416
http://wiki.mikrotik.com/wiki/SNMP

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.

mfg Simon