Re: [PATCH 0/6] Add support for interface binding

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?

Thanks,

Bart.


_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders