2

Alright, I've got two VMs both running under ESXi. One VM is hosting Observium, which uses SNMP to grab its info. I pointed Observium at my ESXi host directly, and it worked fine, so there's no issue with Observium. Trying to add the device using the proper settings (tried SNMP v1, v2c, and v3), there is always no response from the server.

The hostname for the server in this case is cal, and the hostname for the client is default, just to clarify.

The client I'm sending SNMP requests to is a fresh install of Ubuntu Server 14.04 LTS. All I've done is install the snmpd package, and configure it.

Here's my /etc/snmp/snmpd.conf:

com2sec readonly default taylor
group MyROGroup v1 readonly
group MyROGroup v2c readonly
group MyROGroup usm readonly
view all included .1 80
access MyROGroup “” any noauth exact all none none
syslocation “San Francisco, CA”
syscontact email@somesite.com

To my understanding, placing default before the community name (which is taylor) means it will accept SNMP requests from any IP.

And my /etc/default/snmpd:

export MIBS=
SNMPDRUN=yes
SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid -c /etc/snmp/snmpd.conf'
TRAPDRUN=no
TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'

So figuring I had configured everything just fine, I issue a snmpwalk to test:

taylor@cal:~$ snmpwalk -v 2c -c taylor default
Timeout: No Response from default

I can ping just fine:

taylor@cal:~$ ping default
PING default.mywebsite.com (192.168.1.130) 56(84) bytes of data.
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=1 ttl=64 time=0.350 ms
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=2 ttl=64 time=0.235 ms
64 bytes from default.mywebsite.com (192.168.1.130): icmp_seq=3 ttl=64 time=0.192 ms

taylor@default:~$ ping cal
PING cal.taylorjthurlow.com (192.168.1.112) 56(84) bytes of data.
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=1 ttl=64 time=0.306 ms
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=2 ttl=64 time=0.188 ms
64 bytes from cal.taylorjthurlow.com (192.168.1.112): icmp_seq=3 ttl=64 time=0.264 ms

Wanting to make sure we've got traffic, I issue a tcpdump on both the sending and receiving ends:

Sending (SNMP server):

02:22:51.569041 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:52.569547 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:53.570659 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:54.571775 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:55.572715 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:56.573874 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)

Receiving (SNMPD client):

02:22:51.858750 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:52.859290 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:53.860371 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:54.861495 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:55.862424 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)
02:22:56.863590 IP cal.mywebsite.com.42979 > default.mywebsite.com.snmp:  C=taylor GetNextRequest(25)

So, essentially the same thing, just slightly different timestamps. The concerning thing being that there's no response packets being sent. Alright, so maybe there's a firewall or a port issue.

I disabled Ubuntu's Uncomplicated Firewall with ufw disable and confirmed that it was not running with ufw status.

I then checked my iptables, which were empty from the new installation. I added incoming and outgoing rules for port 161 on the SNMPD client.

taylor@default:~$ sudo iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:161

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:161

Still having the same issue. Another post on either SuperUser or ServerFault was resolved for the same issue because their /etc/hosts.allow and iptables were blocking the traffic. Here are mine:

taylor@default:~$ cat /etc/hosts.allow
# /etc/hosts.allow: list of hosts that are allowed to access the system.
#                   See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: LOCAL @some_netgroup
#             ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.

taylor@default:~$ cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
#                  See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID

I'm out of ideas at this point. Any suggestions on what I can try to get this thing to actually reply to my SNMP queries?


EDIT: Here's my /var/log/syslog on the client:

