View Issue Details

IDProjectCategoryView StatusLast Update
0005988GNUnettopology daemonpublic2019-12-15 15:18
ReporterChristian GrothoffAssigned Toschanzen 
PriorityurgentSeverityblockReproducibilityalways
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.12.0Fixed in Version0.12.0 
Summary0005988: topology tests fail after crypto update
DescriptionOddly 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.
TagsNo tags attached.

Activities

schanzen

2019-12-08 13:07

manager   ~0015137

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?

Christian Grothoff

2019-12-10 20:08

manager   ~0015141

I don't know, maybe a new crypto issue that relates to stale files on my system from previous runs. Will do more testing.

schanzen

2019-12-11 12:00

manager   ~0015144

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.

schanzen

2019-12-11 12:57

manager   ~0015145

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)

schanzen

2019-12-11 13:56

manager   ~0015146

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.

schanzen

2019-12-15 15:18

manager   ~0015167

0.12.0 released

Issue History

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