Error opening specified endpoint udp 161

Что не пускает к агенту SNMP?

ОС Debian (lenny). Установлен SMTPD, настроен. Команда к примеру #snmpwalk -c public localhost -v1 отрабатывает без проблем. Стоит localhost заменить реальным IP адресом компьютера, например snmpwalk -c public 192.168.1.55 -v1, получаем Timeout: No Response from 192.168.1.55. С других машин локалки разумеется доступа тоже нет.

Кусок файла конфигурации: com2sec local localhost public com2sec localnet 192.168.0.0/24 public

Вроде ж прописано — пущать в/из локалки. Что то где то надо ещё?

в /etc/default/snmp-что-то там там по умолчанию он слушает на 127.0.0.1
Соответственно, когда вы указываете localhost — он обращается на 127.0.0.1 Это же можно было узнать посмотрев нетстатом =)

Не так всё просто

Чуть позже выяснил, что агент по умолчанию сел на UDP6. Прописал в файл snmpd.conf строку:

В результате имеем:

Dec 11 14:32:41 begemot snmpd[2325]: error on subcontainer ‘ia_addr’ insert (-1) Dec 11 14:32:41 begemot snmpd[2325]: Error opening specified endpoint «udp:161» Dec 11 14:32:41 begemot snmpd[2325]: Server Exiting with code 1

Пробовал сажать на другие порты. Сел на 162, но работал нестабильно и в конце концов тоже перестал его подключать.

begemot, вы читали, что я написал в предыдущем посте?
файлик точно /etc/default/snmpd

Но пардон!

А кто ему не даёт то сесть на 161 порт НЕ по умолчанию, если я прописал в конфиге /etc/snmpd.conf строку

И почему он при этом садится на 162. Нетстат как раз показывает, что оба порта одинаково свободны.

Спасибо, основные проблемы решены.

Осталась одна, касающаяся ловли трапов. Как избавиться от сообщения:

snmptrapd[2205]: Warning: no access control information configured.

Источник

SNMPD bind error in Ubuntu 14.04 Server

I am trying to get SNMPD working on my Zenoss server that runs Ubuntu Server 14.04. I installed it and configured it but when I start it up, i get the following error in syslog:

If I run SNMPD at a command line (sudo /usr/sbin/snmpd -f) it works fine. I did a netstat -oan | grep 161 and there is nothing else binding to port 161. Here is my config file (comments removed):

And my snmpd settings file (comments removed):

3 Answers 3

The problem seems to be here:

-c /etc/snmp/snmpd.conf

Remove that from your /etc/default/snmpd so it looks like this:

If you want to get snmpd to listen on 0.0.0.0 (or all interfaces) then edit:

So it looks like this:

This might be a Permission problem.

under normal situations non-root users are not able to bind to ports

Error opening specified endpoint «udp:127.0.0.1:161»

This looks like quite a slippery area in the snmpd codebase — not sure if this is a property of snmpd (as part of Net-SNMP) or Debian and friends.

I’ve encountered this just now in Debian 11.3.

Too lazy to dive into source code, I’ve managed to find another symptom of the error using strace : namely strace -f -o /var/trace.txt snmpd -u root -g root . In the output trace, you get two consecutive bind() calls on 0.0.0.0:161, the first one succeeds, and the second call fails with EADDRINUSE = address already in use. Initially I dodn’t notice that there were two consecutive bind() attempts, so I went looking for the culprit using netstat -lnp , which yielded no candidates. Then I had a flurry of socket-related keywords emanate from my ageing grey matter, along the lines of TIME_WAIT, SO_LINGER, SO_REUSEADDR (mind that this probably points to TCP only, not UDP) — until I noticed that snmpd itself is actually the culprit!

There’s a Debian bug report along those lines, filed in 2017 for snmpd v5.7. I am already at v5.9, and apparently the bug (or similar) is still there.

There’s another bug report filed with Net-SNMP in 2019 for v5.8 — which claims that the first bind() attempt actually stems from the trapsink keyword somewhere in the config files, specifying the localhost address, and defaulting to port 161 as well. I’ve tried following that advice and it doesn’t seem to apply to my case.

Mine appears to be the «debian flavoured» bug above. Actually my best bet is to exclude (comment out) any references to agentAddress anywhere in the config files — in that case, snmpd will end up starting, reported by netstat as listening on 0.0.0.0:161 . If I add my own declaration of agentAddress , it must not overlap with the default IP Address (0.0.0.0) which is impossible, or it must contain a different UDP port (or TCP instead of UDP). If I meet that rule, both those sockets become open, do listen and I do get the same response to my SNMP queries from both.

