lextudio-support commented 3 hours ago

I tried snmpget with my device (Cisco SF 300), but without success. I used the following command: snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -A=800000090340f4ecf2b113 -u=billing -X=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 (I tried to get state of 3 interface). Every time I run this command I got different replay, for example: Variable: Id: .1.3.6.1.6.3.15.1.1.5.0; Data: 7 Data were changing incrementally. OID is different then I entered in command. I also tried version bigdipper 7 and using the same command receive exception: snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -A=800000090340f4ecf2b113 -u=billing -X=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Lextm.SharpSnmpLib.SnmpException: invalid v3 packet data hash detected at Lextm.SharpSnmpLib.Messaging.MessageFactory.ParseMessage(Int32 first, Stream stream, UserRegistry registry) in d:\sharpsnmpl ib\SharpSnmpLib\Messaging\MessageFactory.cs:line 190 at Lextm.SharpSnmpLib.Messaging.MessageFactory.ParseMessages(Byte[] buffer, Int32 index, Int32 length, UserRegistry registry) i n d:\sharpsnmplib\SharpSnmpLib\Messaging\MessageFactory.cs:line 108 at Lextm.SharpSnmpLib.Messaging.SnmpMessageExtension.GetResponse(ISnmpMessage request, Int32 timeout, IPEndPoint receiver, User Registry registry, Socket udpSocket) in d:\sharpsnmplib\SharpSnmpLib\Messaging\SnmpMessageExtension.cs:line 428 at Lextm.SharpSnmpLib.Messaging.SnmpMessageExtension.GetResponse(ISnmpMessage request, Int32 timeout, IPEndPoint receiver, Sock et udpSocket) in d:\sharpsnmplib\SharpSnmpLib\Messaging\SnmpMessageExtension.cs:line 351 at Lextm.SharpSnmpLib.Messaging.SnmpMessageExtension.GetResponse(ISnmpMessage request, Int32 timeout, IPEndPoint receiver) in d :\sharpsnmplib\SharpSnmpLib\Messaging\SnmpMessageExtension.cs:line 309 at SnmpGet.Program.Main(String[] args) in d:\sharpsnmplib\Samples\C#\snmpget\Program.cs:line 183

May be I doing something wrong?

Original Reported Date: 2012-10-18T23:27:09.657-07:00 Planned For Release:

Original CodePlex ID: 7243

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

May I know what is the version of SharpSnmpLib.dll you are using? If possible, please provide network packet capture, as stated in http://sharpsnmplib.codeplex.com/wikipage?title=600008&referringTitle=KB

Original Posted Date: 2012-10-19T20:44:01.813-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I've used the latest version when I got strange result with incremented Data. (MD5 hash: eb72868eee6bd2f0cf5dcccc17a8ddcc *bigdipper_7.5_bin.zip). I also compiled sources and tried them but with same sad result. The browser return the same results with incremented data too. I also tried binaries (snmpget) from previous version (7.0) and got exception (see first post). My system: Windows 7 Ultimate x86, 4 Gb RAM, CPU: dual core. .Net 2.0-4.0 installed. I will try to obtain network packet capture on monday. And yes, I've tried another version of snmpget from http://www.elifulkerson.com/articles/net-snmp-windows-binary-unofficial.php And it works good with snmp3 and the similar command.

Original Posted Date: 2012-10-20T08:08:22.247-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

In attached files see network packet capture and test description. Hope this helps.

Original Posted Date: 2012-10-22T00:19:14.06-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

Please recapture. The current captures do not contain requests sent from the manager side, so it is almost useless.

The reason .1.3.6.1.6.3.15.1.1.5.0 is returned is because this SNMP agent thinks #SNMP sends an invalid digest (this OID is called usmStatsWrongDigests).

Except providing new captures with more packets, is it possible that you provide more information about this SNMP agent?

Original Posted Date: 2012-10-22T06:55:22.213-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

