Bug 152448
| Summary: | snmpd.conf hostname vs. IP inconsistancy | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Chris Stankaitis <cstankaitis> |
| Component: | net-snmp | Assignee: | Radek Vokál <rvokal> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | tao |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHSA-2005-373 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-09-28 14:25:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 156320 | ||
I didn't manage to reproduce this issue. On a few machines I'm working with the both cases work fine. It seems that this works even with hostname or IP adress in snmpd.conf, obviously on the machine which doesn't have DNS configured this was working only with IP adress (as I understand, not your case 'cos nslookup is working). There has to be sth specific in "some" of the boxes which are not respording to snmpwalk with hostname... where should we start, what info can I provide to help us track down this issue? This might help to track this issue, please attach - your /etc/resolv.conf (is this same on all machines?) - your "hosts" entry in /etc/nsswitch.conf - tcpdump when the problem was reproduced tcpdump -i any -nl -vvv -s 2048 port domain >/tmp/domain.log 2>&1 & snmpget pkill tcpdump and append domain.log to this bug report. Also if you're using named service on some of the broken machines, attach named.conf From User-Agent: XML-RPC The patch fixes the problem. inet_addr return a in_addr_t which actually gets traced back to an unsigned int. The code assumed that the return was actually an unsigned long. On 32 bit systems this works fine since (unsigned int) -1 == (unsigned long) -1 But this doesn't work on x86_64. This patch fixes two things. First it fixes places where the return value of inet_addr was assumed to be an unsigned anything and was made to be a in_addr_t. It also fixes places where the return was tested against some casted -1 and made instead to be checked against INADDR_NONE which should be consistant on any platform. I believe this fix needs to be taken upstream. File uploaded: net-snmp-5.0.9-intet_addr.patch This event sent from IssueTracker by eparis issue 72759 it_file 42716 Created attachment 116569 [details]
Cleans up silly ulong vs in_addr_t stuff
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-373.html |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1 Description of problem: on some boxes I can config my snmpd.conf with a hostname, and am able to snmpwalk the box fine from my central snmp (cricket) server. on other boxes I need to use the IP address rather then the host name snmpd.conf is very simple. rocommunity mykey hostname.com or on boxes with IP rocommunity mykey 10.0.0.139 seems like on some boxes it can translate that hostname.com is 10.0.0.139 and thus allow it to snmpwalk the MIB's but on other boxes it can do the DNS translation and I am forced to use the IP for hostname.com on the server where I need to use IP it can nslookup the hostname.com from command line. Version-Release number of selected component (if applicable): net-snmp-5.1.2-11 & net-snmp-5.0.9-2.30E.12 How reproducible: Sometimes Steps to Reproduce: 1. config snmpd with hostname 2. try and snmpwalk from that configured hostname 3. sometimes that will work, if not 4. change snmpd.conf and replace hostname with the IP for hostname 5. snmpwalk again (which will usually work) Actual Results: in cases where it is not accepting IP tcpdump will show the connection to dst port 161 but will not return any info... I.E. it's making it there but being denied on the snmpd ACL level. Expected Results: snmpwalk should work for both hostname and IP consistenly, or should not accept the hostname in the config if we *should* be only using IP in the conf file. Additional info: