Issue in AgentX subagent on Big Endian architecture
Hi, We are using Net-SNMP version 5.4.2.1 in our product and we found one issue with AgentX communication in the following scenario AgentX Master agent on Little Endian architecture AgentX Subagent on Big Endian architecture In this setup we are facing an issue when subagent sends the AgentX Open-PDU then it can be seen from the capture that it is using big-endian encoding scheme and but the ByteOrder flag in the AgentX Open-PDU is not set. So while parsing the request received from the subagent the master agent is assuming little endian encoding, and hence causing the issue. === Logs of net-snmp when the issue happens === snmpd[13591]: netsnmp_tcp_recv(): snmpTCPDomain.c, 119: snmpd[13591]: netsnmp_tcp: snmpd[13591]: recv fd 27 got 80 bytes snmpd[13591]: dumpx_recv: snmpd[13591]: 00 00 00 3C snmpd[13591]: snmpd[13591]: dumpv_recv: snmpd[13591]: Integer:1006632960 (0x3C00) snmpd[13591]: trace: snmpd[13591]: _sess_read(): snmp_api.c, 5601: snmpd[13591]: sess_read: snmpd[13591]: loop packet_len 80, PDU length 1006632980 snmpd[13591]: trace: snmpd[13591]: _sess_read(): snmp_api.c, 5633: snmpd[13591]: sess_read: snmpd[13591]: pkt not complete (need 1006632980 got 80 so far) == The SNMP payload for Open request received from little endian node 0101e655b7503c0005040100881f030002000a0019004e65742d534e4d50204167656e7458207375622d6167656e7400 == The SNMP payload for Open request received from big endian node 01013b1c9924003c050400011f8800030002000a00194e65742d534e4d50204167656e7458207375622d6167656e7400 Regards Jyoti === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
SNMPv3 problem with kill -HUP on NetSNMP v5.6.1
Hello, I am trying to create a SNMPv3 user on a SNMP v5.6.1 agent. I am using the snmpusm utility to create the user, and seems successfully, that I can show it on: "snmpwalk -v2c -c public 127.0.0.1 snmpUsmMIB" Not until I do a total restart of the SNMP agent, I cannot query the SNMP variable by using the new create username. If I just do a "kill –HUP", I cannot use the newly created user credential to query the variable. Also, if there is any new snmpd.conf configuration change such as community string change, and do a "kill –HUP", I cannot do SNMPv3 query with the username. Does anybody know how to fix the problem ? The snmpusm command that I use is something like: /usr/bin/snmpusm -v3 -u initial -l authNoPriv -a SHA -A xyz1234567 localhost create new_user original_user /usr/bin/snmpusm -v3 -u new_user -l authNoPriv -a SHA -A xyz1234567 -Ca localhost passwd xyz1234567 1234567xyz Thanks -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: Sending and Receiving v3 traps
On 21 June 2012 13:35, wrote: > Just some quick follow up, I had the following in my snmpd.conf file, and at > first attempt, had to make them mutually exclusive. > Is it because I am using the same destination IP? I'm not quite sure what you mean by "the following" If you mean trap2sink 192.168.1.101 trapsess -r 0 -v 3 -u user -l authPriv -a MD5 -A password -x DES -X password 192.168.1.101 then that ought to work fine, It would mean that the machine 192.168.1.101 would receive two copies of every trap (which is clearly unnecessary), but there's nothing inherently forbidden about such a configuration. You shouldn't do it, because it's a bad idea. But that's different from not doing it because it's fundamentally wrong! > How does the agent know from the sendv2_trap API, which does not include any > destination ip info, as to send either via SNMP v2c or 3? The agent uses the settings in the snmpd.conf file to decide whether to use SNMPv1, SNMPv2 or SNMPv3 (as well as where to send it). send_v2trap simply means "please send this trap" - all the details are left to the agent. If there are no trapsink (or equivalent lines), then the trap won't actually be sent. If there are several such lines, then multiple copies will be send - using the version(s) and destination(s) specified in those configuration directives. But that is all the responsibility of the core agent code - the MIB module that requested the trap doesn't know or care about the details. > Longer term, I will need to manipulate the notify tables directlly (as an > SNMP client) to put in > what could be multiple destination ips for a single SNMP v3 trap. Do you > see this is being problematic > assuming that the config file contains the one trapsess statement? You can certainly set up MIB table entries dynamically to configure trap destinations on the fly. If you search the mailing list archives, you should find several explanations of this. Essentially you need to mimic the set of entries set up via a config line. What you can't do is set up a target using the snmpd,conf file, and then manipulate this via SNMP SET requests. Config directives set up "read-only" entries - which can't then be changed. Again - search the list archives for details of why this is the case. > I am required to send out SNMP v3 TRAPs not INFORMs, so it would seem engine > id coordination is required. Interesting that in my test application, SnmpB, > I did not have to specify an engine id, and all seemed to work fine. > > http://sourceforge.net/projects/snmpb/ You will need to talk to the SnmpB people about that. I have enough problems finding the time and energy to provide support for our own project - I really can't cope with providing assistance with someone else's software as well. (Particularly a system that I've never actually used!) A *very* quick look at the source seems to indicate that this is built on SNMP++, so it might be worth looking at the SNMP++ documentation as well. I seem to remember that this package relies on the engineID being explicitly configured - it didn't do engineID discovery. But it's a good few years since I looked at this in any detail, so things may well have changed. But talk to the SnmpB people, and/or consult SNMP++ documentation for more details. (In general, Frank has tended to be better than we are about documenting his system. But then this seems to be a semi-commercial setup, so probably has more resources, and definitely more incentive than we do!) Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: take 2 at installation
On 06/20/2012 02:45 PM, Dave Shield wrote: Anyone see a problem with any of this before I proceed? No - that looks fine. Try compiling, and see what happens Dave OK...I ran make, then "make test." Here's the output of the latter: Test Summary Report --- SNMPv3 snmptrapd USM user management with snmpusm (Wstat: 256 Tests: 12 Failed: 7) Failed tests: 5-11 Non-zero exit status: 1 SNMPv3 traps received and sent by tools (Wstat: 256 Tests: 4 Failed: 2) Failed tests: 2-3 Non-zero exit status: 1 SNMPv2c traps received and sent by tools (Wstat: 256 Tests: 2 Failed: 1) Failed test: 1 Non-zero exit status: 1 authentication failure traps are sent by snmpd (Wstat: 256 Tests: 2 Failed: 1) Failed test: 1 Non-zero exit status: 1 snmptrapd traphandle: launching external shell script (Wstat: 256 Tests: 3 Failed: 2) Failed tests: 1-2 Non-zero exit status: 1 com2secunix directive (Wstat: 256 Tests: 12 Failed: 1) Failed test: 11 Non-zero exit status: 1 AgentX trap sending support using agentxtrap (Wstat: 256 Tests: 2 Failed: 1) Failed test: 1 Non-zero exit status: 1 Files=66, Tests=219, 134 wallclock secs ( 0.23 usr 0.04 sys + 8.96 cusr 3.79 csys = 13.02 CPU) Result: FAIL We failed these 7 tests: SNMPv3 snmptrapd USM user management with snmpusm ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T035snmpv3trapdusermgmt_simple ) SNMPv3 traps received and sent by tools ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T050snmpv3trap_simple ) SNMPv2c traps received and sent by tools ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T051snmpv2ctrap_simple ) authentication failure traps are sent by snmpd ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T058agentauthtrap_simple ) snmptrapd traphandle: launching external shell script ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T059trapdtraphandle_simple ) com2secunix directive ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T072com2secunix_simple ) AgentX trap sending support using agentxtrap ( /home/mzimmers/Downloads/net-snmp-5.7.1/testing/fulltests/default/T114agentxagentxtrap_simple ) make[1]: *** [test] Error 1 make[1]: Leaving directory `/home/mzimmers/Downloads/net-snmp-5.7.1/testing' make: *** [test] Error 2 mzimmers@mzimmers-desktop:~/Downloads/net-snmp-5.7.1$ The common item in these errors seems to be the snmptrapd...is it possible that I somehow misconfigured my install to have messed this up? mz -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
RE: Received response for SNMPv3 inform; but Agent still sending inform for the number of retries configured.
From: skjaiswa...@hotmail.com To: net-snmp-cod...@lists.sourceforge.net; net-snmp-users@lists.sourceforge.net Subject: RE: Received response for SNMPv3 inform; but Agent still sending inform for the number of retries configured. Date: Thu, 21 Jun 2012 15:27:46 +0530 Hi Wes Thanks for quick reply Please clarify issues seen in 2 and 3. 2. Also sending report SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0 (See EngineIDErrorPkt.pcap). updated System time on Agent; still error received. 3. V3 Inform received by Trap Receiver; response sent to agent but agent is sending inform again (retry = 1; See Inform-Retry.pcap). Hi Dave I also attached trapdconfig(in zip file 7.z format) I’m using manage Engine MIB Browser for receiving Trap > From: harda...@users.sourceforge.net > To: skjaiswa...@hotmail.com > CC: net-snmp-cod...@lists.sourceforge.net; > net-snmp-users@lists.sourceforge.net > Subject: Re: Received response for SNMPv3 inform; but Agent still sending > inform for the number of retries configured. > Date: Wed, 20 Jun 2012 08:12:48 -0700 > > Suresh kumar writes: > > > 1. Engine ID discovered correctly during discovery; but Agent still > > incrementing usmStatsUnknownEngineIDs.0 (See EngineIDErrorPkt.pcap) > > 2. Also sending report > > SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0 (See > > EngineIDErrorPkt.pcap). updated System time on Agent; still error > > received. > > These are actually normal. In the process of engineID discovery (and > time discovery) the agent will receive a message with the wrong > engineID, so the agent increments the count and sends back the real one. > That's actually how engineID discovery works. > > -- > Wes Hardaker > Please mail all replies to net-snmp-cod...@lists.sourceforge.net -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: Sending and Receiving v3 traps
[ First - *please* don't mail me privately, without copying any responses to the mailing list. I don't have the time or inclination to offer private, unpaid, SNMP consultancy. Keep discussions to the list, where others can both learn and offer advice. Thanks. ] On 20 June 2012 20:45, Bob O'Neil wrote: > Hi Dave, thanks for the help as usual. > > I have this working now with the trapsess keyword. To do so, I had to > eliminate the trap2sink statement, which I guess makes sense since > the two behaviors need to be mutually exclusive. Is this correct? Not really. The various trapsink/trapinform/trapsess directives each define a location to which notifications should be sent. It's perfectly valid to have more than one trap destination (using either different or the same versions of SNMP). They're not mutually exclusive - they're independent. The one thing that I'd say *is* wrong, would be to have two or more trap destinations, all pointing to the same host trapsink localhost trap2sink localhost informsink localhost is Just Plain Wrong (and shows a complete misunderstanding of how this works). > I did not do anything special in terms of specifying an engine id for the > trap sender In my trapsess statement. If you're working with Inform notifications (-Ci), then this is fine. The agent will do the usual EngineID discovery, just as with client-side SNMPv3 requests, and everything Should Just Work. If you're working with Trap notifications, then this may or may not be a problem.Either you should set the trapsess engineID to match the trap receiver, or you should configure the trap receiver with information about the sender(s). (Or else configure both manually to use the same engineID) Bottom line - the two sides need to agree about which engineID to use. There's more about this in the on-line documentation. > A sample SNMP client (Snmpb) was able to properly receive and > decode the trap I sent from my subagent. Sounds good. > Are there any special considerations that an SNMP Manager > needs in terms of managing engine ids from client as part of > some discovery process, or it is part of the protocol itself? If you're working with Informs, then it's all taken care of (by the Net-SNMP code, at least). If you're working with Traps, then yes, there *are* special considerations. See above. Dave -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Net-snmp-users mailing list Net-snmp-users@lists.sourceforge.net Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
