Tails

#8 Updated by intrigeri 2014-10-05 03:22:32

> I still have severe problems with Tor bootstrapping when using Tor 0.2.5.8-rc. E.g.
> when running the automated test suite for an experimental build, no feature that uses
> Tor succeeded completely for me.

> Am I the only one for whom it’s this bad?

I’ll give it a try. OTOH, it seems that you have missed my last email (Sept. 26) on this topic on tails-dev@, no?

#10 Updated by intrigeri 2014-10-06 06:50:45

Investigated this a bit, sent my results to -dev@. anonym, please have a look at my last email in the relevant thread.

#12 Updated by anonym 2014-10-07 05:27:04

intrigeri wrote:
> anonym wrote:
> > I still have severe problems with Tor bootstrapping when using Tor 0.2.5.8-rc. E.g. when running the automated test suite for an experimental build, no feature that uses Tor succeeded completely for me.
>
> I’ve just run the torified_browsing, torified_gnupg and apt features on a fresh build from experimental, and all succeeded right away on a pretty slow DSL connection. Maybe there was something wrong with your testing environment?

Interesting. I get very different results. I made the following custom feature and ran it in the automated test suite:

  Background:
    Given a computer
    And the network is unplugged
    And I start the computer
    And the computer boots Tails
    And I log in to a new session
    And GNOME has started
    And I save the state so the background can be restored next scenario

  Scenario: Tor can bootstrap and check if Tails has an update
    When the network is plugged
    And Tor is ready
    Then available upgrades have been checked

… with the above scenario repeated 20 times in total. My results were these:

• Tor 0.2.4.24: 20 scenarios (1 failed, 19 passed)

• Tor 0.2.5.8-rc: 20 scenarios (6 failed, 14 passed)

• Tor 0.2.5.8-rc and commits 3da8f6d..713da75 (i.e. fixes mentioned in Feature #7907#note-11): 20 scenarios (6 failed, 14 passed)

With 0.2.4.x I generally get no failures, so the 1/20 fail above may just be a statistical anomaly. In any case, the ~30% error rate with 0.2.5.8-rc is very consistent for me. So, sure, it could be something with my testing environment, or perhaps even my ISP, but still it’s something that some how is specific to 0.2.5.8-rc (or 0.2.5.x in general).

It would be interesting to do the test with an other ISP, but I won’t be able to do that until after the 1.2 RC has been prepared, most likely. In the meantime I’m gonna try some other stuff.

#13 Updated by intrigeri 2014-10-07 06:03:56

The automated test suite spams the control port with getinfo queries (see wait_until_tor_is_working), which we explictly avoid doing in our tor.sh shell library:

# Potential Tor bug: it seems like using this version makes Tor get
# stuck at "Bootstrapped 5%" quite often. Is Tor sensitive to opening
# control ports and/or issuing "getinfo status/bootstrap-phase" during
# early bootstrap? Because of this we fallback to greping the log.

It would be interesting to retry after replacing this control port spamming with log grepping.

#14 Updated by intrigeri 2014-10-07 06:44:25

I did the same tests with Tor 0.2.5.8-rc and commits 3da8f6d..713da75: 20 successes out of 20, and that’s with an upstream router that loses 90% of packets, and a short network outage in the middle of one of the Tor bootstraps.

#15 Updated by anonym 2014-10-07 09:27:57

anonym wrote:
> * Tor 0.2.5.8-rc and commits 3da8f6d..713da75 (i.e. fixes mentioned in Feature #7907#note-11): 20 scenarios (6 failed, 14 passed)

It turns out the image I tested didn’t actually have these commits. With a new experimental build, all I only got two failures out of 40 (I ran the feature twice, one failure in each), which is a huge improvement. Woo!

intrigeri wrote:
> The automated test suite spams the control port with getinfo queries (see wait_until_tor_is_working), which we explictly avoid doing in our tor.sh shell library:
> […]
> It would be interesting to retry after replacing this control port spamming with log grepping.

True, actually we should use the same in both, i.e.:

--- a/features/support/helpers/misc_helpers.rb
+++ b/features/support/helpers/misc_helpers.rb
@@ -46,8 +46,7 @@ end

 def wait_until_tor_is_working
   try_for(240) { @vm.execute(
-    '. /usr/local/lib/tails-shell-library/tor.sh; ' +
-    'tor_control_getinfo status/circuit-established').stdout  == "1\n" }
+    '. /usr/local/lib/tails-shell-library/tor.sh; tor_is_working').success? }
 end

 def convert_bytes_mod(unit)

#16 Updated by intrigeri 2014-10-08 01:31:35

> True, actually we should use the same in both, i.e.:

I’m testing this right now.

#17 Updated by intrigeri 2014-10-08 02:14:22

Works, after adding d3cae19 on top. Pushed.