View Issue Details

IDProjectCategoryView StatusLast Update
0005578GNUnetARM servicepublic2019-02-28 11:17
ReporterschanzenAssigned Toschanzen 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product VersionSVN HEAD 
Target Version0.11.0Fixed in Version0.11.0 
Summary0005578: Arm tests fail on macos
Descriptionmake check in arm yields this.
Additional Information# TOTAL: 4
# PASS: 3
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0

============

Feb 16 19:24:18-899795 test-gnunet-service-arm-493 ERROR Failed to resolve our own hostname!
Feb 16 19:24:18-900282 test-gnunet-service-arm-493 ERROR Assertion failed at test_gnunet_service_arm.c:118.
Feb 16 19:24:18-902487 resolver-515 ERROR Assertion failed at gnunet-service-resolver.c:1249. Aborting.
Test failed with error code 3
FAIL test_gnunet_service_arm (exit status: 3)
TagsNo tags attached.

Activities

schanzen

2019-02-16 20:56

developer   ~0013829

This is a wierd issue and might be a bug. This test is skipped when I am on another network. Can somebody successfuly run this for me?

Christian Grothoff

2019-02-16 21:01

manager   ~0013830

I've fixed the assertion failure in gnunet-service-resolver.c, but that was on exit and should not affect the test itself :-(

Christian Grothoff

2019-02-16 21:02

manager   ~0013831

Try running gnunet-service-resolver from hand and then try to resolve your own hostname (via gnunet-resolve). If that doesn't work you know what to investigate...

Christian Grothoff

2019-02-16 21:03

manager   ~0013832

Oh, I should mention that the usual culprit is a difference in how name resolution is implemented between the host's libc (where it works) and our DNS lookup in util/.

schanzen

2019-02-16 21:44

developer   ~0013835

This was/is a problem with my local network.

ng0

2019-02-17 16:29

developer   ~0013844

test-gnunet-service-arm fails for me, on NetBSD.

host $(hostname) works without errors in a loop.

same error

schanzen

2019-02-17 20:24

developer   ~0013852

Tried a fix in fa7890cc5..5acfa2260.
I think the resolver if given "ANY" as record type resolved an A record and then, even if successful, also tries fo AAAA.
However, if the query for AAAA fails, it will just return with an empty response.

ng0

2019-02-22 22:50

developer  

test-suite.log (81,232 bytes)

ng0

2019-02-22 23:23

developer   ~0013951

in resolv.conf commented the ipv6 address which only exists for cable connection inside the internal network (my isp doesn't have working ipv6).

test-suite-2.log (78,114 bytes)

schanzen

2019-02-23 00:08

developer   ~0013953

Attempted fix in dda10ff31..e73b829fe

ng0

2019-02-23 00:31

developer   ~0013954

For the public record:

Fixing my /etc/hosts to match my /etc/myname "fixed" this test failure by circumventing the error.

Still needs to be fixed.

schanzen

2019-02-23 00:33

developer   ~0013955

We should add a note to the error message. Can you provide a new log of the tested version including my commit?

schanzen

2019-02-23 09:21

developer   ~0013957

Last edited: 2019-02-23 09:22

View 2 revisions

Without being able to confirm it, from the information ng0 has provided the problem is this:

If "gethostname" resolved to "myhostname", but the DNS query response contains a _different_ name than the one queried, the resolver fails to accept the response and it will never be found in the cache.
I tried fixing this with dda10ff31..e73b829fe.
However, the problem still remains for ng0 unless he adds his hostname to /etc/hosts, which circumvents the DNS resolution.

So, this bug is still open.

schanzen

2019-02-23 13:04

developer   ~0013958

I added this to 0.11 for now. Unless grothoff decides this is not relevant.

ng0

2019-02-24 00:46

developer   ~0013974

With gnunet from HEAD, with /etc/hosts no longer containing my hostname (just 'localhost'
and 'localhost.')

test-suite-3.log (77,813 bytes)

Christian Grothoff

2019-02-24 08:20

manager   ~0013978

I've just had the same issue on my travel notebook, so yes, this should be fixed somehow. But the central issue is that the intended behavior will be tricky in this case, as it seems that libc returns the IP address of the network interface (any one? default route? particular order?) if the given domain name matches the hostname. So teaching gnunet-service-resolver to check for 'hostname' and return say 127.0.0.1 or ::1 would NOT work. :-(

Easiest fix might be to not use hostname but 'www.gnu.org' for the test for now...

Any other opinions?

Christian Grothoff

2019-02-24 08:29

manager   ~0013979

Proposed fix pushed as a69123887..35df06d31

ng0

2019-02-24 10:33

developer   ~0013982

What about spoofing the replies by having a small dns server as part of the testsuite?

schanzen

2019-02-24 10:42

developer   ~0013989

Btw in my "fix" I changed the behaviour of the resolver a bit:

When the name "test" is resolved, but an A record for "test.lan" is returned, I store it in the cache under "test" as a result.
Before, we stored it under "test.lan" which meant that the result was not returned. I am not sure this is correct bahviour but this is how the host command also works it seems.

Christian Grothoff

2019-02-24 12:08

manager   ~0014002

i don't think including a DNS server for this is practical, the test ought to not be substantially larger than what we try to test here.

Christian Grothoff

2019-02-24 13:29

manager   ~0014004

schanzen: does the test pass right now? if so, please mark this issue as resolved.

schanzen

2019-02-24 16:30

developer   ~0014019

the issue was already working for me. ng0 still had the issue but solved it by adding his hostname to /etc/hosts.
Anyway, tests pass for me because what was tested before is no longer tested I assume? So closing

Issue History

Date Modified Username Field Change
2019-02-16 19:25 schanzen New Issue
2019-02-16 20:56 schanzen Note Added: 0013829
2019-02-16 20:56 schanzen Assigned To => Christian Grothoff
2019-02-16 20:56 schanzen Status new => assigned
2019-02-16 21:01 Christian Grothoff Note Added: 0013830
2019-02-16 21:02 Christian Grothoff Note Added: 0013831
2019-02-16 21:03 Christian Grothoff Note Added: 0013832
2019-02-16 21:44 schanzen Status assigned => resolved
2019-02-16 21:44 schanzen Resolution open => no change required
2019-02-16 21:44 schanzen Note Added: 0013835
2019-02-17 16:29 ng0 Status resolved => feedback
2019-02-17 16:29 ng0 Resolution no change required => reopened
2019-02-17 16:29 ng0 Note Added: 0013844
2019-02-17 19:33 Christian Grothoff Assigned To Christian Grothoff =>
2019-02-17 20:24 schanzen Note Added: 0013852
2019-02-17 20:24 schanzen Status feedback => new
2019-02-17 20:24 schanzen Status new => feedback
2019-02-22 22:50 ng0 File Added: test-suite.log
2019-02-22 23:23 ng0 File Added: test-suite-2.log
2019-02-22 23:23 ng0 Note Added: 0013951
2019-02-23 00:08 schanzen Note Added: 0013953
2019-02-23 00:08 schanzen Status feedback => new
2019-02-23 00:31 ng0 Note Added: 0013954
2019-02-23 00:33 schanzen Note Added: 0013955
2019-02-23 09:21 schanzen Note Added: 0013957
2019-02-23 09:22 schanzen Note Edited: 0013957 View Revisions
2019-02-23 11:07 schanzen Assigned To => schanzen
2019-02-23 11:07 schanzen Status new => feedback
2019-02-23 13:04 schanzen Product Version => SVN HEAD
2019-02-23 13:04 schanzen Target Version => 0.11.0
2019-02-23 13:04 schanzen Note Added: 0013958
2019-02-24 00:46 ng0 File Added: test-suite-3.log
2019-02-24 00:46 ng0 Note Added: 0013974
2019-02-24 08:20 Christian Grothoff Note Added: 0013978
2019-02-24 08:29 Christian Grothoff Note Added: 0013979
2019-02-24 10:33 ng0 Note Added: 0013982
2019-02-24 10:42 schanzen Note Added: 0013989
2019-02-24 12:08 Christian Grothoff Note Added: 0014002
2019-02-24 13:29 Christian Grothoff Note Added: 0014004
2019-02-24 16:30 schanzen Note Added: 0014019
2019-02-24 16:30 schanzen Status feedback => resolved
2019-02-24 16:30 schanzen Resolution reopened => fixed
2019-02-24 16:30 schanzen Fixed in Version => 0.11.0
2019-02-28 11:17 Christian Grothoff Status resolved => closed