Re: Unstable tests

2018-04-14 Thread Keith Mendoza 
Not ideal; but I guess it'll have to do for now.

On Sat, Apr 14, 2018, at 3:56 PM, Bart Van Assche wrote:
> On 04/05/18 16:38, Lee wrote:
> > On 4/5/18, Keith Mendoza  wrote:
> >> So again, at what point do we stop adding code to net-snmp because
> >> ISP's are messing around as if they're doing us a favor by letting us
> >> use their services?
> > 
> > Since people don't read the docs, how about adding a test to see if
> > dns is borked; if it is link to a faq entry for possible ways to fix
> > it.
> > 
> > verizon 'opt out of dns assistance' link:
> >
> > https://www.verizon.com/support/residential/internet/home-network/settings/opt-out-of-dns-assist
> 
> How about the patch below? With this patch applied Net-SNMP developers can
> make the tests pass easily by setting the NETSNMP_DNS_WORKAROUND environment
> variable before running the tests and normal operation of snmpd is not
> affected.
> 
> Thanks,
> 
> Bart.
> 
> 
> 
> Subject: [PATCH] snmplib: Avoid that test T070com2sec_simple fails due 
> to DNS filtering
> 
> ---
>  snmplib/system.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/snmplib/system.c b/snmplib/system.c
> index d7f06f74087f..28b832352247 100644
> --- a/snmplib/system.c
> +++ b/snmplib/system.c
> @@ -762,6 +762,24 @@ netsnmp_validator_context(void)
>  int
>  netsnmp_gethostbyname_v4(const char* name, in_addr_t *addr_out)
>  {
> +if (getenv("NETSNMP_DNS_WORKAROUND")) {
> +/*
> + * A hack that avoids that T070com2sec_simple fails due to the 
> DNS
> + * client filtering out 127.0.0.x addresses and/or redirecting 
> DNS
> + * resolution failures to a web page.
> + */
> +if (strcmp(name, "onea.net-snmp.org") == 0) {
> +*addr_out = htonl(INADDR_LOOPBACK);
> +return 0;
> +} else if (strcmp(name, "twoa.net-snmp.org") == 0) {
> +*addr_out = htonl(INADDR_LOOPBACK + 1);
> +return 0;
> +} else if (strcmp(name, "no.such.address.") == 0) {
> +return -1;
> +}
> +}
> +
> +{
>  #if HAVE_GETADDRINFO
>  struct addrinfo *addrs = NULL;
>  struct addrinfo hint;
> @@ -826,6 +844,7 @@ netsnmp_gethostbyname_v4(const char* name, in_addr_t 
> *addr_out)
>  #else /* HAVE_GETIPNODEBYNAME */
>  return -1;
>  #endif
> +}
>  }
>  
>  int
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Net-snmp-coders mailing list
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Re: Unstable tests

2018-04-14 Thread Bart Van Assche 
On 04/05/18 16:38, Lee wrote:
> On 4/5/18, Keith Mendoza  wrote:
>> So again, at what point do we stop adding code to net-snmp because
>> ISP's are messing around as if they're doing us a favor by letting us
>> use their services?
> 
> Since people don't read the docs, how about adding a test to see if
> dns is borked; if it is link to a faq entry for possible ways to fix
> it.
> 
> verizon 'opt out of dns assistance' link:
>
> https://www.verizon.com/support/residential/internet/home-network/settings/opt-out-of-dns-assist

How about the patch below? With this patch applied Net-SNMP developers can
make the tests pass easily by setting the NETSNMP_DNS_WORKAROUND environment
variable before running the tests and normal operation of snmpd is not
affected.

Thanks,

Bart.



Subject: [PATCH] snmplib: Avoid that test T070com2sec_simple fails due to DNS 
filtering

---
 snmplib/system.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/snmplib/system.c b/snmplib/system.c
index d7f06f74087f..28b832352247 100644
--- a/snmplib/system.c
+++ b/snmplib/system.c
@@ -762,6 +762,24 @@ netsnmp_validator_context(void)
 int
 netsnmp_gethostbyname_v4(const char* name, in_addr_t *addr_out)
 {
+if (getenv("NETSNMP_DNS_WORKAROUND")) {
+/*
+ * A hack that avoids that T070com2sec_simple fails due to the DNS
+ * client filtering out 127.0.0.x addresses and/or redirecting DNS
+ * resolution failures to a web page.
+ */
+if (strcmp(name, "onea.net-snmp.org") == 0) {
+*addr_out = htonl(INADDR_LOOPBACK);
+return 0;
+} else if (strcmp(name, "twoa.net-snmp.org") == 0) {
+*addr_out = htonl(INADDR_LOOPBACK + 1);
+return 0;
+} else if (strcmp(name, "no.such.address.") == 0) {
+return -1;
+}
+}
+
+{
 #if HAVE_GETADDRINFO
 struct addrinfo *addrs = NULL;
 struct addrinfo hint;
@@ -826,6 +844,7 @@ netsnmp_gethostbyname_v4(const char* name, in_addr_t 
*addr_out)
 #else /* HAVE_GETIPNODEBYNAME */
 return -1;
 #endif
+}
 }
 
 int


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Merge request processing

2018-04-14 Thread Keith Mendoza 
Net-SNMP devs,
After a few discussion in IRC, I feel that I have an understanding on why 
project leadership prefers patches over merge request. I would like to 
summarize them here to make sure that my understanding is correct. Patches are 
applied in the master and the current release's branch (at present this is 
v5.7-patch), and local/gittools/shell-functions makes sure that patches are 
applied to both branches, or removed it if the patch application fails in 
either branch. However, in another conversation over IRC I learned that in the 
past code submitted through merge request required significant rework that 
really can't be automated.

To me, SF's merge request mechanism not having an ability to view a diff of 
what's being submitted is frustrating. If I have to do a git fetch just so I 
can run git diff on the changes included in the merge request; I would go "f*** 
it" and just fix issues with the submitted code changes myself. Unfortunately, 
I feel that this is a disservice to the project team and the merge request 
submitter. Now someone just did extra work they didn't need to do, and the 
submitter doesn't have an opportunity to learn from their mistake.

If the team is willing to give merge requests another shot, this is the process 
that I would propose:

1. We instruct contributors what branch they should be using to make their 
changes based on what their code change is for. Bug fixes should go in current 
patch branch; new features go in master.

2. Review the merge request diff by running
git fetch git://git.code.sf.net/
git diff  

3. When all is well, run
git merge  

4. If we don't like what we see do our best to provide feedback to the 
submitter so they can redo their merge request. Unfortunately, SF doesn't 
provide a way to easily point out the lines of codes you found issues with that 
other software forges provides.

I hope this gets the ball rolling in helping streamline the patch 
submission/merge request process. Questions/comments appreciated.

-- 
Thanks,
Keith (pantherse)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders