Bug 152448 - snmpd.conf hostname vs. IP inconsistancy
snmpd.conf hostname vs. IP inconsistancy
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: net-snmp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Depends On:
Blocks: 156320
  Show dependency treegraph
Reported: 2005-03-29 12:08 EST by Chris Stankaitis
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHSA-2005-373
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-28 10:25:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Stankaitis 2005-03-29 12:08:15 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

seems like on some boxes it can translate that hostname.com is 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:

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:
Comment 1 Radek Vokal 2005-04-04 07:46:58 EDT
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... 
Comment 2 Chris Stankaitis 2005-04-05 09:13:49 EDT
where should we start, what info can I provide to help us track down this issue?
Comment 3 Radek Vokal 2005-05-24 03:06:49 EDT
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 &
   pkill tcpdump

and append domain.log to this bug report. 
Also if you're using named service on some of the broken machines, attach

Comment 5 Issue Tracker 2005-07-09 13:52:55 EDT
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
Comment 6 Eric Paris 2005-07-10 10:10:00 EDT
Created attachment 116569 [details]
Cleans up silly ulong vs in_addr_t stuff
Comment 11 Red Hat Bugzilla 2005-09-28 10:25:47 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.