[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9164 [Flashproxy]: Is Flashproxy pluggable transport really working? Tests, comments and questions
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs