Red Hat Bugzilla – Bug 152448
snmpd.conf hostname vs. IP inconsistancy
Last modified: 2007-11-30 17:07:06 EST
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
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.
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 &
and append domain.log to this bug report.
Also if you're using named service on some of the broken machines, attach
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
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.