Could you please test this change?
--- a/snmplib/transports/snmpUDPIPv4BaseDomain.c
+++ b/snmplib/transports/snmpUDPIPv4BaseDomain.c
@@ -312,7 +312,7 @@
netsnmp_udpipv4base_tspec_transport(netsnmp_tdomain_spec *tspec)
if (NULL != tspec->source) {
struct sockaddr_in src_addr, *srcp = &src_addr;
/** get sockaddr from source */
- if (!netsnmp_sockaddr_in2(&src_addr, tspec->source, NULL))
+ if (!netsnmp_sockaddr_in2(&src_addr, tspec->source, ":0"))
return NULL;
return netsnmp_udpipv4base_transport_with_source(&addr, local,
srcp);
} else {
Thanks,
Bill
On Sun, Aug 26, 2018 at 8:37 PM Bill Fenner <fen...@gmail.com> wrote:
> On Sat, Aug 25, 2018 at 3:45 PM Martin Frlin <martin.fr...@gmail.com>
> 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 <fen...@gmail.com>
>> napisala:
>>
>>> On Thu, Aug 23, 2018 at 9:24 AM Martin Frlin <martin.fr...@gmail.com>
>>> 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 <
>>>> martin.fr...@gmail.com> 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
>>>> Net-snmp-users@lists.sourceforge.net
>>>> 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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