Coupled to that, I’ve noticed some peculiarities in the «precedence of config files», such as:

• if I specify agentAddress in both /usr/share/snmp/snmpd.conf and /etc/snmp/snmpd.conf , the declaration in /etc/snmp/snmpd.conf gets ignored, and the one in /usr/share/snmp/snmpd.conf prevails — despite the fact that I can see both these files getting open in strace output.
• the debianese systemd wrapper around snmpd, called /etc/systemd/system/multi-user.target.wants/snmpd.service contains some extra cmdline args: ExecStart=/usr/sbin/snmpd -LOw -I -smux,mteTrigger,mteTriggerConf that are kind of difficult for me to follow to all their respective resulting effects, and somehow they do affect the MIB’s that get loaded (compared to me just running snmpd by hand at the cmdline) — I get the lmSensors MIB loaded if I start snmpd via systemd, otherwise not. Possibly the modules excluded by the -I — option are troublesome. Also, the systemd wrapper contains an extra condition: ConditionPathExists=/etc/snmp/snmpd.conf . So I cannot just erase /etc/snmp/snmpd.conf. And if I just «touch» an empty file, snmpd starts, but doesn’t respond to the lmSensors OID’s.

In other words, there are several similar misbehaviors around the default IP and socket to bind, and whether this gets overridden by an explicit agentAddress (or collides with it). Plus, based on what different people report as workarounds, the precedence of config files can also differ between distroes. It is curious to me that this sounds like a fairly boring area of the codebase, and it has bugs — and yet the arcane SNMP engine and modular architecture of the thing (pluggable sub-agents) seems rock solid.

Источник

Problem starting net-snmp-5.7_3

cybercoke

Hy guys, I installed net-snmp-5.7_3 on several FreeBSD 8.1-RELEASE machines without any problem, but, when I try to start it with default config /usr/local/share/snmp/snmpd.conf (copy by snmpd.conf.sample) it gave me the following error:

There are no other snmpd.conf anywhere on the paths that it looking for. If I start it from [cmd=]/usr/local/etc/rc.d/snmpd start[/cmd] it gave me the following error:

SirDice

Administrator

cybercoke

Hy SirDice, here is my snmpd.conf:

SirDice

Administrator

cybercoke

SirDice

Administrator

cybercoke

It does the same error:

SirDice

Administrator

Isn’t it already running? It looks like it’s trying to add stuff that’s already there.

ps -aux | grep snmpd

cybercoke

Isn’t it already running? It looks like it’s trying to add stuff that’s already there.

ps -aux | grep snmpd

There is nothing running at all.

cybercoke

Hi guys, I still can’t get net-snmp to work on several machines. Please help me.

SirDice

Administrator

Ah.. I couldn’t figure it out myself. So I just installed it and started playing with it.

Remove your /usr/local/share/snmp/snmpd.conf and run the following command:
# snmpconf -g basic_setup

Answer the questions and it’ll generate a proper snmpd.conf. Copy that file to /usr/local/share/snmp/. It should start properly now.

cybercoke

Ah.. I couldn’t figure it out myself. So I just installed it and started playing with it.

Источник

net-snmp v5.8: trapsink to localhost causes snmpd to fail #34

@bvanassche I encountered the same issue as described in

on my Gentoo system with with the net-analyzer/net-snmp-5.8-r1 package.

It seems to me that the sourceforge ticket was closed by you erroneously without confirming the bug, because you were not able to reproduce the issue with commit 90837dc.

However, I suspect that it is indeed a bug in v5.8 which has disappeared in the mean time on master, possibly during the refactoring of netsnmp_sockaddr_in3 in 8169aca. (Unfortunately, I was not able to verify my conjecture because I failed to configure and build a vanilla net-snmp from the master branch.)

Please reconsider the issue using release v5.8 (463235e) and let me know whether it is indeed a bug or a misconfiguration. Since v5.8 is the current release it would be helpful to have an official confirmation of the bug (with possible workarounds), to prevent others from spending the same time to figure out the problem.

Details

The problem occurred on my Gentoo system with the portage package net-analyzer/net-snmp-5.8-r1. Looking at the gentoo patch set, there seem to be no significant changes to the source code of v5.8 (463235e):

The error case

The attached /etc/snmp/snmpd.conf contains an agentAddress and a trapsink declaration:

According to the documentation, I would expect that the default trapsink port is 162. It turns out however, that port 161 is bound twice and the second call fails with EADDRINUSE:

strace

net-snmpd.log

Workaround

After adding the port number 162 explicitly to the trapsink declaration, the daemon starts up without error:

