View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005578||GNUnet||ARM service||public||2019-02-16 19:25||2019-02-28 11:17|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||SVN HEAD|
|Target Version||0.11.0||Fixed in Version||0.11.0|
|Summary||0005578: Arm tests fail on macos|
|Description||make 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)
|Tags||No tags attached.|
||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?|
||I've fixed the assertion failure in gnunet-service-resolver.c, but that was on exit and should not affect the test itself :-(|
||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...|
||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/.|
||This was/is a problem with my local network.|
test-gnunet-service-arm fails for me, on NetBSD.
host $(hostname) works without errors in a loop.
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.
test-suite.log (81,232 bytes)
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)
||Attempted fix in dda10ff31..e73b829fe|
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.
||We should add a note to the error message. Can you provide a new log of the tested version including my commit?|
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.
||I added this to 0.11 for now. Unless grothoff decides this is not relevant.|
With gnunet from HEAD, with /etc/hosts no longer containing my hostname (just 'localhost'
test-suite-3.log (77,813 bytes)
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?
||Proposed fix pushed as a69123887..35df06d31|
||What about spoofing the replies by having a small dns server as part of the testsuite?|
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.
||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.|
||schanzen: does the test pass right now? if so, please mark this issue as resolved.|
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
|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|