#2978 trapsink to localhost causes snmpd to fail

[Craig Small]

This is snmpd version 5.8 It's running on Debian but I'm using the stock code from the net-snmp tarball. There is no snmpd 5.8 (yet) because this bug stopped me from releasing it.

If snmpd.conf has the following items:

agentAddress udp:127.0.0.1:161
trapsink localhost public

Then snmpd fails to start due to Address already in use.
Im not sure exactly why, but if the trapsink host is "localhost" but not "localhost:162" or "127.0.0.1" or pretty much anything else then the trap source socket will be UDP port 161 (see the binding socket 7 line below). As the trap sending socket is 161 then the snmpd listening on UDP 161 cannot bind to socket and fails.

Any other trapsink will use a random high UDP port for its source, which is the correct operation. snmpd listen port then works fine.

A work-around is to remove the special section in netsnmp_create_v1v2_notification_session that checks for localhost, found in agent/agent_trap.c:

       if ((NULL == client_addr) &&
            ((0 == strcmp("localhost",sink)) ||
             (0 == strcmp("127.0.0.1",sink))))
            client_addr = "localhost";

Commenting this statement out will get it working but seems an unsatisfactory way of working around whatever is thinking if tspec.source is set, then the UDP source port must be 161.

Agent output from snmpd below:

agent/snmpd -f -Dnetsnmp_sockaddr_in -Dnetsnmp_udpbase -m: >/dev/null
registered debug token netsnmp_sockaddr_in, 1
registered debug token netsnmp_udpbase, 1
netsnmp_sockaddr_in: addr 0x7ffc242a65f0, inpeername "localhost", default_target ":162"
netsnmp_sockaddr_in: addr 0x7ffc242a65f0, 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 0x7ffc242a6600, 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: 7 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
netsnmp_udpbase: socket 7 bound to UDP: [127.0.0.1]:162->[127.0.0.1]:161
netsnmp_sockaddr_in: addr 0x7ffc242a89c0, inpeername "127.0.0.1:161", default_target ":161"
netsnmp_sockaddr_in: addr 0x7ffc242a89c0, 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: 6 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

[Bart Van Assche]

I think that trapsink specificies the trap destination address. If snmpd is listening for SNMP requests on port 161, I don't think it makes sense to send traps to port 161.

[Craig Small]

That is the entire point of this bug report. It's not supposed to do that but it is.

Basically it is like this:
Me: trapsink configuration is setting the source address
You: trapsink configuration is not supposed to do that, closing the bug

Did you look at the configuration? The agent address is 161, the trapsink address is using no port but sending them to 162. The "sending to 162" bit is fine, but the trapsink is binding to 161. Yes its not supposed to, yes this is bad, yes this is why there is a bug report.

Somewhere deep in the address resolution code its deciding that no-port + 127.0.0.1 = use 161 which is not correct for all cases, like a trapsink source port.

[Bart Van Assche]

Apologies for having misread this bug report. Anyway, I can't reproduce the reported behavior. If I start snmpd v5.8 from inside the source tree as follows:

agent/snmpd -f -Lo -Mmibs -Dnetsnmp_udpbase -Dnetsnmp_sockaddr -Dtrap -c.../snmpd.conf

then the following debug messages appear (with source and destination address swapped):

trap: send_trap 6 2 NET-SNMP-MIB::netSnmpNotificationPrefix
trap: sending trap type=164, version=0 to UDP: [127.0.0.1]:162->[127.0.0.1]:51206
trap: sending trap type=166, version=3 to UDP: [127.0.0.1]:162->[0.0.0.0]:37458

As one can see the traps are sent to destination port number 162. I used commit [90837dcec21c] for these tests.

[Craig Small]

No worries, its a bit confusing. I noticed those ports too but thought they must have made sense to you.

This bug is highly dependent on the trapsink setting. So depending on what you have in snmpd.conf you may not see it. That's why in the report I gave the exact trapsink line.

[Bart Van Assche]

What I have at the end of my snmpd.conf file is identical to what has been mentioned in the bug report:

agentaddress udp:127.0.0.1:161
trapsink localhost public

[Craig Small]

OK, i was using 5.8, ill sync to the commit you mentioned previously and see if that fixes it.

[Bill Fenner]

This sounds like what I fixed in 06a02b7c708c1ea2bf67e59c333001e8ce128dff ?

[Matthias St. Pierre]

Note: I encountered the same problem and opened a new issue on GitHub:

https://github.com/net-snmp/net-snmp/issues/34