strace

net-snmpd.log

The text was updated successfully, but these errors were encountered:

Источник

Installing net-mgmt/net-snmpd and getting it running

NOTE: IF YOU WANT TO GET IT WORKING, skip down to The Recipe.

I want to measure more stuff. I have catci running on some machines, but I have long neglected those stats. In response to my recent post on the FreeBSD Forums, I was introduced to LibreNMS. I was granted access to a running system and I liked what I saw.

The system is built around gathering information via snmpd . I have a few nodes installed now and I’m slowing added new nodes. For now, I have some issues with snmpd I want to resolve before proceeding.

NOTE: please skip down to the bottom section where you’ll find the recipe I now use for snmp v3 clients.

Installation

What? Don’t read this. Skip to the bottom section where you get good advice. This section goes horribly wrong.

I am installing from packages and I build my own via poudriere . The pkg-message for this port is:

I have a few issues with the above.

Configuration file

If I install lines 8-9, the daemon does not start:

I changed the line in /etc/rc.conf to:

I changed this line in /usr/local/etc/snmp/snmpd.conf to use my local IP address:

Attempts to start snmpd failed:

Looking in /var/log/snmpd.log I saw:

I commented out each line mentioned by number, and the lines with test1 and test2 and tried again:

I commented out AgentX and tried again:

This should not be this much work…

A problem I encountered, which you probably won’t see

I had problems getting net-snmp running on one host. It would run just fine on 127.0.0.1 , but not on any other host. I could not figure it out.

Then I noticed this message in /var/log/messages :

This host has been around since FreeBSD 6.1 back in 2006. I was making use of hosts.allow back then, but I never use it now.

I uncommented this line from /etc/hosts.allow and then net-snmp just ran.

The recipe

I got some help from Ryan Steinmetz who suggested I use this approach.

First, we install net-snmp:

I added this to /etc/rc.conf :

NOTE: in my original post, the -r option was missing.

The configuration file is pretty simple. I started with the supplied example:

I made only this change:

Where 10.0.0.1 is the IP Address that snmpd should listen on.

Next, a wee bit of the documentation:

Now for the formula:

NOTE: in more older versions of this app, the above message will contain this instead:

Move that file to where it can be used:

Also in the older versions, but not recently, I had to do this:

This should just work.

NOTE: you might want to delete the above from your shell history…. no sense leaving those passwords sitting there.

I found wonkiness if you have to put quotes around the -X parameter… observe the output of the net-snmp-config and keep that in mind.

To test that you have the correct passwords, try this:

Источник

root@molly:~#snmpconf -g basic_setup

The following installed configuration files were found:

   1:  ./snmpd.conf

Would you like me to read them in?  Their content will be merged with the
output files created by this session.

Valid answer examples: "all", "none","3","1,2,5"

Read in which (default = all): none
************************************************
*** Beginning basic system information setup ***
************************************************
Do you want to configure the information returned in the system MIB group (contact info, etc)? (default = y): y

Configuring: syslocation
Description:
  The [typically physical] location of the system.
    Note that setting this value here means that when trying to
    perform an snmp SET operation to the sysLocation.0 variable will make
    the agent return the "notWritable" error code.  IE, including
    this token in the snmpd.conf file will disable write access to
    the variable.
    arguments:  location_string

The location of the system: At home

Finished Output: syslocation  "At home"

Configuring: syscontact
Description:
  The contact information for the administrator
    Note that setting this value here means that when trying to
    perform an snmp SET operation to the sysContact.0 variable will make
    the agent return the "notWritable" error code.  IE, including
    this token in the snmpd.conf file will disable write access to
    the variable.
    arguments:  contact_string

The contact information: SirDice

