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

2019-01-29 Thread Bill Fenner via Net-snmp-coders
On Fri, Jan 25, 2019 at 11:37 AM Magnus Fromreide wrote: > On Sun, Oct 28, 2018 at 01:54:22PM -0700, Bart Van Assche wrote: > > Hello, > > > > As you may have noticed multiple people asked to add SO_BINDTODEVICE > support > > to Net-SNMP. This patch series adds such support by allowing to

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

2019-01-25 Thread Magnus Fromreide
On Sun, Oct 28, 2018 at 01:54:22PM -0700, Bart Van Assche wrote: > Hello, > > As you may have noticed multiple people asked to add SO_BINDTODEVICE support > to Net-SNMP. This patch series adds such support by allowing to specify the > name of the network interface to bind a Net-SNMP endpoint to

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

2019-01-25 Thread Bill Fenner via Net-snmp-coders
I was thinking about adding text below the table instead - "When specifying *hostname*, *IPv4-address* or *IPv6-address* in the tcp, udp, tcp6 or udp6 transports, you can also ...". I don't want to clutter up the main documentation with these kind-of-corner-cases. Bill On Fri, Jan 25, 2019

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

2019-01-25 Thread Anders Wallin
What about something like this ( I skipped the "or") diff --git a/man/snmpcmd.1.def b/man/snmpcmd.1.def index aea3ca40a..d4f896000 100644 --- a/man/snmpcmd.1.def +++ b/man/snmpcmd.1.def @@ -367,12 +367,12 @@ to the following table: .BR "" .BR " format" .IP "udp" 28 -hostname[:port] -.I or

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

2019-01-24 Thread Bill Fenner via Net-snmp-coders
On Wed, Jan 23, 2019 at 10:17 PM Bart Van Assche wrote: > On 1/23/19 9:43 AM, Bill Fenner wrote: > > The pattern I was trying to follow from the existing code appeared to be > > basically > > > > if (cp == delimiter of optional section) { > > *cp = '\0'; /* terminate previous section at

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

2019-01-23 Thread Bart Van Assche
On 1/23/19 9:43 AM, Bill Fenner wrote: The pattern I was trying to follow from the existing code appeared to be basically if (cp == delimiter of optional section) {     *cp = '\0'; /* terminate previous section at delimiter */     this = cp + 1; /* handle this section */     cp = ... /*

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

2019-01-23 Thread Bill Fenner via Net-snmp-coders
My attempts at updating the man page formats really poorly in 80 columns: At its simplest, the AGENT specification may consist of a host- name, or an IPv4 address in the standard "dotted quad" notation. In this case, communication will be attempted using UDP/IPv4 to

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

2019-01-23 Thread Bill Fenner via Net-snmp-coders
On Wed, Jan 23, 2019 at 12:58 AM Anders Wallin wrote: > Hi Bill, > > I'm missing updates to the documentation/man pages. (I can't find that the > man pages are update with @iface either) > Yes, I documented it in the same place as @intf ;-) I'll fix that. Bill

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

2019-01-23 Thread Bill Fenner via Net-snmp-coders
On Wed, Jan 23, 2019 at 12:15 AM Bart Van Assche wrote: > On 1/22/19 12:40 PM, Bill Fenner wrote: > > On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche > > wrote: > > > > On 11/6/18 8:03 AM, Bill Fenner wrote: > > > Given your proposed code structure, I imagine

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

2019-01-22 Thread Anders Wallin
Hi Bill, I'm missing updates to the documentation/man pages. (I can't find that the man pages are update with @iface either) BR Anders ons 23 jan. 2019 kl 06:16 skrev Bart Van Assche : > On 1/22/19 12:40 PM, Bill Fenner wrote: > > On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche >

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

2019-01-22 Thread Bart Van Assche
On 1/22/19 12:40 PM, Bill Fenner wrote: On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche > wrote: On 11/6/18 8:03 AM, Bill Fenner wrote: > Given your proposed code structure, I imagine that we could add network > namespaces to netsnmp_ep too - this

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

2019-01-22 Thread Bill Fenner via Net-snmp-coders
On Wed, Nov 7, 2018 at 1:26 AM Bart Van Assche wrote: > On 11/6/18 8:03 AM, Bill Fenner wrote: > > Given your proposed code structure, I imagine that we could add network > > namespaces to netsnmp_ep too - this basically ends up using "socketat( > > /* magic */, family, type, protocol )" instead

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

2018-11-08 Thread Bill Fenner via Net-snmp-coders
I've applied my clientaddr parsing fix for IPv4 and IPv6, passing ":0" as the default transport, and also modified the IPv6 address parser to handle a bare IPv6 address (no brackets, no port). With these changes, all of the tests pass in their original form. I'd like to add some more tests for

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

2018-11-07 Thread Bill Fenner
> On Nov 7, 2018, at 1:27 AM, Bart Van Assche 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",

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

2018-11-06 Thread Bart Van Assche
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

2018-11-06 Thread Bart Van Assche
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

2018-11-06 Thread Bill Fenner via Net-snmp-coders
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

2018-11-06 Thread Bill Fenner via Net-snmp-coders
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

2018-11-06 Thread Bill Fenner via Net-snmp-coders
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

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

2018-11-02 Thread Bart Van Assche
Hello Sam, Thanks for having tested this code! Bart. On 11/2/18 9:53 AM, Sam Tannous wrote: Hi Bart, I've merged/tested your patches and they work fine.  I'm ok with '@' as the separator and this is a much cleaner (not to mention more portable and complete) patch than mine.  Thanks for

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

2018-11-02 Thread Sam Tannous
Hi Bart, I've merged/tested your patches and they work fine. I'm ok with '@' as the separator and this is a much cleaner (not to mention more portable and complete) patch than mine. Thanks for doing this. --Sam Tannous On Sun, Oct 28, 2018 at 5:19 PM Bart Van Assche wrote: > Hello, > > As