Thank you for your quick replies. Unfortunately, I am unable to capture packets with outgoing snmp requests. I don't know why. I tried another network interface on computer, disabled windows firewall, ran Wireshark with administrative privileges after computer restart, but with the same result. I also tried to setup date and time correctly on the device. The same result. May be you have some new suggestions how to solve this problem. Below is information about my device and Wireshark version. Also I've tried another device (Linksys SRW224G4) with the same results. Cisco SF 300-24 24-Port 10/100 Managed Switch System Object ID: 1.3.6.1.4.1.9.6.1.82.24.1 PID VID: SRW224G4-K9 V01 Firmware Version (Active Image): 1.0.0.27 Firmware MD5 Checksum (Active Image): 1987292110f5657e74308dde30c03dc4 Firmware Version (Non-active): 1.0.0.27 Firmware MD5 Checksum (Non-active): 1987292110f5657e74308dde30c03dc4 Boot Version: 1.0.0.4 Boot MD5 Checksum: 4c9a0b6a9f1346736646d08ab94ae2ac Locale: en-US Language version: 1.0.0.27 Language MD5 Checksum: N/A

Wireshark: Version 1.8.3 (SVN Rev 45256 from /trunk-1.8) Copyright 1998-2012 Gerald Combs gerald@wireshark.org and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled (32-bit) with GTK+ 2.24.10, with Cairo 1.10.2, with Pango 1.30.0, with GLib 2.32.2, with WinPcap (4_1_2), with libz 1.2.5, without POSIX capabilities, with SMI 0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Oct 2 2012), with AirPcap.

Running on 32-bit Windows 7 Service Pack 1, build 7601, with WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap. Built using Microsoft Visual C++ 10.0 build 40219

Original Posted Date: 2012-10-23T00:33:46.84-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I just tried Microsoft Network Monitor 3.4. It's seems that threre are outgoing requests too. See captures in attached "MNMCaptures.zip": dump1.cap - obtained using your version of netsnmp dumpOK.cap - net-snmp version

Original Posted Date: 2012-10-23T01:51:07.86-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

Well, LOL at last.

This is a false alarm, as your command line for #SNMP snmpget was wrong. The one you use is

snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -A=800000090340f4ecf2b113 -u=billing -X=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3

However, it should be

snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3

SNMP's snmpget does not yet support -e switch.

Original Posted Date: 2012-10-23T06:15:43.383-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I've retested my two devices with new commands, below are results. I've executed command 3 times on every device. I used: username - billing, password - testing345

LinkSys SRW224G4 (IP: 192.168.209.3)

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.3 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 13

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.3 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 14

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.3 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 15

Cisco SF 300-24 (IP: 192.168.209.4)

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 4

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 5

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 6

I see that the problem still persists.

Original Posted Date: 2012-10-23T07:14:26.463-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

Just reviewed your latest comment and found that the new OID in fact is usmStatsNotInTimeWindows, which you can find further explanation in http://www.ietf.org/rfc/rfc2274.txt. This error is not caused by missing -e as I previously commented, but is caused by latency on the wire probably.

If possible, you might capture some more packets and we can see if that can give us more insights.

Original Posted Date: 2012-10-23T20:31:22.247-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

In attached "MNMCaptures2.zip" see new capture and system time settings on my device. I configured date and time on device, but the problem still here. Also I've already mentioned in my second post, that the browser application also return the error result. So, I think, this is not a problem of only snmpget itself. See example output of browser: [192.168.209.4:161] [24.10.2012 09:57:01] ==== Begin GET ==== [192.168.209.4:161] [24.10.2012 09:57:02] Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 21 [192.168.209.4:161] [24.10.2012 09:57:02] ==== End GET ====

d:\New\SNMP\bigdipper_7.5_bin>snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Variable: Id: .1.3.6.1.6.3.15.1.1.2.0; Data: 18

Hope, this helps you to detect the problem.