Finished Output: syscontact  SirDice
Do you want to properly set the value of the sysServices.0 OID (if you don't know, just say no)? (default = y): y

Configuring: sysservices
Description:
  The proper value for the sysServices object.
    arguments:  sysservices_number

does this host offer physical services (eg, like a repeater) [answer 0 or 1]: 0
does this host offer datalink/subnetwork services (eg, like a bridge): 0
does this host offer internet services (eg, supports IP): 1
does this host offer end-to-end services (eg, supports TCP): 1
does this host offer application services (eg, supports SMTP): 1

Finished Output: sysservices 76
**************************************
*** BEGINNING ACCESS CONTROL SETUP ***
**************************************
Do you want to configure the agent's access control? (default = y): y
Do you want to allow SNMPv3 read-write user based access (default = y): n
Do you want to allow SNMPv3 read-only user based access (default = y): n
Do you want to allow SNMPv1/v2c read-write community access (default = y): n
Do you want to allow SNMPv1/v2c read-only community access (default = y): y

Configuring: rocommunity
Description:
  a SNMPv1/SNMPv2c read-only access community name
    arguments:  community [default|hostname|network/bits] [oid]

The community name to add read-only access for: public
The hostname or network address to accept this community name from [RETURN for all]:
The OID that this community should be restricted to [RETURN for no-restriction]:

Finished Output: rocommunity  public
Do another rocommunity line? (default = y): n
****************************************
*** Beginning trap destination setup ***
****************************************
Do you want to configure where and if the agent will send traps? (default = y): n
****************************************
*** Beginning monitoring setup ***
****************************************
Do you want to configure the agent's ability to monitor various aspects of your system? (default = y): n

Error: An snmpd.conf file already exists in this directory.

'overwrite', 'skip', 'rename' or 'append'? : overwrite


The following files were created:

  snmpd.conf

These files should be moved to /usr/local/share/snmp if you
want them used by everyone on the system.  In the future, if you add
the -i option to the command line I'll copy them there automatically for you.

Or, if you want them for your personal use only, copy them to
/root/.snmp .  In the future, if you add the -p option to the
command line I'll copy them there automatically for you.

root@molly:~#cp snmpd.conf /usr/local/share/snmp/
root@molly:~#service snmpd start
Starting snmpd.
root@molly:~#

Модераторы: GRooVE, alexco

less /usr/local/etc/snmp/snmpd.conf
rocommunity  Ka5tu3e7!gh 192.168.95.99

#################### SNMP ################
snmpd_enable="YES"
snmpd_conffile=/usr/local/etc/snmp/snmpd.conf
NET_SNMP_LOGFILE=/var/log/snmpd.log

/usr/local/etc/rc.d/snmpd start
Starting snmpd.
/usr/local/etc/rc.d/snmpd: WARNING: failed to start snmpd

tail -f /var/log/snmpd.log
mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st"
Error opening specified endpoint ""
Server Exiting with code 1

ls -la /var/log/sendmail.st
-rw-r--r--  1 root  wheel  0 12 апр 03:00 /var/log/sendmail.st

/usr/local/etc/rc.d/snmpd start
Starting snmpd.
/usr/local/etc/rc.d/snmpd: WARNING: failed to start snmpd
tail -f /var/log/snmpd.log
mibII/mta_sendmail.c:open_sendmailst: could not guess version of statistics file "/var/log/sendmail.st"
Error opening specified endpoint ""
Server Exiting with code 1

###########################################################################
# SECTION: Agent Operating Mode
#
#   This section defines how the agent will operate when it
#   is running.

# agentaddress: The IP address and port number that the agent will listen on.
#   By default the agent listens to any and all traffic from any
#   interface on the default SNMP port (161).  This allows you to
#   specify which address, interface, transport type and port(s) that you
#   want the agent to listen on.  Multiple definitions of this token
#   are concatenated together (using ':'s).
#   arguments: [transport:]port[@interface/address],...

#  Listen for connections from the local system only
#agentAddress  udp:127.0.0.1:161

#  Listen for connections on all interfaces (both IPv4 *and* IPv6)
#agentAddress udp:161,udp6:[::1]:161

#agentAddress udp:161@fxp0/10.20.0.1

agentAddress  udp:10.10.0.1:161

@bvanassche I encountered the same issue as described in

• sourceforge #2978 — trapsink to localhost causes snmpd to fail

on my Gentoo system with with the net-analyzer/net-snmp-5.8-r1 package.

It seems to me that the sourceforge ticket was closed by you erroneously without confirming the bug, because you were not able to reproduce the issue with commit 90837dc.

However, I suspect that it is indeed a bug in v5.8 which has disappeared in the mean time on master, possibly during the refactoring of netsnmp_sockaddr_in3 in 8169aca. (Unfortunately, I was not able to verify my conjecture because I failed to configure and build a vanilla net-snmp from the master branch.)

Please reconsider the issue using release v5.8 (463235e) and let me know whether it is indeed a bug or a misconfiguration. Since v5.8 is the current release it would be helpful to have an official confirmation of the bug (with possible workarounds), to prevent others from spending the same time to figure out the problem.

Details

The problem occurred on my Gentoo system with the portage package net-analyzer/net-snmp-5.8-r1. Looking at the gentoo patch set, there seem to be no significant changes to the source code of v5.8 (463235e):

/usr/portage/net-analyzer/net-snmp/files # for patch in net-snmp-5.8-*.patch; do echo $patch; diffstat $patch; done
net-snmp-5.8-do-not-conflate-LDFLAGS-and-LIBS.patch
 net-snmp-config.in |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
net-snmp-5.8-my_bool.patch
 snmptrapd_sql.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net-snmp-5.8-pcap.patch
 config_os_libs2            |   18 ++++++++++--------
 config_project_with_enable |    5 +++++
 2 files changed, 15 insertions(+), 8 deletions(-)
net-snmp-5.8-tinfo.patch
 config_os_libs2 |    1 +
 1 file changed, 1 insertion(+)

The error case

The attached /etc/snmp/snmpd.conf contains an agentAddress and a trapsink declaration:

agentAddress  udp:127.0.0.1:161
# ...
trapsink     localhost public

According to the documentation, I would expect that the default trapsink port is 162. It turns out however, that port 161 is bound twice and the second call fails with EADDRINUSE:

strace

~ # strace /usr/sbin/snmpd -f  -f -Dnetsnmp_sockaddr_in -Dnetsnmp_udpbase |& grep 'bind.*INET'
bind(12, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
bind(11, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)

net-snmpd.log

# cat /var/log/net-snmpd.log 
netsnmp_sockaddr_in: addr 0x7fffac6cca70, inpeername "localhost", default_target ":162"
netsnmp_sockaddr_in: addr 0x7fffac6cca70, inpeername ":162", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 162
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:162 }
netsnmp_sockaddr_in: check user service localhost
netsnmp_sockaddr_in: servname not numeric, check if it really is a destination)
netsnmp_sockaddr_in: check destination localhost
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:162 }
netsnmp_sockaddr_in: addr 0x7fffac6cca80, inpeername "localhost", default_target "[NIL]"
netsnmp_sockaddr_in: check user service localhost
netsnmp_sockaddr_in: servname not numeric, check if it really is a destination)
netsnmp_sockaddr_in: check destination localhost
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
netsnmp_udpbase: open remote UDP: [127.0.0.1]:162->[0.0.0.0]:0
netsnmp_udpbase: binding socket: 12 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: socket 12 bound to UDP: [127.0.0.1]:162->[127.0.0.1]:161
Turning on AgentX master support.
netsnmp_sockaddr_in: addr 0x7fffac6ceed0, inpeername "127.0.0.1:161", default_target ":161"
netsnmp_sockaddr_in: addr 0x7fffac6ceed0, inpeername ":161", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: check destination 127.0.0.1
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
netsnmp_udpbase: open local UDP: [127.0.0.1]:161->[0.0.0.0]:0
netsnmp_udpbase: set IP_PKTINFO
netsnmp_udpbase: binding socket: 11 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: failed to bind for clientaddr: 98 Address already in use
Error opening specified endpoint "udp:127.0.0.1:161"
Server Exiting with code 1

