Integration tests sometimes fail on server connections / Add WaitForAuthenticated() check on PeerServerConnections() #132

New Issue

sarah · 2018-10-04T19:41:55Z

sarah commented

2018-10-04 19:41:55 +00:00

Our integration test is a little flaky on server connection joins, needs to be using WaitForAuthenticated() construct

sarah commented

2018-10-10 05:12:53 +00:00

Adding to this. They have started to timeout. We definitely need to upgrade the tor version on the OpenPriv Cwtch instance (see Erinns PR on this) and implement a better Connection State check in the integ tests.

A mix of both should drastically speed up these tests.

Adding to this. They have started to timeout. We definitely need to upgrade the tor version on the OpenPriv Cwtch instance (see Erinns PR on this) and implement a better Connection State check in the integ tests. A mix of both should drastically speed up these tests.

dan commented

2018-10-10 06:27:42 +00:00

it's using the tor 0.3.3.7 version for x86 I statically built and put in buildfiles
https://git.openprivacy.ca/openprivacy/buildfiles/src/master/bin

What version we want?

(oooh right, if its not like 0.3.4 does it just silently fail like I was having on friday?)

it's using the tor 0.3.3.7 version for x86 I statically built and put in buildfiles https://git.openprivacy.ca/openprivacy/buildfiles/src/master/bin What version we want? (oooh right, if its not like 0.3.4 does it just silently fail like I was having on friday?)

sarah commented

2018-10-10 16:47:24 +00:00

Less than 0.3.5.2 will cause successive listens to struggle - if we are constantly crashing/restarting because of #136 that could compound it

solution: the best solution for this is to upgrade to tor >= 0.3.5.1 (which at the time of writing is an alpha so you'll have to build 0.3.5.2 yourself, unfortunately). 0.3.5.1 introduces stateless revision counters: the revision counter for a new service descriptor is an order-preserving encryption of the seconds since the last SRV was issued, so descriptors created later always take precedence (assuming clocks are set approximately correctly). (nb: the OPE is to prevent leaking your clock skew by sending the elapsed time directly)

Less than 0.3.5.2 will cause successive listens to struggle - if we are constantly crashing/restarting because of #136 that could compound it `solution: the best solution for this is to upgrade to tor >= 0.3.5.1 (which at the time of writing is an alpha so you'll have to build 0.3.5.2 yourself, unfortunately). 0.3.5.1 introduces stateless revision counters: the revision counter for a new service descriptor is an order-preserving encryption of the seconds since the last SRV was issued, so descriptors created later always take precedence (assuming clocks are set approximately correctly). (nb: the OPE is to prevent leaking your clock skew by sending the elapsed time directly)`

sarah commented

2019-01-21 18:51:36 +00:00

I haven't seen this for a while, assuming that upgrading tor fixed the integ connection issues.

sarah closed this issue

2019-01-21 18:51:36 +00:00

Sign in to join this conversation.