[tor-dev] Flashproxy alpha bundles

[Alexandre]

The "scary console" mentioned in the test report is probably
because of the console=true option in the pyinstaller
spec file. I'll have a look and confirm.

Alex

On 2012-12-13, at 7:01 PM, David Fifield <david at bamsoftware.com> wrote:

> Thank you for testing! This report is very helpful.
> 
> On Thu, Dec 13, 2012 at 07:59:31PM +0100, Sebastian G. <bastik.tor> wrote:
>>> - If it didn't work, was it at least clear what was wrong?
>> 
>> I thought the progress would have stopped here, but it just took much
>> longer than expected.
>> 
>> [Notice] Bootstrapped 50%: Loading relay descriptors.
>> 
>> Starting TBB again, reduces the time.
>> 
>> Might be the proxy that is in use, because on retrying again, I "stuck"
>> at 85% or 90%.
> 
> That is interesting. I have often seen Tor stall at 50%. During that
> time there is no network traffic for about 60 seconds, so it's not just
> that downloading descriptors is slow. After about 60 seconds, it starts
> downloading descriptors. I haven't figured out why.
> 
> Stalling at 85% might mean that you got only one proxy, when two are
> required to bootstrap, recently and for yet-unknown reasons.
> https://lists.torproject.org/pipermail/tor-dev/2012-December/004260.html
> If you go into the bundle and run the flashproxy-reg-email or
> flashproxy-reg-http program, that should be enough to get you more
> proxies without restarting Vidalia.
> 
> You can get better debugging information by adding something like
> 	--log flashproxy.txt
> to the ClientTransportPlugin line in torrc.
> 
>>> - Were you able to use this as your main Tor process for a day?
>> 
>> Browsing is slower (due to the proxies in use I assume), but aside from
>> that I could use it to get the information I require.
> 
> It's slower for at least three reasons. One is that you're extending the
> network path of the circuit (three Tor hops and one flash proxy hop).
> Another is that the websocket bridge relay isn't particularly fast.
> Another is that some browsers (only Firefox 10 at this point I think)
> don't support binary WebSocket frames and we use base64-encoded text
> frames for them instead.
> 
>> It's an alpha bundle, but I did not expect it to dump everything where
>> the executable was. (Tor Browser\) I thought I would be able to select
>> where to extract.
>> 
>> I also saw a, to some maybe scary, console. Might be alpha stuff.
> 
> Oh, thank you. This is good to know. Probably I created the
> self-extracting executable in a different way than the official bundles.
> (BTW the procedure for making the Windows bundle is here:
> https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/bundle-windows.txt.)
> 
> David Fifield
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev