> On Nov 7, 2018, at 1:27 AM, Bart Van Assche <bvanass...@acm.org> wrote:
>
>> On 11/6/18 12:31 PM, Bill Fenner wrote:
>> Playing with this in V5-8-patches, I see it broke my fix for using
>> clientaddr to specify the source address for traps:
>> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername "127.0.0.1", default_target
>> ":0"
>> netsnmp_sockaddr_in: addr 0xffd5e824, inpeername ":0", default_target "[NIL]"
>> netsnmp_sockaddr_in: return { AF_INET, 0.0.0.0:161 <http://0.0.0.0:161> }
>> netsnmp_sockaddr_in: hostname (resolved okay)
>> netsnmp_sockaddr_in: return { AF_INET, 127.0.0.1:161 <http://127.0.0.1:161> }
>> In the previous implementation, specifying a default_target of ":0" would
>> set the port number to zero, meaning, let the kernel decide. Now, it
>> appears to mean, use the SNMP default. This causes the bind() to fail, of
>> course, since binding to 127.0.0.1:0 <http://127.0.0.1:0> would work fine,
>> but binding to 127.0.0.1:161 <http://127.0.0.1:161> conflicts with the
>> actual snmpd port.
>> netsnmp_udpbase: open remote UDP: [172.25.24.62]:5716->[0.0.0.0]:0
>> netsnmp_udpbase: binding socket: 8 to UDP: [0.0.0.0]:0->[127.0.0.1]:161
>> netsnmp_udpbase: failed to bind for clientaddr: 13 Permission denied
>> snmpd: netsnmp_create_notification_session:
>> /tmp/snmp-test-T180trap2sinkclientaddr_simple-7030/snmpd.conf: line 8:
>> Error: cannot create sink: udp:172.25.24.62:5716 <http://172.25.24.62:5716>
>> I've committed my tests for trap2sink, trapsess, and using "-s" with
>> trapsess. None of the v6 versions work, but the v4 trapsess versions work,
>> after fixing netsnmp_udpipv4base_transport_with_source() to use the
>> "bind_addr" variable. I believe that fixing the parsing of ":0" to return a
>> zero port like it did before would fix trap2sink. I haven't looked at
>> what's wrong with v6 yet.
>> (The confusing code in netsnmp_udpipv4base_transport() around "have_port"
>> and "uses_port", including the introduction of
>> NETSNMP_DS_LIB_CLIENT_ADDR_USES_PORT, is probably completely working around
>> this same bug of setting the port when it doesn't need to be set, and could
>> be eliminated altogether if that bug is fixed.)
>
> Oops, that's something I was not aware of. Can you check that whether the
> changes I checked in earlier today fix this regression? Are there any other
> regressions than this one that you are aware of?
5.8 was released with regressions in this area already, so the regressions that
are present in this branch are not necessarily due to your changes. The T18*
tests (without the change to specify the port explicitly) should all pass (and
do in the 5-7-patches branch).
I think one thing for v6 is that it needs to be able to parse a bare IP address
without port or brackets (for clientaddr purposes).
The T18* tests should probably be improved to prohibit receiving traps sourced
from port 161 or 162, in case someone runs the tests as root. I will look at
making this change.
Bill
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
