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

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

On 11/6/18 8:03 AM, Bill Fenner wrote: My main question is, what's the advantage of storing the IPv4/IPv6 address as a string and a port number, instead of as a sockaddr_*? I.e., why use netsnmp_ep_str? Parsing endpoint addresses happens in two phases: first parsing the endpoint strings and

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

I screwed up the v6 tests a little, and just pushed some fixes to it. The current status is: the 4 tests that are in V5-7-patches all pass (trap2sink, v6 trap2sink, trapsess, v6 trapsess). I applied the same clientaddr port zeroing to v6 as v4 already has in V5-7-patches to get the v6 trapsink

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

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]"

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

Hi Bart, My main question is, what's the advantage of storing the IPv4/IPv6 address as a string and a port number, instead of as a sockaddr_*? I.e., why use netsnmp_ep_str? Is the API change here ok? Are we assuming that nobody ever calls netsnmp_foo_transport() directly? Should there be an