Re: Unstable tests

2018-03-31 Thread Keith Mendoza 
I personally feel that whoever is running the automated tests should
make the necessary changes to their environment to resolve any
hostname that is needed to run the tests. In my case,
onea.net-snmp.org and twoa.net-snmp.org resolves to IP's in the
127.0.0.0/24 network; however no.such.address resolves to 92.242.140.2
which is an IP assigned to barefruit.co.uk. We now have a case of some
unscrupulous advertiser that "highly targeted traffic for ISPs by
replacing DNS and HTTP errors with relevant advertising" (that's from
their home page).

>From a software development and testing point-of-view I feel that we
will eventually get caught in expanding the number of hostnames that
will have to be handled by all the hostname resolution utility
functions in snmplib/system.c. I haven't had a chance to do a complete
analysis of how many each of the *gethostbyname* function variants are
used through the net-snmp code base; so, I'm not going to speak as to
whether these changes is limited to netsnmp_gethostbyname_v4(), or
should be applied elsewhere.

I understand full well the desire to make it as easy as possible for
as many users to be able to build, test, and deploy any open-source
software. However, I feel that the typical user's abilities should
also be considered. I feel that assuming that they can make the
necessary changes to their test environment to resolve a given set of
hostnames is a reasonable one.

Thanks,
Keith (pantherse)
Thanks,
Keith