Workaround

After adding the port number 162 explicitly to the trapsink declaration, the daemon starts up without error:

agentAddress  udp:127.0.0.1:161
# ...
trapsink     localhost:162 public

strace

~ # strace /usr/sbin/snmpd -f  -f -Dnetsnmp_sockaddr_in -Dnetsnmp_udpbase |& grep 'bind.*INET'
bind(11, {sa_family=AF_INET, sin_port=htons(161), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
read(15, "grep--colour=autobind.*INET", 1024) = 30
^C

net-snmpd.log

~ # cat /var/log/net-snmpd.log 
netsnmp_sockaddr_in: addr 0x7ffe33b0d430, inpeername "localhost:162", default_target ":162"
netsnmp_sockaddr_in: addr 0x7ffe33b0d430, inpeername ":162", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 162
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:162 }
netsnmp_sockaddr_in: check user service 162
netsnmp_sockaddr_in: check destination localhost
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:162 }
netsnmp_udpbase: open remote UDP: [127.0.0.1]:162->[0.0.0.0]:0
Turning on AgentX master support.
netsnmp_sockaddr_in: addr 0x7ffe33b0f890, inpeername "127.0.0.1:161", default_target ":161"
netsnmp_sockaddr_in: addr 0x7ffe33b0f890, inpeername ":161", default_target "[NIL]"
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 }
netsnmp_sockaddr_in: check user service 161
netsnmp_sockaddr_in: check destination 127.0.0.1
netsnmp_sockaddr_in: hostname (resolved okay)
netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 }
netsnmp_udpbase: open local UDP: [127.0.0.1]:161->[0.0.0.0]:0
netsnmp_udpbase: set IP_PKTINFO
netsnmp_udpbase: binding socket: 11 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
NET-SNMP version 5.8
Received TERM or STOP signal...  shutting down...