[tor-bugs] #9164 [Flashproxy]: Is Flashproxy pluggable transport really working? Tests, comments and questions

[Tor Bug Tracker & Wiki]

#9164: Is Flashproxy pluggable transport really working? Tests, comments and
questions
---------------------------+------------------------------------------------
    Reporter:  Aymeric     |       Owner:  dcf   
        Type:  defect      |      Status:  closed
    Priority:  normal      |   Milestone:        
   Component:  Flashproxy  |     Version:        
  Resolution:  duplicate   |    Keywords:        
      Parent:              |      Points:        
Actualpoints:              |  
---------------------------+------------------------------------------------
Changes (by dcf):

  * status:  new => closed
  * resolution:  => duplicate


Comment:

 Replying to [comment:1 arlolra]:
 > This wasn't necessary. The embed code can accept querystring parameters,
 > {{{
 >
 embed.html?facilitator_poll_interval=10&initial_facilitator_poll_interval=10&debug=1
 > }}}

 But ''please don't'' override `facilitator_poll_interval`. Set up your own
 test network if you must use such aggressive parameters. The facilitator
 does not yet protect itself against proxies polling so frequently; that's
 #7823. If you are debugging connections, don't use the public facilitator.
 Use the `client` and `relay` query string parameters instead.

 This is a duplicate to #9008. Unfortunately, most of the connections you
 get are likely to fail. It's nothing to worry about.

 It's not surprising that a later WebSocket connection fails when it worked
 before. That just means they closed their Tor Browser Bundle and
 flashproxy-client is no longer listening.

 Aymeric, please don't post flashproxy.js debug files that contain client
 IP addresses.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9164#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online