On Sat, Mar 31, 2018 at 8:48 PM, Bart Van Assche  wrote:
> On 03/22/18 12:22, Eric S. Raymond wrote:
>>
>> Bart Van Assche :
>>>
>>> Hello Eric,
>>>
>>> These are the only two tests that sometimes fail on my test setup.
>>> Whether
>>> or not these tests pass depends on your DNS server. If I e.g. add
>>> "nameserver 8.8.8.8" as the first entry in /etc/resolv.conf then these
>>> tests
>>> pass on my setup. I think the reason is that the domain names used by
>>> that
>>> test resolve into 127.0.0.x and because some DNS servers filter these
>>> results.
>>>
>>> Bart.
>>
>>
>> You guys have been at this too long.  You're failing to document your
>> assumptions.
>>
>>> From 6cd949342a65ff2260253bca234bfa08f8e3b5c2 Mon Sep 17 00:00:00 2001
>>
>> From: "Eric S. Raymond" 
>> Date: Thu, 22 Mar 2018 15:20:21 -0400
>> Subject: [PATCH] INSTALL: explain workaround for comsec test failures.
>>
>> ---
>>   INSTALL | 11 +++
>>   1 file changed, 11 insertions(+)
>>
>> diff --git a/INSTALL b/INSTALL
>> index aad9099..9bcd65a 100644
>> --- a/INSTALL
>> +++ b/INSTALL
>> @@ -6,6 +6,7 @@ TABLE OF CONTENTS
>>   * Net-SNMP Specific Information
>> Long (but you should read these) Instructions
>> Installing the Perl/SNMP Module
>> +  Tests
>>   * Compilers and Options
>> Compiling For Multiple Architectures
>> Installation Names
>> @@ -155,6 +156,16 @@ Net-SNMP libraries and demon applications.
>>   make test
>>   make install (as root)
>>   +Tests
>> +=
>> +
>> +The ordinary self-test sequence can be invoked with "make test". There
>> +are more comprehensive options.
>> +
>> +Spurious failures on the "comsec" tests can be due to misconfigured
>> +DNS upstream of you. A workaround is to point your DNS server at a
>> +non-broken one. Adding "nameserver 8.8.8.8" as the first entry in
>> +/etc/resolv.conf will do.
>> Compilers and Options
>>   =
>
>
> How about the patch below? It makes test T070com2sec_simple pass on my
> setup.
>
> Thanks,
>
> Bart.
>
> ---
>  snmplib/system.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/snmplib/system.c b/snmplib/system.c
> index d7f06f74087f..c9dbea344f71 100644
> --- a/snmplib/system.c
> +++ b/snmplib/system.c
> @@ -762,6 +762,19 @@ netsnmp_validator_context(void)
>  int
>  netsnmp_gethostbyname_v4(const char* name, in_addr_t *addr_out)
>  {
> +/*
> + * A hack that avoids that T070com2sec_simple fails due to the DNS
> + * client filtering out 127.0.0.x addresses.
> + */
> +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;
> +}
> +
> +{
>  #if HAVE_GETADDRINFO
>  struct addrinfo *addrs = NULL;
>  struct addrinfo hint;
> @@ -826,6 +839,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
>

Re: Unstable tests

2018-03-31 Thread Bart Van Assche 

On 03/22/18 12:22, Eric S. Raymond wrote:

Bart Van Assche :

Hello Eric,

These are the only two tests that sometimes fail on my test setup. Whether
or not these tests pass depends on your DNS server. If I e.g. add
"nameserver 8.8.8.8" as the first entry in /etc/resolv.conf then these tests
pass on my setup. I think the reason is that the domain names used by that
test resolve into 127.0.0.x and because some DNS servers filter these
results.

Bart.


You guys have been at this too long.  You're failing to document your
assumptions.


From 6cd949342a65ff2260253bca234bfa08f8e3b5c2 Mon Sep 17 00:00:00 2001

From: "Eric S. Raymond" 
Date: Thu, 22 Mar 2018 15:20:21 -0400
Subject: [PATCH] INSTALL: explain workaround for comsec test failures.

---
  INSTALL | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/INSTALL b/INSTALL
index aad9099..9bcd65a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -6,6 +6,7 @@ TABLE OF CONTENTS
  * Net-SNMP Specific Information
Long (but you should read these) Instructions
Installing the Perl/SNMP Module
+  Tests
  * Compilers and Options
Compiling For Multiple Architectures
Installation Names
@@ -155,6 +156,16 @@ Net-SNMP libraries and demon applications.
  make test
  make install (as root)
  
+Tests

+=
+
+The ordinary self-test sequence can be invoked with "make test". There
+are more comprehensive options.
+
+Spurious failures on the "comsec" tests can be due to misconfigured
+DNS upstream of you. A workaround is to point your DNS server at a
+non-broken one. Adding "nameserver 8.8.8.8" as the first entry in
+/etc/resolv.conf will do.
  
  Compilers and Options

  =


How about the patch below? It makes test T070com2sec_simple pass on my
setup.

Thanks,

Bart.

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

diff --git a/snmplib/system.c b/snmplib/system.c
index d7f06f74087f..c9dbea344f71 100644
--- a/snmplib/system.c
+++ b/snmplib/system.c
@@ -762,6 +762,19 @@ netsnmp_validator_context(void)
 int
 netsnmp_gethostbyname_v4(const char* name, in_addr_t *addr_out)
 {
+/*
+ * A hack that avoids that T070com2sec_simple fails due to the DNS
+ * client filtering out 127.0.0.x addresses.
+ */
+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;
+}
+
+{
 #if HAVE_GETADDRINFO
 struct addrinfo *addrs = NULL;
 struct addrinfo hint;
@@ -826,6 +839,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

Re: Some bugs that need closing

2018-03-31 Thread Bill Fenner 
On Wed, Mar 28, 2018 at 1:09 PM, Ian Bruene  wrote:

>
> Trawling through the bugtracker I found a number of bugs - some reaching
> back to 2002 - which have either been fixed, or from the explanations in
> the comments need to be listed as WONTFIX. This is obviously not a complete
> list, but it is what I found after maybe half an hour of looking: if I
> found this many in that amount of time then the 650 "open" bug count is
> probably a considerably lower number with a metric ton of detritus mixed
> in. This is not conducive to finding and nailing the real bugs.
>
> The list:
>
> #2823 Is fixed.
>

This was the one that you later mentioned on irc, and the formatting misled
you into thinking that it was fixed but it isn't?

#2513 Appears to be a misunderstanding of the logging system and as such a
> WONTFIX.
>

I've closed this one.

#414 Has a pseudo-patch associated with it. Looking at the code it does not
> appear that it was ever applied. However the bug involves 32/64-bit issues
> and dates from all the way back in 2003, so it may have been solved in
> other ways. I don't run sunos so I can't tell myself.
>

Yeah, the code was completely restructured since then, so I've closed it.

#518 was Apple's fault even if it still exists.
>

Well, we like to figure out portability problems, but, the bug is so old
that it's not worth chasing.

#648 is about a precompiled binary. It appears to be mostly the asker
> wondering if they should compile themselves.
>

Not the #648 that's at https://sourceforge.net/p/net-snmp/bugs/648/ - but
it's closable for other reasons.  Do you know what bug you were trying to
refer to here?

#759 is a duplicate of #414
>

Closed as such.

#814 "Not a bug."
>

Closed as such.

Thanks!
  Bill
--
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