Feature #10686

Network disconnection shouldn't make download fail in DAVE

Added by sajolida 2015-11-27 09:32:38 . Updated 2016-08-25 07:50:06 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Installation
Target version:
Tails_2.6
Start date:
2015-11-27
Due date:
% Done:

70%

Feature Branch:
Type of work:
Communicate
Blueprint:

Starter:
Affected tool:
ISO Verification Extension
Deliverable for:

Description

Currently, when using DAVE in Tails, disconnecting and reconnection the network DAVE goes into verifying the incomplete download and fails.

See the screencast:

https://un.poivron.org/~sajolida/dave/disconnect.ogv

Subtasks

History

#1 Updated by sajolida 2015-11-30 11:21:38

  • Priority changed from Normal to Elevated

This breaks downloads so marking this as elevated for the beta.

#2 Updated by ma1 2015-12-01 04:24:01

I couldn’t reproduce outside Tails, could you?
It just fails and I get the “Failed” message and the “Retry” button, using which I can complete the download & verification successfully.

Still have to try on Tails, should I assume it’s a Tails-specific bug?

#3 Updated by ma1 2015-12-03 15:33:34

  • QA Check set to Info Needed

I could confirm it is a Firefox bug specific to Tails: the download manager reports the download as “succeeded” on reconnection because of an unhandled exception in the management of the underlying network channel, therefore it cannot be resumed because it’s considered “completed”.
Tested on Tor Browser and Firefox, could not reproduce neither on Ubuntu nor Windows (I didn’t have a chance to check on Mac OS X).
The only work-around which doesn’t involve investigating and fixing the bug in Mozilla’s codebase (quite unlikely, at least in an acceptable time-frame) is detecting this abnormal condition and automatically restarting the download, rather than resuming it, upon reconnection.
Is this acceptable?

#4 Updated by sajolida 2015-12-05 06:02:50

  • Assignee changed from ma1 to anonym

Thanks for investigating all this. I’m glad it’s specific to Tails. I guess it’s due to the fact that we’re stopping and starting Tor on network reconnection. I know this part Tails is very complex, so I’d like to reassign this to anonym for more info.

Until, then I guess that yes, restarting the download is acceptable.

anonym: why are we doing this hard restart on Tor when (re)connecting? is our usecase worth trying to modify this behavior?

#5 Updated by intrigeri 2015-12-05 10:24:26

  • Assignee changed from anonym to sajolida

> anonym: why are we doing this hard restart on Tor when (re)connecting?

IIRC:
https://trac.torproject.org/projects/tor/ticket/8766
and https://trac.torproject.org/projects/tor/ticket/1247

#6 Updated by sajolida 2015-12-07 08:04:37

  • Assignee changed from sajolida to anonym

#7 Updated by intrigeri 2015-12-07 12:54:05

ma1 wrote:
> I could confirm it is a Firefox bug specific to Tails: the download manager reports the download as “succeeded” on reconnection because of an unhandled exception in the management of the underlying network channel, therefore it cannot be resumed because it’s considered “completed”.

My understanding is that the only behaviour that’s “specific to Tails” here is: the browser loses connection to its configured proxy (in our case: because the proxy restarts in a way that drops client connections). Strictly speaking this is not specific to Tails, is it? It might be a rare event outside of Tails, but really I’ve no idea since I’m not familiar with (e.g. corporate) settings where SOCKS or HTTP proxies are the norm.

(I don’t have the assistant / extension big picture in mind so I won’t try to assess how important this problem is.)

#8 Updated by ma1 2015-12-09 06:26:53

  • Assignee changed from anonym to ma1

As I said, this is mainly a Firefox download manager bug.
I’ve recently talked face to face with with Paolo Amadini (pamadini@mozilla.com), the Mozilla guy who wrote the code, and I’m putting him into the loop to better understand whether a fix or work-around is feasible in a near future.

#9 Updated by sajolida 2015-12-11 04:24:47

So I still think that we should:

1. Stick with what Giorio proposed as a workaround for the first releases, which is “automatically restarting the download, rather than resuming it”.
2. Investigate, whenever anonym has more time, whether it would be easy to have our Network-Manager hooks prevent this from happening, as a better workaround which would allow us to prevent the Firefox bug from happening in Tails.
3. Work on solving this bug upstream in Firefox. I don’t think we should consider solving it as part of the DAVE deliverable but maybe at least reporting it and providing enough info for the Firefox upstream to triage it.

So, Giorgio, is there already a Firefox bug reported upstream? If so where can we track it? Otherwise, could you report it?

#10 Updated by sajolida 2015-12-17 09:26:19

  • Target version changed from Tails_1.8 to Tails_2.0

#11 Updated by sajolida 2016-01-05 17:48:12

#12 Updated by ma1 2016-01-10 01:06:22

  • Assignee changed from ma1 to sajolida
  • QA Check changed from Info Needed to Ready for QA

The proposed work-around is implemented in 0.2.7rc15, in AMO’s beta channel and on ma1’s git.
Not reported yet on Mozilla’s bugzilla because I’d like to produce a test-case which doesn’t depend on the Tor Browser or at least spots the buggy Firefox code exactly. I’ll try to do it before the end of this month (I might even end to fix it myself, since I’m currently working with Mozilla on other upstream features).

#13 Updated by sajolida 2016-01-15 14:52:18

  • Assignee changed from sajolida to ma1
  • Target version deleted (Tails_2.0)
  • QA Check deleted (Ready for QA)
  • Type of work changed from Code to Communicate

The workaround on Tails seems to work. So I’m removing the dependency to 2.0 and Feature #8592 (the official release) but keeping this open until the bug is tracked upstream.

#14 Updated by sajolida 2016-01-29 18:17:12

#15 Updated by sajolida 2016-04-01 10:38:31

  • blocks #8538 added

#16 Updated by sajolida 2016-04-01 11:02:12

  • Priority changed from Elevated to Normal

#17 Updated by ma1 2016-07-19 13:36:26

  • Target version set to Tails_2.5
  • % Done changed from 0 to 100
  • QA Check set to Ready for QA

sajolida wrote:
> The workaround on Tails seems to work. So I’m removing the dependency to 2.0 and Feature #8592 (the official release) but keeping this open until the bug is tracked upstream.

Tracked upstream here: https://bugzilla.mozilla.org/show_bug.cgi?id=1287920

#18 Updated by intrigeri 2016-07-19 15:05:14

  • Assignee changed from ma1 to sajolida
  • % Done changed from 100 to 70

#19 Updated by intrigeri 2016-08-02 09:31:56

  • Target version changed from Tails_2.5 to Tails_2.6

#20 Updated by sajolida 2016-08-25 07:50:06

  • Status changed from Confirmed to Resolved
  • Assignee deleted (sajolida)
  • QA Check deleted (Ready for QA)

Cool!