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 #i

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

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 ve

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

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 sp

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

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

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 t

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

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

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

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 deli

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

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 at

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

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 specify

Re: [net-snmp:code] 4 new commits to Code

On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository < nore...@code.net-snmp.p.re.sourceforge.net> wrote: > Branch: V5-8-patches > > configure: Determine endianness at compile time instead of at configure > time > > The new test supports cross-compilation. In other words, --with-endianness > no

Re: [net-snmp:code] 4 new commits to Code

On Mon, Apr 29, 2019 at 7:10 PM Bart Van Assche wrote: > On Mon, 2019-04-29 at 17:19 -0400, Bill Fenner wrote: > > On Sun, Apr 28, 2019 at 7:52 PM net-snmp Git repository < > nore...@code.net-snmp.p.re.sourceforge.net> wrote: > > Branch: V5-8-patches > > configure: Determine endianness at compile

Re: [net-snmp:code] 4 new commits to Code

On Tue, May 7, 2019 at 7:41 PM Bart Van Assche wrote: > On 5/7/19 9:42 AM, Bill Fenner wrote: > > I was hoping you might have an idea of a more graceful solution that > > allows keeping const'ness. If not, I can check in my change. > > Hi Bill, > > Please have a look at commit 068b4686739c ("lib

Re: [net-snmp:code] 2 new commits to Code

There's a long history of telling people "You're polling a Linux system, you have to know that you subtract buffers and cached from physical before you report free memory" in the HOST-RESOURCES-MIB. I'm not against simplifying, but - if people have data collection set up for "the old way", where y

Re: [net-snmp:code] 2 new commits to Code

B: Account reclaimable > space")? > I'm fine with 4e3ace87b566 ("NET-SNMP-SYSTEM-MIB: Account reclaimable space"). It's change a88d81f1144e ("NET-SNMP-SYSTEM-MIB, Linux: Update calculation of free space") that I'm concerned about, that changes the long-st

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository < nore...@code.net-snmp.p.re.sourceforge.net> wrote: > Branch: V5-8-patches > > treewide: Terminate netsnmp_feature_*() uses with a semicolon > > This patch has been generated by the following shell command: > > git grep -l netsnmp_feature_

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner wrote: > On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository < > nore...@code.net-snmp.p.re.sourceforge.net> wrote: > >> Branch: V5-8-patches >> >> treewide: Terminate netsnmp_feature_*() uses with a semicolon >> >> This patch has been generated b

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On Mon, Aug 26, 2019 at 12:34 PM Bill Fenner wrote: > On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner > wrote: > >> On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository < >> nore...@code.net-snmp.p.re.sourceforge.net> wrote: >> >>> Branch: V5-8-patches >>> >>> treewide: Terminate netsnmp_featur

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On Mon, Aug 26, 2019 at 4:51 PM Bart Van Assche wrote: > On 8/26/19 12:59 PM, Bill Fenner wrote: > > Just as a personal preference, I like to use "awk" instead of grep|... - > > "awk '/NSF_WW/ {print $1}' $tmpf" gives the same result and doesn't care > > about the presence or absence of the semic

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On Mon, Aug 26, 2019 at 11:48 AM Bill Fenner wrote: > On Tue, Aug 13, 2019 at 11:17 PM net-snmp Git repository < > nore...@code.net-snmp.p.re.sourceforge.net> wrote: > >> Branch: V5-8-patches >> >> treewide: Terminate netsnmp_feature_*() uses with a semicolon >> >> This patch has been generated b

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

It turns out a typo in the .travis.yml did not export the environment variables to the build script. Looks like MODE=minimalist and MODE=read-only are both broken as-is: https://travis-ci.org/fenner/net-snmp/builds/577056671 Bill ___ Net-snmp-coders m

Re: [net-snmp:code] treewide: Terminate netsnmp_feature_*() uses with a semicolon

On Tue, Aug 27, 2019 at 11:11 PM Bart Van Assche wrote: > On 8/26/19 3:12 PM, Bill Fenner wrote: > > It turns out a typo in the .travis.yml did not export the environment > > variables to the build script. Looks like MODE=minimalist and > > MODE=read-only are both broken as-is: > > https://travi