Problem when querying HOST-RESOURCE-MIB items
Hi everyone, I'm trying net-snmp-5.2.1 on my RedHat-Linux 7.3 box, and currently having trouble when I retrieve HOST-RESOURCES-MIB items. I already tried the following steps: 1. Set bash env param MIBS=ALL 2. Specify --with-mibs=HOST-RESOURCES-MIB:SNMPv2-MIB:... during ./configure 3. Distributed my snmp.conf and snmp.local.conf (same files) in the following paths: /Home/root/.snmp/ /usr/local/lib/snmp/ /var/net-snmp/ ... as suggested by previous debug results Note that I also have the said MIB in my /usr/local/share/snmp/mibs/ as created by make install. My box is configured as such: ### # snmpd.conf # - created by the snmpconf configuration program ### syslocation Company Name, Inc. syscontact [EMAIL PROTECTED] rocommunity public rwcommunity [EMAIL PROTECTED] dodebugging 1 ### # snmp.conf # - created by the snmpconf configuration program ### defaultport 161 defversion 1 defcommunity [EMAIL PROTECTED] Having the above configs, and inspecting the generated /var/log/snmpd.log file, I notice that I have these entries: parse-mibs: Checking file: /usr/local/share/snmp/mibs/HOST-RESOURCES-TYPES.txt... trace: new_module(): parse.c, 4092: parse-mibs: Module 26 HOST-RESOURCES-TYPES is in /usr/local/share/snmp/mibs/HOST-RESOURCES-TYPES.txt trace: add_mibfile(): parse.c, 4625: From this, I take it that my HOST-RESOURCES-MIBs are indeed being loaded by snmpd. Now what else can I check/do in order to get/retrieve HOST-RESOURCES-MIB items Each time I do an `snmpwalk...`? I can post my lengthy snmpwalk results if anyone wishes to see it. Best regards, Vic -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.7.5/18 - Release Date: 6/15/2005 --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ 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: Re: UPDATE: Possible bug: NET-SNMP v5.1.2.pre2 crashes
Hi Robert, everyone, From: Robert Story (Users) [EMAIL PROTECTED] Re: UPDATE: Possible bug: NET-SNMP v5.1.2.pre2 crashes 2004-06-29 19:48 On Tue, 29 Jun 2004 17:16:33 +0800 Vic wrote: VB The command that sent net-snmp crashing is an attempt to write value to the VB ipRouteIfIndex.xxx.xxx.xxx.xxx quad-network object. Should net-snmp be VB able to safely reject/process such a request? Yes. Any crash is a bug. Can you run in a debugger and sent a stack trace? What OS? Sorry for this late reply. Anyways, I'm running net-snmp 5.1.2 from a Linux-2.4.18- based environment. I also tried using RH7.3, also 2.4.18, and the problem exists also. The bug is really not difficult to replicate. All the user should do is run a SET instruction on ipRouteMetric* and ipRouteIndex* objects. On my Linux system, such SET commands on said objects, always crash snmpd. This is also evident in the older 5.1.1 release. SilverCreek did such tests that initiated the crash. I tried doing it manually, and lo and behold... the daemon does crash :o(. Best regards, Vic --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.672 / Virus Database: 434 - Release Date: 4/28/2004 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
UPDATE: Possible bug: NET-SNMP v5.1.2.pre2 crashes
Hi, The command that sent net-snmp crashing is an attempt to write value to the ipRouteIfIndex.xxx.xxx.xxx.xxx quad-network object. Should net-snmp be able to safely reject/process such a request? Best regards, Vic --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.672 / Virus Database: 434 - Release Date: 4/28/2004 --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Possible bug: NET-SNMP v5.1.2.pre2 crashes
Hi,
I've been testing the v2c implementation of this current release
using SilverCreek. In order to test full R/W access from a remote
machine, I had my public group set to R/W also.
On one of SilverCreek's tests, entitled: SET read-write objects,
it seems that NET-SNMP failed to handle SET instructions involving
erroneous data.
What happened is that snmpd crashed when SilverCreek tried to SET
(perhaps, invalid) values into the server. Here are test log details
of what SilverCreek is doing when the crash occurred. Included also
is the generated /var/log/snmpd.log.
--
sysDescr: Test Machine [192.168.63.119:SNMPv2c]
2.4.x The purpose of these tests is to verify that the agent
returns the correct error-status when the test intentionally
writes variables. The tests are run on each of the read-write
variables returned in 2.1.2.1.
2.4.1 This test issues SET using the current value of the variable.
The expected outcome is for the agent to return noError.
(Note: some objects with peculiar semantics, e.g. tcpConnState,
will return wrongValue instead of noError).
Reference RFC 1905 ยง 4.2.5
Details for Test 2.4.1
[FAILED] Remarks: SET on 1.3.6.1.2.1.2.2.1.7.1 ifAdminStatus
[FAILED] Remarks: SET on 1.3.6.1.2.1.2.2.1.7.1 ifAdminStatus
Received Message Data {
Error-Status: notWritable,
Error-Index : 1,
Bindings {
ifAdminStatus.1,
INTEGER,
1
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.2.2.1.7.2 ifAdminStatus
Received Message Data {
Error-Status: notWritable,
Error-Index : 1,
Bindings {
ifAdminStatus.2,
INTEGER,
1
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.3.1.1.2.2.1.192.168.63.105
atPhysAddress
Received Message Data {
Error-Status: notWritable,
Error-Index : 1,
Bindings {
atPhysAddress.2.1.192.168.63.105,
OctetString,
0x08:00:46:0e:21:82
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.4.1.0 ipForwarding
Received Message Data {
Error-Status: notWritable,
Error-Index : 1,
Bindings {
ipForwarding.0,
INTEGER,
2
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.4.2.0 ipDefaultTTL
Received Message Data {
Error-Status: notWritable,
Error-Index : 1,
Bindings {
ipDefaultTTL.0,
INTEGER,
64
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.4.21.1.2.127.0.0.0 ipRouteIfIndex
Received Message Data {
Error-Status: resourceUnavailable,
Error-Index : 1,
Bindings {
ipRouteIfIndex.127.0.0.0,
INTEGER,
2
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.4.21.1.2.192.168.63.0 ipRouteIfIndex
Received Message Data {
Error-Status: resourceUnavailable,
Error-Index : 1,
Bindings {
ipRouteIfIndex.192.168.63.0,
INTEGER,
2
}
}
[FAILED] Remarks: SET on 1.3.6.1.2.1.4.21.1.3.0.0.0.0 ipRouteMetric1
Received Message Data {
Error-Status: wrongValue,
Error-Index : 1,
Bindings {
ipRouteMetric1.0.0.0.0,
INTEGER,
1
}
}
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[FAILED] Remarks: SET on 1.3.6.1.2.1.4.21.1.3.127.0.0.0 ipRouteMetric1
Received Message Data {
Error-Status: timeout,
}
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
[ERROR] Remarks: An unexpected error occurred
ECONNRESET
TclSNMPContext::Eval()
RecvMessage()
--
/var/log/snmpd.log
--
NET-SNMP version 5.1.2.pre2
not string
not string
not string
not right2not right2not right2not int1not int1not int1not right4not
RE: MAC address not retrieved by Win32 client
Hi David, everyone, -Original Message- From: Dave Shield [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 4:52 PM To: Vic Berdin Cc: [EMAIL PROTECTED] Subject: Re: MAC address not retrieved by Win32 client However, I noticed that MAC (physical) addresses (OID .1.3.6.1.2.1.2.2.1.6.2, etc) were NOT retrieved by the tool. It would be a lot easier to advise you as to the cause of this problem if you'd included some indication as to what you'd actually tried. It might be that you're asking for the wrong OIDs (as David suggests). Or it may be a problem with the agent configuration. Have you read the FAQ? Yep I did, prior to posting. In particular, see the entry: I can see the system group, but nothing else. Why? Here are more details: If I will run `snmpwalk` from my Linux machine, I can definitely see the line: RFC1213-MIB::ifPhysAddress.2 = Hex-STRING: 00 90 73 00 02 F5 as one of the results to my snmpwalk command. Then if I will use `snmptranslate -On RFC1213-MIB::ifPhysAddress.2`, the output is indeed: .1.3.6.1.2.1.2.2.1.6.2. The same OID that comes out NULL from snmputilg.exe tool, but the value is NULL. It's also highly possible that snmputilg does not support physical addresses (*shrugs*). Btw, what other FREE Win32 client tools that you guys use, in order to get/set information to your net-snmp servers? Also, here's my test conf, please feel free to send flames: #- # sec.name source community com2sec local 172.0.0.1 public com2sec mynetwork 0.0.0.0/0 public # Second, map the security names into group names: # sec.model sec.name group MyRWGroup v1 local group MyRWGroup v2clocal group MyRWGroup usmlocal group MyROGroup v1 mynetwork group MyROGroup v2cmynetwork group MyROGroup usmmynetwork # Third, create a view for us to let the groups have rights to: # incl/excl subtree mask view allincluded .1 80 # Finally, grant the 2 groups access to the 1 view with different # write permissions: #context sec.model sec.level match read write notif access MyROGroup any noauthexact allnone none access MyRWGroup any noauthexact allallnone ### # System contact information # syslocation In My Place syscontact zxiv1001 [EMAIL PROTECTED] sysdescr My Machine sysname Machine Sys ### # Define trap destinations # # trapsink: A SNMPv1 trap receiver # arguments: host [community] [portnum] trapsink 127.0.0.1 # trap2sink: A SNMPv2c trap receiver # arguments: host [community] [portnum] trap2sink 127.0.0.1 # informsink: A SNMPv2c inform (acknowledged trap) receiver # arguments: host [community] [portnum] informsink 127.0.0.1 # trapsess: A generic trap receiver defined using snmpcmd style arguments. # Read the snmpcmd manual page for further information. # arguments: [snmpcmdargs] host #trapsess 127.0.0.1 #-- --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.672 / Virus Database: 434 - Release Date: 4/28/2004 --- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
RE: MAC address not retrieved by Win32 client
Hi Dave, Alex, everyone, -Original Message- From: Dave Shield [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 7:00 PM To: Vic Berdin Cc: [EMAIL PROTECTED] Subject: Re: MAC address not retrieved by Win32 client Here are more details: If I will run `snmpwalk` from my Linux machine, I can definitely see the line: RFC1213-MIB::ifPhysAddress.2 = Hex-STRING: 00 90 73 00 02 F5 Is that the same box as the agent is running on, or a different one? It's worth checking you can see things from a remote system, as well as the local one. VIC: It's the same box. I've just tried your suggestion, and my other Linux machine (vmware actually) was able to get the physical address. And incidentally, after reading another response from Alex, I tried the Win32 based net-snmp, and yep, snmpwalk from this net-snmp flavor can also retrieve physical address values. It's also highly possible that snmputilg does not support physical addresses (*shrugs*). Seems unlikely, to be honest. Such tools typically work with raw OIDs, and don't care about what the values actually mean. Btw, what other FREE Win32 client tools that you guys use, in order to get/set information to your net-snmp servers? Well personally, I tend to use the Net-SNMP client applications on all systems, including windows boxes. (Not that I use windows kit much). But I'd be fairly surprised if this made a difference. It's much more likely to be an access control problem. Also, here's my test conf, please feel free to send flames: #- # sec.name source community com2sec local 172.0.0.1 public com2sec mynetwork 0.0.0.0/0 public Is that a typo for 127.0.0.1 ? Otherwise the access control stuff looks OK. VIC: It is a typo on my actual config. I already changed it, but the problem remains (I'd have used default rather than 0.0.0.0/0 but it probably works the same). You don't need all three of the following: trapsink 127.0.0.1 trap2sink 127.0.0.1 informsink 127.0.0.1 since that will generate *three* copies of every trap you send, but that's not relevant to this problem. VIC: So that's what it means! I've made a script just to see if my trap daemon can indeed detect coldStart. The script simply echoes to a file. And to my amazement, three entries are always gets created. Thanks for this one! BTW, how do you actually test warmStart, linkUp, and linkDown? Another thought - are you *sure* that this is the snmpd.conf file that's being read. If you're running a pre-installed version of the agent, then that will typically be looking in somewhere like /etc/snmp/snmpd.conf rather than /usr/local/etc/snmp/snmpd.conf VIC: This is indeed the active config. I have this on my rc start-up script: -c /usr/local/share/snmp/snmp.conf ...and this as my trapd option: -f -Le -c /usr/local/share/snmp/snmptrapd.conf Try deliberately putting an invalid token into the config file and restarting the agent. It should log an error. VIC: No need. I've had obvious errors on this config before. And the error does get logged in /var/log/messages. At present, my messages log is free from snmpd errors. VIC: I really have no more ideas at this point on how to resolve this. Since another Linux machine and the Win32 net-snmp can retrieve the MAC values from the server, I'm bent on believing that snmputilg.exe has problems... However: I also would like to inform the list that SilverCreek spurs out a lot of TimeOut errors from this server and config. Out of 79 tests for v2c, I get: - 52 passed tests, 23 failures, 3 warnings, and 1 uninnitiated test due to dependencies on previous failed tests. - For v1, almost half of the test failed (22 failures 3 warings out of 51 tests). - I haven't started testing v3 yet. Can this be interpreted that net-snmp has its own means of getting things done? Or isn't really/fully RFC compliant? :o( To those who may be interested, I can give you a zipped copy of the errors I'm getting. But for starters, here's a snip of one of my saved logs: I really wonder what does this error on Index value mean. I'm getting lines and lines of these errors/warnings, along with write problems eventhough `snmpset` works fine from a Linux client. --- [WARNING] Remarks: Possible problems in set-request operation Agent returned out of range error-index value The error-index value in a Reponse-PDU with an error-status of notWritable must be between 1 and the number of varbinds in the request. Instead, an error-index of 0 was received, which does not correspond to any of the 2
