Community discussions

MUM Europe 2020
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

SNMP problems with 5.x

Mon Oct 15, 2012 5:07 pm

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?
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Tue Oct 23, 2012 4:41 pm

Is the Problem already fixed?
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6618
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: SNMP problems with 5.x

Wed Jan 09, 2013 3:36 pm

Please make sure problem is not related to your SNMP program.
Run snmpwalk from any unix (linux, etc.) machine. Do you get any output?
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Wed Jan 09, 2013 5:24 pm

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
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6618
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: SNMP problems with 5.x

Thu Jan 10, 2013 4:05 pm

Please post here exact command (commands), that are not working properly at v5.22
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Thu Jan 10, 2013 8:40 pm

Hi,

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

Tell me if you want to see the WireShark Capturefiles.

mfg
Simon
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6618
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: SNMP problems with 5.x

Fri Jan 11, 2013 10:34 am

Please post here exact command (commands), that are not working properly at v5.22
that include also errors you got with snmpwalk.
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Fri Jan 11, 2013 1:16 pm

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!
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Wed Jan 16, 2013 5:59 pm

up!
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6618
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: SNMP problems with 5.x

Thu Jan 17, 2013 11:47 am

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.
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Thu Jan 17, 2013 1:43 pm

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
 
User avatar
sergejs
MikroTik Support
MikroTik Support
Posts: 6618
Joined: Thu Mar 31, 2005 3:33 pm
Location: Riga, Latvia
Contact:

Re: SNMP problems with 5.x

Thu Jan 17, 2013 2:16 pm

MikroTik SNMP is developed accordingly to RFC,
Standards: RFC 1157 RFC 3414 RFC 3416
http://wiki.mikrotik.com/wiki/SNMP
 
AdunSG
just joined
Topic Author
Posts: 10
Joined: Mon Oct 15, 2012 4:21 pm

Re: SNMP problems with 5.x

Mon Jan 21, 2013 4:45 pm

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

Who is online

Users browsing this forum: No registered users and 68 guests