Dec  9 01:48:24 default snmpd[2888]: NET-SNMP version 5.7.2
Dec  9 01:48:27 default snmpd[2888]: Connection from UDP: [192.168.1.112]:41109->[192.168.1.130]:161
Dec  9 01:50:54 default kernel: [ 8359.253571] nf_conntrack version 0.5.0 (7951 buckets, 31804 max)
Dec  9 01:48:32 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:41109->[192.168.1.130]:161]
Dec  9 01:52:53 default snmpd[2888]: Connection from UDP: [192.168.1.112]:40482->[192.168.1.130]:161
Dec  9 01:54:05 default kernel: [ 8550.718971] ip6_tables: (C) 2000-2006 Netfilter Core Team
Dec  9 01:52:58 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:40482->[192.168.1.130]:161]
Dec  9 01:54:11 default snmpd[2888]: Connection from UDP: [192.168.1.112]:59617->[192.168.1.130]:161
Dec  9 01:54:16 default snmpd[2888]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:59617->[192.168.1.130]:161]
Dec  9 01:56:43 default snmpd[2888]: Received TERM or STOP signal...  shutting down...
Dec  9 01:56:45 default snmpd[3165]: NET-SNMP version 5.7.2
Dec  9 02:00:06 default snmpd[3165]: Received TERM or STOP signal...  shutting down...
Dec  9 02:00:08 default snmpd[3216]: NET-SNMP version 5.7.2
Dec  9 02:00:18 default snmpd[3216]: Connection from UDP: [192.168.1.112]:45692->[192.168.1.130]:161
Dec  9 02:00:23 default snmpd[3216]: message repeated 5 times: [ Connection from UDP: [192.168.1.112]:45692->[192.168.1.130]:161]
Dec  9 02:02:36 default snmpd[3216]: Received TERM or STOP signal...  shutting down...
Dec  9 02:02:38 default snmpd[3242]: Error opening specified endpoint "udp:161"
Dec  9 02:02:38 default snmpd[3242]: Server Exiting with code 1
Dec  9 02:07:16 default snmpd[3281]: duplicate registration: MIB modules pass and pass (oid .1.3.6.1.4.1.4413.4.1).
Dec  9 02:07:16 default snmpd[3281]: Error opening specified endpoint "udp:161"
Dec  9 02:07:16 default snmpd[3281]: Server Exiting with code 1
Dec  9 02:17:01 default CRON[3283]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  9 02:23:55 default kernel: [10340.925233] device eth0 left promiscuous mode

Looks like some of it is due to me watching packets, and then there's a few mentions of Error opening specified endpoint "udp:161" but they're sporadic. Could be something.

EDIT: This was actually due to me trying agentAddress udp:161,udp6:[::1]:161. The logs only said it sporadically because I was enabling and disabling that line. So, back at square one.

  • Is snmpd writing anything into the system logs? – Flup Dec 9 '14 at 11:00
  • @Flup I added what looked to be some relevant stuff from /var/log/syslog to the bottom of my question. As far as I can tell, that showed up there in my efforts to get it to output a log earlier, but I couldn't get it to output anywhere. I'm not exactly unix/linux fluent yet so I wasn't sure about specific log locations but /var/log/syslog seems to be important. – taylorthurlow Dec 9 '14 at 11:08
  • Try removing 80 from the end of the view... configuration line in /etc/snmp/snmpd.conf and restart snmpd. Also, try testing your snmpwalk from the the machine named default (is that the machine you are trying to query?) first using localhost in place of the actual hostname. If that works, then try same but using default's IP address. Again, if that works try from the client. It'll help isolate where the problem may be. – user87664 Dec 10 '14 at 0:37
  • Removed 80 from that line, still no luck. No errors from snmpd in /var/log/syslog due to me changing it either. I tried snmpwalk -v 2c -c taylor localhost and snmpwalk -v 2c -c taylor 192.168.1.130 from default (the client to itself) and those requests also have no response. – taylorthurlow Dec 10 '14 at 0:53
1

I'm not particularly sure why this worked, but I seem to have solved my issue. In my /etc/snmp/snmpd.conf, I replaced the line:

com2sec readonly default taylor

with

rocommunity taylor

and everything works great.

|improve this answer|||||
0

From your logs, the SNMP daemon is failing to bind to port 161 and then exiting:

Dec  9 02:07:16 default snmpd[3281]: Error opening specified endpoint "udp:161"
Dec  9 02:07:16 default snmpd[3281]: Server Exiting with code 1

so the reason you're not getting any replies is that snmpd isn't actually running at the time.

You might try commenting out the agentAddress line in case there's some syntax problem, but it may also be the case that something else is bound to UDP port 161. Check the output of netstat -lnp | grep :161 which will show you what is bound to that port.

|improve this answer|||||
  • I checked, and it wasn't starting properly. That was probably due to me trying the agentAddress thing. Nonetheless, it does start when I have that line commented out, but it still gives me no response. Here's an image of the server on the left, client on the right: i.imgur.com/h40KtDs.png I made sure it was running first, then issued the snmpwalk, then tailed the syslog and it seems normal. – taylorthurlow Dec 9 '14 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.