View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005988 | GNUnet | topology daemon | public | 2019-12-07 18:19 | 2019-12-15 15:18 |
Reporter | Christian Grothoff | Assigned To | schanzen | ||
Priority | urgent | Severity | block | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
Product Version | Git master | ||||
Target Version | 0.12.0 | Fixed in Version | 0.12.0 | ||
Summary | 0005988: topology tests fail after crypto update | ||||
Description | Oddly enough, it is (now) _only_ the topology tests, and those fail with plenty of signature issues (outside peers involved???). Help with the investigation would be very welcome, I'm dealing with fallout in other areas right now. | ||||
Tags | No tags attached. | ||||
|
Well. On alpine the tests work for me: make test_gnunet_daemon_topology make[1]: Entering directory '/workbench/gnunet/src/topology' make[1]: 'test_gnunet_daemon_topology' is up to date. make[1]: Leaving directory '/workbench/gnunet/src/topology' make check-TESTS make[1]: Entering directory '/workbench/gnunet/src/topology' make[2]: Entering directory '/workbench/gnunet/src/topology' PASS: test_gnunet_daemon_topology ============================================================================ Testsuite summary for gnunet 0.11.8 ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ make[2]: Leaving directory '/workbench/gnunet/src/topology' make[1]: Leaving directory '/workbench/gnunet/src/topology' On macos the tests fail. But that is mostly due to the fact that testbed is a non-portable mess that is impossible to debug. Are you sure this this actually a new crypto issue? |
|
I don't know, maybe a new crypto issue that relates to stale files on my system from previous runs. Will do more testing. |
|
I tested on my fedora 30 VM where I can reproduce the bug. I get a testcase time, but I am not convinced that it is a crypto issue, yet. |
|
I am pretty sure the problem is the following: 1. Testbed does not really "connect" the peers. It needs the bootstrap peer (currently this is Y924) 2. No key is ever received from the "testbed" peers in the topology. I guess nobody every actually tested testbed w/o the bootstrap peer. The failure of Y924 due to protocol breakage @core now exposes this problem. Unfortunately, I think this is a bigger testbed issue... Maybe we should at some point scrap testbed and do this via external means? e.g. buildbot or other test-deployment strategies? (kubernetes comes to mind) |
|
Fixed in c20f5634b..1fc982c45 The problem was that the test tried to verify that each "testpeer" in the topology connected to at least 8 / 2 = 4 peers. This implicitly assumed that we are able to connect to the "real" network and find peers. I disabled bootstrapping from hostlist and reduced the threshold for the test to 1. I added a note in the test, if this is not what we want, we have to redesign/rewrite the test anyway. |
|
0.12.0 released |
Date Modified | Username | Field | Change |
---|---|---|---|
2019-12-07 18:19 | Christian Grothoff | New Issue | |
2019-12-07 18:19 | Christian Grothoff | Status | new => assigned |
2019-12-07 18:19 | Christian Grothoff | Assigned To | => schanzen |
2019-12-08 13:07 | schanzen | Note Added: 0015137 | |
2019-12-10 20:08 | Christian Grothoff | Note Added: 0015141 | |
2019-12-11 12:00 | schanzen | Note Added: 0015144 | |
2019-12-11 12:57 | schanzen | Note Added: 0015145 | |
2019-12-11 13:56 | schanzen | Status | assigned => resolved |
2019-12-11 13:56 | schanzen | Resolution | open => fixed |
2019-12-11 13:56 | schanzen | Fixed in Version | => 0.12.0 |
2019-12-11 13:56 | schanzen | Note Added: 0015146 | |
2019-12-15 15:18 | schanzen | Note Added: 0015167 | |
2019-12-15 15:18 | schanzen | Status | resolved => closed |