Re: SNMPD v5.8 Error opening specified endpoint
Bill Fenner <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <CAF4SogZjZd8eZN62gsC0PDacY0ntH32KmB=zWFrsv4S8emNWYQ@mail.gmail.com> |
On Sat, Aug 25, 2018 at 3:45 PM Martin Frlin <[email protected]> wrote: > If you specify trapsink line in form localhost:<port> it does not bind a > socket because it does not set a source in the piece of code I have linked. > I was suggesting adding "-s 127.0.0.1:<some high level port>" to your trapsink line, like trapsink -s 127.0.0.1:62134 localhost public and trapsink -s 127.0.0.1:0 localhost public Regarding why it binds to port 161 I don't understand your comment. I know > that destination port will be 162 because that is where the snmptrapd > listens (by default). > The code that's being used to turn "localhost" into a transport spec thinks it's being used for an SNMP listener, not a clientaddr, so it defaults to port 161. This looks like it's a bug that was added in 5.8, and partially worked around with the new "clientaddrUsesPort" configuration that you found but as you found that's also buggy. > If someone can explain the reasoning why is binding happening if trapsink > is on localhost and not if it is on remote and why it always binds on port > 161 thus creating a problem I could make a patch that resolves this issue. > I don't quite know why this behavior is desirable. From the comment, I *think* the intent to address the problem that a socket that is bound to a port will receive packets destined to that port, so if you bind to 0.0.0.0:62134 and someone sends you a packet to port 62134 that socket will receive it. This isn't much of a problem since snmpd never reads from this port. The intention is to bind to localhost:0, which will cause the kernel to pick a port, but due to the bug I mentioned above it tries to use localhost:161. Bill V V pet., 24. avg. 2018 ob 19:57 je oseba Bill Fenner <[email protected]> > napisala: > >> On Thu, Aug 23, 2018 at 9:24 AM Martin Frlin <[email protected]> >> wrote: >> >>> Ok, additional information. >>> Compare this line in v5.8: >>> https://sourceforge.net/p/net-snmp/code/ci/master/tree/agent/agent_trap.c#l358 >>> with this line >>> https://sourceforge.net/p/net-snmp/code/ci/v5.7.3/tree/agent/agent_trap.c#l251 >>> >>> You will see that v5.7 does not set a source. And because it does not >>> set a source it does not bind. >>> >>> But maybe we want to bind? (Source says we want to reduce open ports but >>> I don't understand this) >>> >>> Ok, but why bind on port 161? If understand correctly we want to SEND >>> traps. So we should bind localhost:<random high level port> -> >>> localhost:162 (address of our snmptrapd), but this does not happen. >>> Instead we get (note that netsnmp prints to->from): >>> netsnmp_udpbase: binding socket: 9 to UDP: [0.0.0.0]:0->[127.0.0.1]:161 >>> netsnmp_udpbase: socket 9 bound to UDP: [127.0.0.1]:162->[127.0.0.1]:161 >>> >>> So why is socket bound on port 161 instead of some random high level >>> port? I didn't find where in code port 161 is set. >>> >> >> It comes from the code that parses transport specifications. But it's >> assuming that it's parsing a destination, not a source. Even if you told >> that code that you were doing the lookup in the context of a trap, it would >> use 162. >> >> So I think the solution is that either port is unbound or random high >>> level port is chosen for binding. >>> >>> I've also tried to set >>> clientaddr 127.0.0.1:<some high level port> >>> clientaddrUsesPort yes >>> because documentation says this will be used for clients but it also >>> does not work. >>> >> >> Can you try adding "-s 127.0.0.1:<some high level port>" to your >> trapsink line instead? You can also try ":0". >> >> I found a few bugs in the clientaddr changes before 5.8 went out, but I >> don't use trapsink so didn't notice this one. There are a bunch of hacks >> in the clientaddr support that would clearly have been better to push into >> the transport parsing instead. >> >> Bill >> >> >>> V V čet., 23. avg. 2018 ob 11:47 je oseba Martin Frlin < >>> [email protected]> napisala: >>> >>>> If you have line: >>>> trapsink localhost public >>>> in your config v5.8 fails to start. Meanwhile v5.3 starts with no >>>> problems. >>>> >>>> Am I missing something or is this a bug?. >>>> >>>> This output was generated using exactly the same config >>>> v5.8 >>>> # snmpd -Dnetsnmp_udpbase -Lo -f >>>> registered debug token netsnmp_udpbase, 1 >>>> Log handling defined - disabling stderr >>>> netsnmp_udpbase: open remote UDP: [127.0.0.1]:162->[0.0.0.0]:0 >>>> netsnmp_udpbase: binding socket: 9 to UDP: [0.0.0.0]:0->[127.0.0.1]:161 >>>> netsnmp_udpbase: socket 9 bound to UDP: [127.0.0.1]:162->[127.0.0.1]:161 >>>> Turning on AgentX master support. >>>> netsnmp_udpbase: open local UDP: [127.0.0.1]:161->[0.0.0.0]:0 >>>> netsnmp_udpbase: set IP_PKTINFO >>>> netsnmp_udpbase: binding socket: 8 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 >>>> >>>> >>>> v5.3 >>>> # snmpd -Dnetsnmp_udpbase -Lo -f >>>> registered debug token netsnmp_udpbase, 1 >>>> Log handling defined - disabling stderr >>>> netsnmp_udpbase: open remote UDP: [127.0.0.1]:162->[0.0.0.0]:0 >>>> netsnmp_udpbase: client open UDP: [127.0.0.1]:162->[0.0.0.0]:0 >>>> Turning on AgentX master support. >>>> netsnmp_udpbase: open local UDP: [127.0.0.1]:161->[0.0.0.0]:0 >>>> netsnmp_udpbase: set IP_PKTINFO >>>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Net-snmp-users mailing list >>> [email protected] >>> Please see the following page to unsubscribe or change other options: >>> https://lists.sourceforge.net/lists/listinfo/net-snmp-users >>> >> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users