Re: [tor-relays] new VPS bridge bandwidth under-reported
I allowed the bridge bandwidth decay over a couple of days back to 8KBbyte, which seems to be the floor. "Fast" flag was dropped. After about a day that way, the bridge/relay daemon started running an occasional "bandwidth self-test", the rate went up to 60KB and the "fast" flag returned. Appears as though the self-check here is looking for a minimum level and not trying to push to maximum useable bandwidth, but this is only a casual observation. Six days in and no "stable" flag, but I'm hoping to see it in the next couple of days. At 05:57 1/5/2015 -0500, starlight.201...@binnacle.cx wrote: >Whoa wow. . . > >It just popped to 700KB, presumably because >I used it to browse and then download >the TBB bundle as a test. > >So I guess that means the bandwidth measurement >for a bridge is strictly passive? Presumably >that also means that it is not used as >a criteria for dissemination? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
That was my bug report, thanks for the quick turnaround on that one :3
My problem was that my infrastructure, including that tor exit node,
is puppetized. But a problem with that resulted in dhcp blitzing
/etc/resolv.conf and I kept putting in google dns out of sheer muscle
memory and I simply forgot to put it back.
It is pretty easy. This is the relevant configuration snippet from my
puppet manifest:
# setup internal DNS cache / resolver
include bind
bind::server::conf { '/etc/bind/named.conf':
directory => '/etc/bind',
listen_on_addr => [ 'any' ],
listen_on_v6_addr => [ 'any' ],
forwarders => [ '2001:4860:4860::8844',
'2001:1608:10:25::1c04:b12f', '2600::1' ],
allow_query => [ 'any' ],
statistics_file => '/etc/bind/named.stats',
recursion => 'yes',
extra_options => {
'forward' => 'only',
'auth-nxdomain' => 'no',
}
}
+ some other symlinks to account for the fact this isn't a RHEL box
like the module implicitly assumes.
I even have DNSSEC query validation setup, as the forwarders seem to support it.
Now I have named caching again. For those who are unclear, it helps a
LOT. From rndc stats:
++ Cache Statistics ++
[View: default]
53446329 cache hits
5246190 cache misses
15049168 cache hits (from query)
3044495 cache misses (from query)
The exit node in question sits between 10 and 20mb/s continuously, and
goes through a crazy amount of traffic. Something like 50T last month.
I even threw on a squid proxy on regular http and that's caching
something like 5-10% of all requests and overall http bandwidth.
Where it gets interesting is now that I've moved all of my DNS traffic
into a native ipv6 stack (outside of v4 local queries), I can say that
all the udp traffic I get is not legitimate/requested.
Which is looking to be a lot of traffic.
I got dinged with a nice udp DDoS the other day, and now its' even
more clear about what traffic is bad on tcpdump.
On Thu, Jan 8, 2015 at 9:04 AM, Nick Mathewson wrote:
> Hi, all!
>
> While looking into a bug report, I noticed that an exit node was using
> one of Google's well-known public DNS servers for its own DNS server.
>
> No disrespect to the operators of Google's fine public DNS service,
> but my sense is that using it for a Tor exit node might not be the
> greatest idea for users' privacy, having one DNS provider that gets to
> see so many requests. It's probably a better idea to have your own
> local cacheing DNS server.
>
> Would anybody like to share a guide about how to set one of those up
> safely and migrate correctly?
>
> best wishes,
> --
> Nick
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] badexit 03F84EA2E09CF427A519C65479DC0BF0D72886A6
router Tansam 79.143.87.234 443 0 0 03F84EA2E09CF427A519C65479DC0BF0D72886A6 Appears to be having trouble with, or is doing something with, http versions of https en.wikipedia.org articles. They're either blank or stripped of framework. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On Thu, 08 Jan 2015 08:38:35 -0800, Paul Syverson wrote: The flip side is that, against such an adversary, using a DNS server that supports encryption of queries and responses is probably more important than it being local. I like to chain unbound up to dnscrypt-proxy in order to encrypt DNS traffic for this very reason. dnscrypt-proxy frequently is unable to keep up however, so I currently have unbound configured to make queries directly if dnscrypt-proxy is not responding. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On Thu, Jan 08, 2015 at 10:04:35AM -0500, Nick Mathewson wrote: > Hi, all! > > While looking into a bug report, I noticed that an exit node was using > one of Google's well-known public DNS servers for its own DNS server. > > No disrespect to the operators of Google's fine public DNS service, > but my sense is that using it for a Tor exit node might not be the > greatest idea for users' privacy, having one DNS provider that gets to > see so many requests. It's probably a better idea to have your own > local cacheing DNS server. > > Would anybody like to share a guide about how to set one of those up > safely and migrate correctly? > I know people have already started to make specific suggestions and I don't intend to comment on those. But I wanted to say that in general there is another consideration: AS and other network level vulnerabilities. Obviously recursive resolution may send queries wherever, but using a local resolver should limit the network adversaries seeing exit DNS traffic. The flip side is that, against such an adversary, using a DNS server that supports encryption of queries and responses is probably more important than it being local. (At least until Tor starts choosing exits to minimize exposure to network adversaries on the destination link ;>) -Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On 01/08/2015 11:21 AM, Toralf Förster wrote: > On 01/08/2015 05:07 PM, Libertas wrote: >> And add 'nameserver 127.0.0.1' as the first line of your >> /etc/resolv.conf.tail > > Why not /etc/resolv.conf.head ?? > I was actually just looking into this, and it strangely seems that OpenBSD doesn't have one. You're right, too - as far as I know, if you're using DHCP (which is indeed an 'if' in the context of servers), the dynamic nameserver settings will override resolv.conf.tail's. That said, you can find dhclient.conf one-liners to set a permanent primary DNS server on IRC or your search engine of choice. I haven't tested any (and I don't need any, having a static IP), so I won't copy-and-paste any here. I also can't find any mention of resolv.conf.head in the OpenBSD source code, or any reason online for why it doesn't exist, so I may write a patch. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On 01/08/2015 05:07 PM, Libertas wrote: > And add 'nameserver 127.0.0.1' as the first line of your > /etc/resolv.conf.tail Why not /etc/resolv.conf.head ?? -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On 01/08/2015 10:11 AM, Peter Palfrader wrote: > ... > o remove all nameserver entries in /etc/resolv.conf and add one for the >local recursor. Either manually or use (untested): > sed -i -e 's/^nameserver /#&/; $a nameserver 127.0.0.1' /etc/resolv.conf > o prevent anything else from modifying that file ever again: >chattr +i /etc/resolv.conf > ... For what it's worth, most *nix OSs have files that are prepended and/or appended to /etc/resolv.conf, which are the intended way of doing this. They often come with corresponding man pages, too. OpenBSD has /etc/resolv.conf.tail, and Ubuntu has base, head, and tail in the /etc/resolvconf/resolv.conf.d directory. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On 01/08/2015 10:04 AM, Nick Mathewson wrote: > Hi, all! > > While looking into a bug report, I noticed that an exit node was using > one of Google's well-known public DNS servers for its own DNS server. > > No disrespect to the operators of Google's fine public DNS service, > but my sense is that using it for a Tor exit node might not be the > greatest idea for users' privacy, having one DNS provider that gets to > see so many requests. It's probably a better idea to have your own > local cacheing DNS server. > > Would anybody like to share a guide about how to set one of those up > safely and migrate correctly? > > best wishes, > -- > Nick > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > I actually just switched to unbound, which is included in the OpenBSD base system as of the most recent release. Aside from starting it, all you have to do is add the following to your /etc/rc.conf.local so that it starts up on boot: unbound_flags="" And add 'nameserver 127.0.0.1' as the first line of your /etc/resolv.conf.tail (and, for the time being, /etc/resolv.conf - see the man pages for details). I still have an OpenDNS server and a Google server listed below it in case something goes wrong with the local one. Here's Michael Lucas's guide, which includes information on how to test your DNS server, how to restrict access (although that seems to be default now), and how to set up DNSSEC in a minute or two: http://blather.michaelwlucas.com/archives/580 Ignore his installation instructions. They were written before it was included in the base system. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Why not use a private DNS server from opennicproject.org Am 08. Jänner 2015 15:11:09 WEZ, schrieb Peter Palfrader : >On Thu, 08 Jan 2015, Nick Mathewson wrote: > >> Would anybody like to share a guide about how to set one of those up >> safely and migrate correctly? > >o apt-get install unbound >o remove all nameserver entries in /etc/resolv.conf and add one for >the > local recursor. Either manually or use (untested): >sed -i -e 's/^nameserver /#&/; $a nameserver 127.0.0.1' >/etc/resolv.conf >o prevent anything else from modifying that file ever again: > chattr +i /etc/resolv.conf > >voila. > >-- > | .''`. ** Debian ** > Peter Palfrader | : :' : The universal > http://www.palfrader.org/ | `. `' Operating System > | `-http://www.debian.org/ >___ >tor-relays mailing list >tor-relays@lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays - -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On Thu, 08 Jan 2015, Nick Mathewson wrote: > Would anybody like to share a guide about how to set one of those up > safely and migrate correctly? o apt-get install unbound o remove all nameserver entries in /etc/resolv.conf and add one for the local recursor. Either manually or use (untested): sed -i -e 's/^nameserver /#&/; $a nameserver 127.0.0.1' /etc/resolv.conf o prevent anything else from modifying that file ever again: chattr +i /etc/resolv.conf voila. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
Hi, all! While looking into a bug report, I noticed that an exit node was using one of Google's well-known public DNS servers for its own DNS server. No disrespect to the operators of Google's fine public DNS service, but my sense is that using it for a Tor exit node might not be the greatest idea for users' privacy, having one DNS provider that gets to see so many requests. It's probably a better idea to have your own local cacheing DNS server. Would anybody like to share a guide about how to set one of those up safely and migrate correctly? best wishes, -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new VPS bridge bandwidth under-reported
starlight.201...@binnacle.cx transcribed 0.5K bytes: > Whoa wow. . . > Bridge relays conduct both bandwidth and reachability self-tests. (See §2.1.3 of torspec.git/path-spec.txt.) The Bridge then includes its self-measured bandwidth as the bandwidth-observed value on the "bandwidth" line of its (bridge-)server-descriptor, which it submits to the BridgeAuthority. (See §2.1.1 of torspec.git/dir-spec.txt.) The BridgeAuthority then (also) conducts a reachability test of the Bridge's ORPort, afterwards the BridgeAuthority takes the lesser value of the bandwidth-observed (as measured by the Bridge itself) and the bandwidth rate limit (as specified by the Bridge's operator in the Bridge's torrc) (§3.4.2 torspec.git/dir-spec.txt) to be the value for the "w" line in the bridge-networkstatus document (which is kind of like a mix between a microdescriptor-vonsensus and a consensus, except that it's really its own crazy document format, and it's only for Bridge relays). (To see examples of what these descriptors look like, see [0]) > It just popped to 700KB, presumably because I used it for to browse and then > download the TBB bundle as a test. I believe that client activity shouldn't effect your reported bandwidth (but I'm not entirely sure, actually). > So I guess that means the bandwidth measurement for a bridge is strictly > passive? Yes, currently there is only the Bridge's self-reported bandwidth. There is no infrastructure for authoritatively measuring any of the Bridges' bandwidths, however, I need this infrastructure, and its creation is currently being prioritised, so hopefully it will exist quite soon. :) > Presumably that also means that it is not used as a criteria for > dissemination? No, it is not used. Bridges may lie all they like about their bandwidths in their descriptors; in fact, a Bridge may lie about many things in its descriptors. However, BridgeDB is programmed, loosely speaking, to take certain descriptor information more or less seriously, depending on which information it is and which of the Bridge's descriptors it originated from. [0]: https://para.noid.cat/bridgedb/descriptors.html -- ♥Ⓐ isis agora lovecruft _ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] missing pluggable transport
Hi,
qq1693129601:
> When open tor-browser, it says
>
> Tor failed to establish a Tor network connection.
>
> Connecting to a relay directory failed (missing pluggable transport).
>
> The log is below, could anyone help?
it seems you might want to get in touch with our help desk via
h...@rt.torproject.org. The tor-relays list is the wrong mailing list
for this problem.
Georg
> -
> 01/06/2015 15:03:35.786 [NOTICE] DisableNetwork is set. Tor will not make
> or accept non-control network connections. Shutting down all existing
> connections.
> 01/06/2015 15:03:35.786 [NOTICE] Opening Socks listener on 127.0.0.1:9150
> 01/06/2015 15:03:36.711 [WARN] The communication stream of managed proxy
> './TorBrowser/Tor/PluggableTransports/fteproxy.bin' is 'closed'. Most
> probably the managed proxy stopped running. This might be a bug of the
> managed proxy, a bug of Tor, or a misconfiguration. Please enable logging
> on your managed proxy and check the logs for errors.
> 01/06/2015 15:03:36.711 [NOTICE] Failed to terminate process with PID
> '30230' ('Success').
> 01/06/2015 15:03:37.711 [NOTICE] Bootstrapped 5%: Connecting to directory
> server
> 01/06/2015 15:03:37.711 [WARN] We were supposed to connect to bridge
> '[2001:49f0:d002:1::2]:80' using pluggable transport 'fte', but we can't
> find a pluggable transport proxy supporting 'fte'. This can happen if you
> haven't provided a ClientTransportPlugin line, or if your pluggable
> transport proxy stopped running.
> 01/06/2015 15:03:37.712 [WARN] Problem bootstrapping. Stuck at 5%:
> Connecting to directory server. (Can't connect to bridge; PT_MISSING; count
> 1; recommendation warn)
> 01/06/2015 15:03:39.270 [WARN] We were supposed to connect to bridge
> '[2001:49f0:d00a:1::c]:80' using pluggable transport 'fte', but we can't
> find a pluggable transport proxy supporting 'fte'. This can happen if you
> haven't provided a ClientTransportPlugin line, or if your pluggable
> transport proxy stopped running.
> 01/06/2015 15:03:39.270 [WARN] Problem bootstrapping. Stuck at 5%:
> Connecting to directory server. (Can't connect to bridge; PT_MISSING; count
> 2; recommendation warn)
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
