[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #10082 [Flashproxy]: flashproxy-client fails to communicate with connected browser proxies when logging is disabled

#10082: flashproxy-client fails to communicate with connected browser proxies when
logging is disabled
----------------------------+-------------------------------
     Reporter:  infinity0   |      Owner:  dcf
         Type:  defect      |     Status:  needs_information
     Priority:  major       |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:
       Points:              |
----------------------------+-------------------------------
Changes (by dcf):

 * status:  new => needs_information


Comment:

 That's interesting behavior. I can totally buy that some py2exe buffer is
 filling up as flashproxy-client writes to stderr but nothing reads it. Can
 you reproduce it without using the facilitator, with a proxy you operate
 yourself?

 I suggest that because what you describe is consistent with what happens
 when a flash proxy dies on you during bootstrapping. Using your own proxy
 may not create enough log messages to trigger the bug; so you could
 register manually after connecting with your own proxy (or just add some
 dummy logging, I guess).

 > 1 connections died in state handshaking (TLS) with SSLv2/v3 read server
 hello A in HANDSHAKE

 This message is consistent with a proxy dying during bootstrapping.
 Normally flashproxy-client would just switch to a different proxy and tor
 would try to reconnect. But it seems (and I haven't really investigated
 this) that Tor is more vulnerable to bridge failure during bootstrapping,
 and is less likely to try to reconnect to a bridge. That's not something I
 know for sure, just an impression I've gotten.

 The other thing I would try is using five `Bridge` lines as described in
 comment:5:ticket:7153. That might cause Tor to think that you actually
 have separate bridges, so the failure of one during bootstrapping wouldn't
 cause Tor to conclude that they are all down.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10082#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs