openwrt / packages

Community maintained packages for OpenWrt. Documentation for submitting pull requests is in CONTRIBUTING.md
GNU General Public License v2.0
4.03k stars 3.5k forks source link

snmpd: listens on the wrong version of IP, causes connection failure #4758

Closed sourcejedi closed 7 years ago

sourcejedi commented 7 years ago

Maintainer: @stintel Environment: LEDE 17.01.2

Description:

snmpd only listens on the legacy version of IP. But, the DNS server in LEDE advertises IPv6, which is preferred by DNS resolver libs. As a result, attempting to connect to snmpd using the routers hostname will fail.

This was particularly confusing on my Debian Jessie server, where Cacti tries to use IPv6 and fails, but the commandline tools snmpwalk etc still only use legacy IP, and hence succeed.

sourcejedi commented 7 years ago

I tried changing agentaddress to UDP:161,UDP6:161 or UDP6:161. Both of these had the desired effect in netstat -l output. Unfortunately, neither of them seemed to respond to SNMP queries sent by Cacti:

$ sudo tcpdump -i eth0 udp port snmp -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 12:53:11.468948 IP6 fd5e:fcf3:b885:10:250:43ff:fe01:c0ab.52330 > fd5e:fcf3:b885:10::1.161: GetRequest(28) .1.3.6.1.2.1.1.1.0 12:53:11.970486 IP6 fd5e:fcf3:b885:10:250:43ff:fe01:c0ab.52330 > fd5e:fcf3:b885:10::1.161: GetRequest(28) .1.3.6.1.2.1.1.1.0 12:53:12.471217 IP6 fd5e:fcf3:b885:10:250:43ff:fe01:c0ab.52330 > fd5e:fcf3:b885:10::1.161: GetRequest(28) .1.3.6.1.2.1.1.1.0 12:53:12.971939 IP6 fd5e:fcf3:b885:10:250:43ff:fe01:c0ab.52330 > fd5e:fcf3:b885:10::1.161: GetRequest(28) .1.3.6.1.2.1.1.1.0

It works fine if I point Cacti at the address router.local, which uses MDNS, which is configured for IPv4 only. Or if I use an IPv4 address directly.

12:54:31.492124 IP 172.16.1.8.58309 > 172.16.1.2.161: GetRequest(28) .1.3.6.1.2.1.1.1.0 12:54:31.492809 IP 172.16.1.2.161 > 172.16.1.8.58309: GetResponse(99) .1.3.6.1.2.1.1.1.0="Linux mortar.carrier.duckdns.org 4.4.71 #0 Wed Jun 7 19:24:41 2017 mips" 12:54:31.496607 IP 172.16.1.8.53492 > 172.16.1.2.161: GetRequest(28) .1.3.6.1.2.1.1.3.0 12:54:31.497250 IP 172.16.1.2.161 > 172.16.1.8.53492: GetResponse(30) .1.3.6.1.2.1.1.3.0=4597 12:54:31.500179 IP 172.16.1.8.42773 > 172.16.1.2.161: GetRequest(28) .1.3.6.1.2.1.1.5.0 12:54:31.500846 IP 172.16.1.2.161 > 172.16.1.8.42773: GetResponse(39) .1.3.6.1.2.1.1.5.0="HeartOfGold" 12:54:31.503523 IP 172.16.1.8.51852 > 172.16.1.2.161: GetRequest(28) .1.3.6.1.2.1.1.6.0 12:54:31.504104 IP 172.16.1.2.161 > 172.16.1.8.51852: GetResponse(34) .1.3.6.1.2.1.1.6.0="office" 12:54:31.506760 IP 172.16.1.8.49492 > 172.16.1.2.161: GetRequest(28) .1.3.6.1.2.1.1.4.0 12:54:31.507465 IP 172.16.1.2.161 > 172.16.1.8.49492: GetResponse(44) .1.3.6.1.2.1.1.4.0="bofh@example.com"

I can't get any relevant logging, either way. Best I could get was this:

# /usr/sbin/snmpd -f -LE 7 -Dall -c /var/run/snmpd.conf2 buffer too small to read octet string (11 < 11) MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs Cannot find module (SNMPv2-MIB): At line 0 in (none) Cannot find module (IF-MIB): At line 0 in (none) Cannot find module (IP-MIB): At line 0 in (none) Cannot find module (TCP-MIB): At line 0 in (none) Cannot find module (UDP-MIB): At line 0 in (none) Cannot find module (HOST-RESOURCES-MIB): At line 0 in (none) Cannot find module (NOTIFICATION-LOG-MIB): At line 0 in (none) Cannot find module (DISMAN-EVENT-MIB): At line 0 in (none) Cannot find module (DISMAN-SCHEDULE-MIB): At line 0 in (none) Cannot find module (SNMP-VIEW-BASED-ACM-MIB): At line 0 in (none) Cannot find module (SNMP-COMMUNITY-MIB): At line 0 in (none) Cannot find module (SNMP-FRAMEWORK-MIB): At line 0 in (none) Cannot find module (SNMP-MPD-MIB): At line 0 in (none) Cannot find module (SNMP-USER-BASED-SM-MIB): At line 0 in (none) Cannot find module (TUNNEL-MIB): At line 0 in (none) Cannot find module (IPV6-FLOW-LABEL-MIB): At line 0 in (none) Cannot find module (UCD-DLMOD-MIB): At line 0 in (none) Cannot find module (NET-SNMP-PASS-MIB): At line 0 in (none) Turning on AgentX master support. NET-SNMP version 5.7.3 No pgpgin line in /proc/vmstat No pgpgout line in /proc/vmstat No pswpin line in /proc/vmstat No pswpout line in /proc/vmstat

zorun commented 7 years ago

Do you have a firewall for IPv6? This package is normally built with IPv6 support so it should work.

sourcejedi commented 7 years ago

For comparison, the Debian Jessie snmpd-5.7.2.1+dfsg-1 can also be configured to listen on IPv6; there is a commented example in snmpd.conf. It seemed to suffer the same problem: my cacti could send requests to it over IPv6, but no reply is sent. It turns out you also have to uncomment a line further down in order to authorize access over ipv6, which starts rocommunity6.

The problem is I don't know how I would grant access over ipv6 in LEDE's /etc/config/snmp. It doesn't use the new rocommunity syntax.

I'm able to SSH in over IPv6, and I don't think I have any custom firewall rules which block SNMP or blanket block IPv6.

sourcejedi commented 7 years ago

@zorun do you agree that the default should be changed to listen to IPv6 (and allow the same access as IPv4)?

I.e. I got it to work now, but surely it's a bug that I had to go through it

--- snmpd-opkg  2017-02-17 00:11:18.000000000 +0000
+++ snmpd   2017-08-25 13:04:37.000000000 +0000
@@ -1,5 +1,5 @@
 config agent
-   option agentaddress UDP:161
+   option agentaddress UDP:161,UDP6:161

 config agentx
    option agentxsocket /var/run/agentx.sock
@@ -9,10 +9,15 @@
    option source default
    option community public

+config com2sec6 public
+        option secname ro
+        option source default
+        option community public
+
stintel commented 7 years ago

Can hardly call this a bug, as it's just a matter of changing the configuration, but I'll update the default.

stintel commented 7 years ago

Hmm, there seems to be a UCI bug. Adding the config com2sec6 public section overrides the config com2sec public section.

stintel commented 7 years ago

Fixed in e4165b44525131cc03399774a5f5ca4853b4679f.

sourcejedi commented 7 years ago

Thanks for considering my report, regardless of what it should be described as :).