Original Posted Date: 2012-10-23T23:59:16.927-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I also tried net-snmp snmpget without indicating engineID with success: snmpget -c public -v 3 -a MD5 -l authNoPriv -u billing -A testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 ... IF-MIB::ifAdminStatus.3 = INTEGER: down(2)

I've noticed that this program (and iReasoning MIB browser, trial version works with snmp v3) increments error counter (.1.3.6.1.6.3.15.1.1.2.0) but returns correct result! May be it's due to discovery process as it is described in RFC3414 (http://tools.ietf.org/html/rfc3414#page-31) Do your library support discovery process?

Original Posted Date: 2012-10-31T01:33:49.64-07:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I am not familiar with Cisco SF 300. From the captures I can see the following details,

In dumpOK.cap, the time difference between the two SNMP requests is only 4.8-ms.
In dump1.cap, the time difference is 72.3-ms.

If the time window for SNMP v3 discovery of this device is set to a very small value (less than 70-ms), then the problem you described can be reasonably explained.

Is it possible that you follow the user manual of this Cisco device and see what is the value of discovery time window? Knowing that setting is critical right now to identify the root cause.

Original Posted Date: 2012-11-06T05:26:55.157-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I can't discover what is exact value of time window size on my device. But as RFC3414 says (and here too: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-3/snmpv3.html) time window size is about 100-150 seconds (not milliseconds). So it's big enough for snmp requests to succeed. net-snmp version of snmpget and iReasoning MIB browser works fine even when device have wrong date and time settings (after reboot). See also the link (http://www.webnms.com/cagent/help/troubleshoot/c_troubleshoot_snmp.html#v3): "How to correct it(usmStatsNotInTimeWindows): The subsequent queries will be success, since the "Not In Time Window" error response has both the latest EngineTime and EngineBootCnt of agent." So I think that it is a question of negotiation between agent and manager. Manager should treat this error properly and resend new request with correct values of snmpEngineBoots and snmpEngineTime. I perform debug of snmget using your sources and noticed that after command "ReportMessage report = discovery.GetResponse(timeout, receiver);" report.Parameters have EngineBoots and EngineTime equal to 0 (and this in incorrect). I put breakpoint in MessageFactory.cs (line 156) "parameters = new SecurityParameters((OctetString)body[2]);" and noticed that line was called twice, but only after second time EngineBoots and EngineTime were not zero and contain correct values. It seems that first call (discovery) returns not valid values or may be they filled incorrectly. And these invalid values are sent within main request, so it returns with error usmStatsNotInTimeWindows. So the problem is in incorrect discovery results before main (second) request.

Original Posted Date: 2012-11-07T04:05:08.947-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I read RFC3414 chapter 4 (Discovery) more carefully. The discovery in my case must have two phases. First - to obtain engineID. Second - using this engineID to obtain snmpEngineBoots and snmpEngineTime (as a part of time synchronization). As I understand, you have not implemented the second part of discovery process. Am I right?

Original Posted Date: 2012-11-07T06:20:51.317-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

What can you say about this code fragment (I've modified snmpget example code and it returns correct result): Discovery discovery = Messenger.NextDiscovery; ReportMessage report = discovery.GetResponse(timeout, receiver); // we have now engineID // Obtain engineBoots, engineTime: GetRequestMessage request = new GetRequestMessage(VersionCode.V3, Messenger.NextMessageId, Messenger.NextRequestId, new OctetString(user), new List(), priv, Messenger.MaxMessageSize, report); ISnmpMessage response = request.GetResponse(timeout, receiver); // Save data, I've open this props in SecurityParameters: report.Parameters.EngineBoots = response.Parameters.EngineBoots; report.Parameters.EngineTime = response.Parameters.EngineTime;

            // now perform final managed request:
            request = new GetRequestMessage(VersionCode.V3, Messenger.NextMessageId, Messenger.NextRequestId, 
                new OctetString(user), vList, priv, Messenger.MaxMessageSize, report);
            response = request.GetResponse(timeout, receiver);

Original Posted Date: 2012-11-15T05:41:34.067-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

The very first time when you call,

// Obtain engineBoots, engineTime: GetRequestMessage request = new GetRequestMessage(VersionCode.V3, Messenger.NextMessageId, Messenger.NextRequestId, new OctetString(user), new List(), priv, Messenger.MaxMessageSize, report);

The engineBoots and engineTime are set in GetRequestMessage (take a look at the constructor you call and you know it). So as I stated it is just a timing issue.

SNMP follows the RFC documents already, and I think your changes happen to work just because it falls into the configured time window on the second attempt. Capture some packets and see if the hint is there.

Original Posted Date: 2012-11-15T22:36:22.35-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I understand your point of view. The problem is the following: report variable (filled in line: "ReportMessage report = discovery.GetResponse(timeout, receiver);") does not contained valid values for EngineBoots and EngineTime! Only EngineID is filled. See attached screenshot "Greenshot_2012-11-16_14-12-44.png". Is this an expected behavour? I still think that error usmStatsNotInTimeWindows is caused by incorrect values of these two variables, not by latency (my device connected to computer directly). According to RFC it is expected error when one indicates wrong EngineTime in managed request.

Original Posted Date: 2012-11-16T04:31:41.203-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

A further check on MNMCaptures.zip shows that this agent refused to reply with correct EngineBoots and EngineTime in dump1.cap in the very first reply.

This is completely different from dumpOK.cap, where the first reply contains that information.

So the original question on why dump1.cap failed can be answered by "the agent needs the request to contain something, such as an engine ID and others". I need some time to fully compare the very first requests in the two cases.

If #SNMP can make exact the same request in the first attempt, that agent might authenticate it as expected.

I recommend we ignore the later cases described so as to focus on this small scope.

Original Posted Date: 2012-11-18T22:31:12.44-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

For your information. I perfomed new fresh tests and saved dumps in "MNMCaptures3.zip" (I used Microsoft Network Monitor to capture packets and WireShark to see its structure) Results:

SNMP4j - OK Actions: uses 3 requests: 1 - sends empty msgAuthoritativeEngineID, receives correct value from agent (in my case - 80:00:00:09:03:40:f4:ec:f2:b1:13) 2 - sends correct msgAuthoritativeEngineID, receives correct values for msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime. 3 - sends managed request, receives correct response.

Net-snmp - OK (I not indicated EngineID this time!) snmpget -c public -v 3 -a MD5 -l authNoPriv -u billing -A testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Actions: the same as for SNMP4j

SharpSNMP - FAILED snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 Actions: the second step is missing (msgAuthoritativeEngineBoots, msgAuthoritativeEngineTime not obtained from agent) Managed request returns predictable error (notInTimeWindow).

As I understand, first two programs succeds because they perform discovery according to rfc3414 p.4.

Original Posted Date: 2012-11-19T23:47:53.61-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

Thanks for the new captures. It is now clear that this SNMP agent of Cisco requires two requests in discovery phase (which follows the example shown in http://tools.ietf.org/html/rfc3414#section-4).

However, the SNMP agents used in #SNMP development (NET-SNMP and snmp4j agents) always performs snmpEngineID learning and time synchronization by returning all such information in a single REPORT message, in which case only one request is required in discovery phase.

I think only a few lines of changes need to be changed in snmpget to support this Cisco agent. Will investigate on that once I have time.

Your workaround performs a similar attempt as it indeed sends two requests in discovery phase, which receives correct time information from the agent. Thus, you can temporarily use it. The only drawback is that the second message contains too many data, which can be reduced.

Original Posted Date: 2012-11-21T06:19:28.92-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

Just published a new build,

https://github.com/lextm/sharpsnmplib/tree/29bd79a367b12ca5d347de2825cd74d5d9ac6257

Can you test whether this version of snmpget has the issue fixed?

Original Posted Date: 2012-12-15T05:02:56.93-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

I've performed test of snmpget and got "unknown error" message. After debugging I made some corrections in Program.cs (see below) and obtained correct result.

/ var id = reply.Pdu().Variables[0].Id; if (id != Messenger.NotInTimeWindow) { var error = id.GetErrorMessage(); Console.WriteLine(error); return; } /

// according to RFC 3414, send a second request to sync time. request = new GetRequestMessage(VersionCode.V3, Messenger.NextMessageId, Messenger.NextRequestId, new OctetString(user), vList, priv, Messenger.MaxMessageSize, reply); reply = request.GetResponse(timeout, receiver); var id = reply.Pdu().Variables[0].Id; if (id == Messenger.NotInTimeWindow) // Equality! { var error = id.GetErrorMessage(); Console.WriteLine(error); return; }

Original Posted Date: 2012-12-17T05:31:40.203-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

If on your side the problem remains, hope you can share a new packet capture.

I didn't know why you have to make the changes. So I went ahead and modified #SNMP's snmpd to work in the RFC 3414 mode in this build,

https://github.com/lextm/sharpsnmplib/tree/48ddec0bf56d6ecbcf856716d2e12e05801cd714

In my case, the #SNMP snmpget command line tool can successfully pass discovery and receive correct result, with no further modification required.

Original Posted Date: 2012-12-19T06:04:54.937-08:00

lextudio-support commented 3 hours ago

Copied from CodePlex without authors:

See new dumps in file 2012-12-20.zip Command: snmpget -c=public -v=3 -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7.3 My IP: 192.168.209.2 Device IP: 192.168.209.4

V7.5.pcapng - dump using original version of snmpget and library. newVersionWitherr.pcapng - new version (got "unknown error" message). correctedVersion.pcapng - new version with my correction (command executed successfully).

Original Posted Date: 2012-12-19T23:54:52.25-08:00

lextudio-support commented 2 hours ago

Copied from CodePlex without authors:

Thanks for the new captures. It is something wrong in recent changes of Messenger.cs and I have just fixed.

Can you test out this build?

https://github.com/lextm/sharpsnmplib/tree/9398103b65abe50d4f040d9327f2baf6e6100408

If the issue is resolved, I am going to start shipping it as 7.6 release.

Original Posted Date: 2012-12-21T04:48:32.143-08:00

lextudio-support commented 2 hours ago

Copied from CodePlex without authors:

With snmpget everything seems to be OK. I also performed quick tests of snmpset, snmpbulkget, snmpwalk. Command below returns correct result (snmp v2): snmpwalk -c=public -v=2 -m=subtree 192.168.209.4 1.3.6.1.2.1.2.2.1.7

Command below returns no output (snmp v3), is it OK? snmpwalk -c=public -v=3 -m=subtree -a=MD5 -l=authNoPriv -u=billing -A=testing345 192.168.209.4 1.3.6.1.2.1.2.2.1.7

See dump for last command in file snmpwalkv3NotOk.pcapng.

Original Posted Date: 2012-12-21T06:59:29.703-08:00

lextudio-support commented 2 hours ago

Copied from CodePlex without authors:

Just fixed the remaining issue in Messenger.cs,

https://github.com/lextm/sharpsnmplib/tree/989a7c22ec838139516137552ee007e49e23a4fe

The code is still bit of ugly. Will see if later can use the session concept to simplify the code base.

Original Posted Date: 2012-12-28T05:11:03.433-08:00

lextudio-support commented 2 hours ago

Original Closed Date: 2013-04-06T23:38:46.237-07:00

lextudio / sharpsnmplib

SNMP v3 discovery bug #213

SNMP's snmpget does not yet support -e switch.

SNMP follows the RFC documents already, and I think your changes happen to work just because it falls into the configured time window on the second attempt. Capture some packets and see if the hint is there.