- tor-relays - lists.torproject.org

Re: [tor-relays] Anonbox Project
by Torzilla 15 Oct '14

15 Oct '14

I have seen their website and it looks like someone is trying to sell this product though I didn't see a price tag yet. Looks dangerous. Possibly a honeypot. Thanks, Torzilla11 Sent from my Sony Xperia™ smartphone Thomas White <thomaswhite(a)riseup.net> wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Well the topic has come up several times in the last day or two on IRC >and generally the feeling is that it may be quite bad for the users of >the product, not necessarily the Tor network however. > >One thing that AnonBox does do is increase Tor network traffic - you >can see this as both good and bad since it adds load to exit operators >like myself which are already in short supply and diversity, but at >the same time adding traffic to the network makes it safer to use for >everyone. > >The real concern is the mismarketing and borderline fraud occuring by >assuming the simple use of a protocol or open source software (which I >note, the hardware is not actually open source at all). In addition, >the users of such a system are going to be leaving an enormous browser >fingerprint and their activities will be correlated so expectation of >reasonable privacy from this project is a misguided hope at best; at >worst very dangerous to life and limb of anyone who relies on Tor for >their life. > >I am personally hoping somebody high up in the Tor Project management >will openly condemn this atrocity and hopefully Kickstarter and the >funders will withdraw their funds before a whole load of people buy >into this "security as a tool" idea. > >- -T > >On 15/10/2014 12:15, Sven Reissmann wrote: >> Hi there, >> >> I recently read about the anonbox project [1], a small >> hardware-router, which allows end-users to connect their whole LAN >> to the Tor network. The project is on kickstarter at the moment >> [2]. >> >> Has there already been a discussion on how this might affect the >> performance of the Tor network? >> >> Regards, Sven. >> >> >> [1] http://anonabox.com [2] >> https://www.kickstarter.com/projects/augustgermar/anonabox-a-tor-hardware-r… >> >> >> >> >> _______________________________________________ tor-relays mailing >> list tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v2.0.22 (MingW32) > >iQIcBAEBAgAGBQJUPmHuAAoJEE2uQiaesOsLAOMP/j8BHqO2yIHRV8Q7Ja3aYHrv >ppLrDbjvbkV9paqGR4X8Gz71PJyHXZoOse6JfBxOnZG+mmoS9elYoXDkKoz8y5Z3 >ot/cpoQdKLei+LvmRxQ5VHcwDXx6wb35+o7I5FnvMoyH2YTeqyfAmGnb5X7D3oa7 >H5rYF8n17ttfvqHvFt2tRuZKKyskJWRnjnpkmmAJSeZpmZnRf38JGhdknmoPMXg3 >5hwzh7E9xFSMM5NrCpXDYvRdZJMvQPWdDFOVUZvKMh/magJitfBZ2Lr7cpq2Vpep >bU8Xs4z/a92j+bm3lN1jzUEgoxs7BEtn/bG2ASRJp2BufOFW8+FCTuOJQPVV0iSa >BPtjoNGe1cwBin256ODF3GjcuzS0Vbql0oS3HyYyEgYEnDjXcw05sdd9tg9i1lqk >66M8h9/aQvZZX1qB4EPzweOYM10VX7mS2pGGl+00wGkGZvhZ4k5ixP/8kHQ7OqQh >d6lwg/ZWK+6wYx3ADCKCvfD5pCNMlf4AtWgam3eQpSPw1uJuw3/twKEvuQijfhRM >XyNu3GivErIpL1d9awm0tJdqcZYZsKw/RFKN9leHt8PhYTMcSp+MViPuFaPIcYh0 >CHwj36gQTqB3XxzdnyJyzigwQhpWePs+qcmc4S3mTq8ogZsnBMgS080XocOx1Jrp >zqZfg7sOGY+s3018nntK >=SX0h >-----END PGP SIGNATURE----- >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

GoodBadISPs revamp?
by subkeys＠riseup.net 14 Oct '14

14 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [cross-posted on tor-talk and tor-relays] i've found that the Tor GoodBadISPs list [1] is somewhat outdated on current hosts that allow Tor (exit) relays to be hosted. i'm trying to find a cheap host that allows exits to be operated from their services, and navigating the outdated list and finding an operator that isn't extremely expensive is time consuming (some entries go back to 2010!). should the community start a revamp project (or start a whole new list)? i'd be willing to donate my time to help get this started if need be. thanks. - ---- mikael ball 0xB1910271AE8587F4 @subkeys [1]: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUOyMfAAoJELGRAnGuhYf0BKIP/jW0D+wgMOMrYlFQ9k46fHTK g57tkqp6SAKPL/us6Zgf1tG3XIxUGcsQXTt9xrRwgpBAC1iEJtQcBGVutd6hCtYn s3ByxR1fhHa7LglDISueiDTsSx7/cu0cGykKbT7xxGSBLXint0tVxyis/GAznIue MoIlwCoFBO6rHsDU+aPyfLk0SjpYaDZ2tI3PKVplWO/NCW7UHiDeMONPfTXQxVQQ XYSl7Mp2AhmdatpU2a7ACXi1qWibFRlJqVji/Hp3wVpDYxGGIGxP1RG7vR+JvoqU wZ0g0s9JTRpNpjKfLlHGs8ZxF1XXFGXkpqYR9Ka1lAvkD50EFHbQshMKD6exGnfY xyNrEaleCTB+w3ww4YMPqRCzd3J5a/6+xdncBEitV5YzKh15aYD4VJk0/vlFVbED 950Zsh+6n242fwCAXRZi59rbmL3TRqkqNsM3Ihp8z6RyNSf5IwkFf/8TQXIFZ5xy ieNTtnFljinTDgScBjwSh0yvpQTuSL1doG8Uw5Gj3OAWVZWUnb/qrE6GGXY7cjHl 3KsPDr7/wMLF73kDc8TkcUPYcQkC3THXRB40qapSucB0utKZMfBWbczkZLu+JXxb aBLVqd9HKBhqyRsp5Y9yaCFYgWbIwssGYhgY+qi/vgr0y3aedP1A2Y0rhyyYUJAt wBRikkm58YQfotoN0o5H =YSqt -----END PGP SIGNATURE-----

9 11

Slow relay speeds for Australian geographic location(s)
by Mathew 13 Oct '14

13 Oct '14

Hello all, I run a non-exit relay in Australia. My relay has been running for almost 15 days and has seen very little traffic. I have a 100/40 fibre connection and bandwidth is set at 2MB/s and 2.5MB/s burst. The mean read/write is 3.22kb/s and the advertised bandwidth constantly varies between 100-800kb/s which is obviously a fraction of my available bandwidth. Do relays located in less tor frequented countries see much less traffic or something? I have ports set at 443 and dirport 9030, is this an optimal port setting? Anyone with helpful information would be appreciated. My relay is 1337m8 if anyone wants to look at the traffic. Thanks

4 4

New error message
by Paul Blakeman 13 Oct '14

13 Oct '14

Hi all This has started appearing in my notices.log Can anyone shed any light please? Oct 13 12:04:05.000 [warn] Unexpected sendme cell from client. Closing circ (window 1000). [3 similar message(s) suppressed in last 600 seconds]

2 1

Re: [tor-relays] GoodBadISPs revamp?
by mikael ball 13 Oct '14

13 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 had to create a new thread because i had digests turned on. oh well. On Mon, Oct 13, 2014, Thomas White wrote: > As a community I think we should also be more transparent in > communications with the ISP's in question. For example, rather than > stating a yes/no instead we find a tidy way to paste their exact > response and link it in the table so we know exactly who they talked > to, waht their question was and the reason they disallowed it. i agree with this. in addition, we should ask for all of the ASN and/or IP blocks from the customer service reps, query onionoo for nodes running within those and display a list of them. (how?) in regards to the EFF partnership idea: i support this. getting the name of a respectable entity who has experience in PR (what kind?) might help with getting the ISPs on board. - -- mikael ball 0xB1910271AE8587F4 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUO0GdAAoJELGRAnGuhYf0KbMP/RWYW8P5wkY2pZwV6pARoQOq i9C5RH+AXXceihZEdaxF5kXMaXGA3Xndck74DZ8O06dEmJzztMBFqR6342qgOwe0 d+oyb2DjCQPd8d/FJEPwrgJKcyKSi3EDgJt7KqUA7bMbcyh3cn4s+clVQzCeYkZK TWuzv2gzOUdL05t+N0MTAQG4tTCaFSH1Y3cC4zca764kAreds4DLRX/Ju4+wYUBe QdlxpKl11o6x7LF1nT7kNsxGdNY9VB5t6mbWDDjIBRA6lCbIIvAfqajDB9yuAqy8 yY230fhZ1PU4eU+eJdsxh3U9yI4t3Z5dKeKI0LAHe8agNoLP6IqmWJRV2odri/vb U7BpuY9v5zpQ5gs4U7ppwtgIWagdXe1YC4ULpdabW09InVnC2D0u6/ncUu7gVg08 2qIf+kWxLItaNVJr+4xH1tsJZfNuTK6sUjDm43LJP9WH9nuiveiLo+7MGb5vf1Aw PfdghSA+8J291hJv8X51SmvgEgl9b6SeV4WyBQQVsyFcomjOpBIQmXLt0+D1BhUd G7WNfRf584Ts372Brmtf8UfZqT0niMaHh3BEg14NvCpnaKZ8X8mwRSMHreaIvSpr /wlV8Dy62rpqcsrqp7srLYSsPA9AOP6DsHl52qEjZ4cbeSPY6/ir+RDXn1nJ3BHx 51PhadTMMRybDbNfv1Xv =Xniq -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Question on running bridge nodes
by teor 12 Oct '14

12 Oct '14

On 12 Oct 2014, at 09:32 , tor-relays-request(a)lists.torproject.org wrote: > Date: Sat, 11 Oct 2014 23:25:47 +0100 > From: Tor externet co uk <tor(a)externet.co.uk> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Question on running bridge nodes > Message-ID: <49c1abc0aa88e1bf8425fdc8e482402d(a)nodataavailable.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Hi, > > I've set up a bridge node in the previous few weeks, but have had to put > a bandwidth limit on, as I only have 10TB of traffic per month before my > ISP will start throttling me to 100k/sec. > > I wondered whether it was more helpful to the Tor network as a whole to > have have a very fast node which hibernated every 12-15 hours, or if I > throttled Tor traffic, so that the node was more stable. > > I'll confess that I'm far more au fait with the politics of Tor than I > am of the exact ins and outs of how the technology works. Any help would > be gratefully received. > > Thanks > L For relays, where pathing is quite dynamic, we recommend speed + hibernation over uptime. But for bridges, users obtain only 3 bridge descriptors at a time, usually via some difficult or dangerous method. We'd want to make sure at least 1 stays up at all times (2 for reliability), which would favour throttling. teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

2 2

Re: [tor-relays] Slow relay speeds for Australian geographic location(s)
by teor 12 Oct '14

12 Oct '14

On 12 Oct 2014, at 18:06 , tor-relays-request(a)lists.torproject.org wrote: > Date: Sun, 12 Oct 2014 18:06:42 +1100 > From: Mathew <wired.kid(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Slow relay speeds for Australian geographic > location(s) > > Thanks for the in depth post, Teor. I had read the lifecycle article but > was concerned when people were posting that their relay was soaking all > their bandwidth after a day or two. This makes sense now, given the > oversupply and location. It was also worrying when the advertised bandwidth > was fluctuating so much and was only advertising a fraction of what > actually is available. > > The Windows server is using very minimal resources at the moment, and TCP > connections are around 250. The router will definitely be able to handle > the load, I run a pfSense APU. > > TPG doesn't have any bandwidth constraints specifically. They run a lot of > their own infrastructure including their own undersea PPC-1 cable > https://www.tpg.com.au/about/networks.php. No connection is ever shaped by > TPG and I have unlimited bandwidth. > > Amsterdam - http://www.speedtest.net/my-result/3825961515 > LA - http://www.speedtest.net/my-result/3825963543 > Boston - http://www.speedtest.net/my-result/3825964878 > London - http://www.speedtest.net/my-result/3825966771 > > So you think it isn't detecting all of my available bandwidth due to > distance and location and such? Is it just one of those things? > > torrc http://pastebin.com/GcTswhQx Actually, I think it's a matter of waiting on a stable IP and network connection for a month or two. (Your torrc looks fine.) I was just trying to list all possible factors, however unlikely. The instability is likely due to the bandwidth authorities (there's only a small number, which doesn't help stability). It will stabilise over time. But I don't think your overall level is caused by the authorities. Now that I think about it, as far as I recall, the "observed bandwidth" is a notional figure, not an actual bandwidth measurement. Because middle relays are in oversupply, their bandwidths get weighted down. (My middle relays are listed at about 50% of their advertised/link bandwidth.) Australian middle relays that are getting similar results to yours are: Aquinas DC5E2202E0148A53379F68A04207E04FFA7B4B2D (default) - Windows 8 terranullius - Windows 8 CoD Australian middle relays that are getting almost their exact advertised bandwidth: Serversaurus If you can pick the difference, I'm sure we'd be glad to know why! teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

1 0

Re: [tor-relays] Slow relay speeds for Australian geographic location(s)
by Mathew 12 Oct '14

12 Oct '14

Sorry about that test. Thanks for the in depth post, Teor. I had read the lifecycle article but was concerned when people were posting that their relay was soaking all their bandwidth after a day or two. This makes sense now, given the oversupply and location. It was also worrying when the advertised bandwidth was fluctuating so much and was only advertising a fraction of what actually is available. The Windows server is using very minimal resources at the moment, and TCP connections are around 250. The router will definitely be able to handle the load, I run a pfSense APU. TPG doesn't have any bandwidth constraints specifically. They run a lot of their own infrastructure including their own undersea PPC-1 cable https://www.tpg.com.au/about/networks.php. No connection is ever shaped by TPG and I have unlimited bandwidth. Amsterdam - http://www.speedtest.net/my-result/3825961515 LA - http://www.speedtest.net/my-result/3825963543 Boston - http://www.speedtest.net/my-result/3825964878 London - http://www.speedtest.net/my-result/3825966771 So you think it isn't detecting all of my available bandwidth due to distance and location and such? Is it just one of those things? torrc http://pastebin.com/GcTswhQx Thanks again.

1 0

Re: [tor-relays] Slow relay speeds for Australian geographic location(s)
by Mathew 12 Oct '14

12 Oct '14

Test

1 0

Question on running bridge nodes
by Tor externet co uk 11 Oct '14

11 Oct '14

Hi, I've set up a bridge node in the previous few weeks, but have had to put a bandwidth limit on, as I only have 10TB of traffic per month before my ISP will start throttling me to 100k/sec. I wondered whether it was more helpful to the Tor network as a whole to have have a very fast node which hibernated every 12-15 hours, or if I throttled Tor traffic, so that the node was more stable. I'll confess that I'm far more au fait with the politics of Tor than I am of the exact ins and outs of how the technology works. Any help would be gratefully received. Thanks L

2 2

Re: [tor-relays] Slow relay speeds for Australian geographic location(s)
by teor 11 Oct '14

11 Oct '14

On 12 Oct 2014, at 09:32 , tor-relays-request(a)lists.torproject.org wrote: > Date: Sun, 12 Oct 2014 06:19:16 +1100 > From: Mathew <wired.kid(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Slow relay speeds for Australian geographic > location(s) > > Hello all, > > I run a non-exit relay in Australia. My relay has been running for almost > 15 days and has seen very little traffic. > I have a 100/40 fibre connection and bandwidth is set at 2MB/s and 2.5MB/s > burst. > > The mean read/write is 3.22kb/s and the advertised bandwidth constantly > varies between 100-800kb/s which is obviously a fraction of my available > bandwidth. > > Do relays located in less tor frequented countries see much less traffic or > something? I have ports set at 443 and dirport 9030, is this an optimal > port setting? > > Anyone with helpful information would be appreciated. My relay is 1337m8 if > anyone wants to look at the traffic. > > Thanks A few hints: 1. The Tor network currently has an oversupply of non-exit relays. Therefore, your relay will never be fully utilised unless it is incredibly fast and stable over the longer term (months). 2. Your relay doesn't have the Guard flag yet. When it gets it, there will be a drop in traffic as your relay changes roles from middle to guard, then an increase overall. [-1] 3. If you look at the graphs for your relay on Atlas [0], there is a gradual increase in bandwidth. This should keep gradually increasing, apart from the guard transition in point #2. 4. It's unlikely your relay is compute-bound (at 100% CPU) or network-bound (saturating any network links). But it might be resource-bound (again, this seems unlikely at the levels you're seeing). Can your NAT box handle ~5000 simultaneous TCP connections/open files/NAT translations? (Mine can't, it reboots occasionally.) Can your Windows server handle ~5000 simultaneous TCP connections? 5. Most of the Tor network is outside Australia. How is TPG's international bandwidth for the NBN? Are the coping? Or are they shaping international transfers? (Please feel free to correct my ISP and network assumptions.) What do you get if you use an online bandwidth test server located in the US or Europe? What are your typical upload speeds on the link? 6. The bandwidth authorities are outside Australia. This appears to produce greater bandwidth measurement variance. To measure bandwidth, the authorities build a circuit between it, your router, and another router with similar bandwidth. More than likely, the authority and other router are a long way away from Australia. My experience has been variance between 50 - 120 KB/s on a 120KB/s set bandwidth. (Which is a little too low for a Tor relay, by the way.) And to answer your questions: A. Tor is country-agnostic, but network-aware by default. Faster, stable relays get priority. B. In my experience, 443 gets more bandwidth than the Tor default port of 9001. You could try setting up another instance on 9001, and see if it experiences the same issues after a few weeks. You could also try paste-binning your torrc, and we'll look for specifics. [-1]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay [0]: https://atlas.torproject.org/ teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w…

1 0

Few questions about relaying
by Blaise Gagnon 11 Oct '14

11 Oct '14

Hi and many thanks for developping this project ! I have a dedicated 200Mb (25 MB) fiber optics connection and a dedicated quad-core Linux server (64). What is the best setup to get maximum bandwidth usage ? I'm still stuck at 46.4Kb measured speed and 3,51MB advertised bandwidth. The server has direct connection to the Internet. Fingerprint : 5EF740BB88C75915F8316DFEC8F1C8631FF26F12 Should I run multiple relays on the same machine/IP ? Thanks !

6 17

introduction
by Mirimir 11 Oct '14

11 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't know whether introductions are hopelessly old school on this list, but here's a brief one. Although I've used Tor for many years, it's been just about a year since I decided to understand it better. I've also been catching up on the literature. Now I'm considering the possibility of running some relays. I've read some of the instructions on torservers.net, and have a few questions about security. I'm presuming that this is the best place to ask them. I won't be signing all of my list messages, by the way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJUNy7oAAoJEGINZVEXwuQ+GPQH/imif4StAJPp6io3zBEkt3iu rNN94iZw+EukXnCbVMTKW686H/6l0NbQ+0iHQ+RkUeX7xUcvV7+rqB9E+nIB7bx/ DOXCDvyqOP2uUeYmxgkTxKz33jD3eMV+MGprB/9oCdMozur4yJmKjf+oYY+6+PT5 WO9Xf7rBbL9KuBqOY7iLCpRtLTvg31vkjz8o3pQFeJYm+aKKRnUjcNcwtroxxdUD c8xe5r8CtFkLL0OX8NuaRX2y3WXeu2GS/8fEEv95J3yqFPTCJ6K9hxmwRfbjG7QT wi/SZ2FEfdAzdvXwT3qd4E5CYMB8RKXVqArlsvmKs7EHbZSVzEqbTbzKBYBvckc= =P0Ua -----END PGP SIGNATURE-----

2 1

questions about attacks involving single-end measurements of available bandwidth
by Mirimir 10 Oct '14

10 Oct '14

In planning how to configure Tor relays, I've been considering various known attacks. Most involve systemic issues about design and implementation, and so aren't relevant to relay configuration. But there is one that seems relevant, and addressable. I've been reading the work of Sambuddho Chakravarty and coworkers, in particular his thesis and a technical report on LinkWidth.[0],[1] What seems relevant here are deanonymization attacks on clients and hidden services that rely on traffic watermarking in conjunction with single-end measurements of available relay bandwidth. I am somewhat dubious about real-world workability. Fast relays simultaneously handle numerous connections, and so it's arguable that no single connection substantially perturbs available bandwidth. But on the other hand, it takes months for traffic through new relays to ramp up, and perhaps they are easier to scope while relatively idle. Regardless, Tor relays are very specialized. And so it should be trivial to craft iptables rules that prevent responses to LinkWidth and other tools for single-end bandwidth measurement, but don't interfere with anything essential. However, I haven't come across anything that seems relevant. Has this threat been addressed? Or am I missing something that complicates the response? Or conversely, is it not something to worry about? [0] Chakravarty (2014) Traffic Analysis Attacks and Defenses in Low Latency Anonymous Communication (PhD thesis) http://www.cs.columbia.edu/~angelos/Papers/theses/sambuddho_thesis.pdf [1] Chakravarty et al. (2008) LinkWidth: A Method to Measure Link Capacity and Available Bandwidth using Single-End Probes http://academiccommons.columbia.edu/download/fedora_content/download/ac:110…

1 0

Need Routing Info on Relays
by Tor Zilla 09 Oct '14

09 Oct '14

Hi Folks, I am trying to figure out how the packet flows over a Tor network.. There is a mix of information.. Some claim that the ISP is not aware of the payload as the complete data is encrypted whereas some say that your ISP is not used at all when using Tor network. AFAIK my packets go to the outer web via my ISP and there is no way to by pass that. I might be wrong. Can someone give me a detailed packet flow? Thanks, Torzilla11

3 8

Re: [tor-relays] . obfsproxy not working on bridge relay
by Jan Nielsen 09 Oct '14

09 Oct '14

I believe that error means obfsproxy was either not installed correctly or your torrc is not pointing to the correct location. Follow the below link's instructions. Also, a quick google search for that error provided resukts from this mailing list. Follow its instructions as well. https://lists.torproject.org/pipermail/tor-relays/2014-February/003892.html On Oct 8, 2014 6:00 AM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. obfsproxy not working on bridge relay (jchase) > 2. Re: obfsproxy not working on bridge relay (George Kadianakis) > > > ---------- Forwarded message ---------- > From: jchase <jchase(a)riseup.net> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Wed, 08 Oct 2014 10:36:39 +0000 > Subject: [tor-relays] obfsproxy not working on bridge relay > Hi, > Due to m limited bandwidth I've decided to turn my relay into a bridge. > I seem to have everything right except if I restart tor I get a warning > that "managed proxy obfsproxy is 'closed'". I'm sure this has come up in > the past but I can find it in the archives. > In torrc I have: > SocksPort 0 > ORPort 9001 > Exitpolicy reject *:* > Log notice file /var/log/tor/notices.log > Contact info [] > Nickname rasptorholland > BridgeRelay 1 > ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed > ServerTransportListenAddr obfs3 0.0.0.0:9030 > DisableDebuggerAttachment 0 > > Both ports are forwarded, though I can't find proof that tor is actually > using port 9030. > > Any suggestions? > -J. Chase > > > > > ---------- Forwarded message ---------- > From: George Kadianakis <desnacked(a)riseup.net> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Wed, 08 Oct 2014 11:41:22 +0100 > Subject: Re: [tor-relays] obfsproxy not working on bridge relay > jchase <jchase(a)riseup.net> writes: > > > Hi, > > Due to m limited bandwidth I've decided to turn my relay into a bridge. > > I seem to have everything right except if I restart tor I get a warning > > that "managed proxy obfsproxy is 'closed'". I'm sure this has come up in > > the past but I can find it in the archives. > > In torrc I have: > > SocksPort 0 > > ORPort 9001 > > Exitpolicy reject *:* > > Log notice file /var/log/tor/notices.log > > Contact info [] > > Nickname rasptorholland > > BridgeRelay 1 > > ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed > > ServerTransportListenAddr obfs3 0.0.0.0:9030 > > DisableDebuggerAttachment 0 > > > > Hello, > > how did you install obfsproxy? Which installation instructions did you > follow? Seems like you didn't follow: > https://www.torproject.org/projects/obfsproxy-instructions.html.en > > What happens if you run '/usr/bin/obfsproxy managed' in a terminal? > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

1 0

Bridges and advertised bandwidth
by Jan Nielsen 09 Oct '14

09 Oct '14

Hi everyone. I am currently operating 4 bridges on VPSs. They all appear to working correctly. However, 2 of the 4 bridges have 0kb/s as their advertised bandwidth while the other two are advertising around 100KB/s. Is there a reason for the 0kb/s? Does this indicate an error in my bridges or simply a gitch? See this for reference. https://globe.torproject.org/#/search/query=acrossthebridge Thank you.

1 0

How many exits can we run?
by Eric Hocking 09 Oct '14

09 Oct '14

Hi everyone, Is there a limit to how many exit nodes we can run?

3 2

Re: [tor-relays] obfsproxy not working on bridge relay - solved?
by jchase 08 Oct '14

08 Oct '14

> From: George Kadianakis <desnacked(a)riseup.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] obfsproxy not working on bridge relay > Message-ID: <874mve973h.fsf(a)riseup.net> > Content-Type: text/plain > > jchase <jchase(a)riseup.net> writes: > >> Hi, >> Due to m limited bandwidth I've decided to turn my relay into a bridge. >> I seem to have everything right except if I restart tor I get a warning >> that "managed proxy obfsproxy is 'closed'". I'm sure this has come up in >> the past but I can find it in the archives. >> In torrc I have: >> SocksPort 0 >> ORPort 9001 >> Exitpolicy reject *:* >> Log notice file /var/log/tor/notices.log >> Contact info [] >> Nickname rasptorholland >> BridgeRelay 1 >> ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed >> ServerTransportListenAddr obfs3 0.0.0.0:9030 >> DisableDebuggerAttachment 0 >> > > Hello, > > how did you install obfsproxy? Which installation instructions did you > follow? Seems like you didn't follow: > https://www.torproject.org/projects/obfsproxy-instructions.html.en > > What happens if you run '/usr/bin/obfsproxy managed' in a terminal? Hello, Thanks for your advice! I had installed obfsproxy with apt-get on a Pi. I removed that and tried pip. It took me a while to find out that pip was actually python-pip. (Maybe the Tor website could be more specific about that.) That install went well. You asked me to see what happened after the command '/usr/bin/obfsproxy managed'. It took me a while to find that obfsproxy was installed in /usr/local/ , not in /usr/bin/ . And now, until further notice from tor, things seem to work fine. Thanks, J. Chase

1 0

obfsproxy not working on bridge relay
by jchase 08 Oct '14

08 Oct '14

Hi, Due to m limited bandwidth I've decided to turn my relay into a bridge. I seem to have everything right except if I restart tor I get a warning that "managed proxy obfsproxy is 'closed'". I'm sure this has come up in the past but I can find it in the archives. In torrc I have: SocksPort 0 ORPort 9001 Exitpolicy reject *:* Log notice file /var/log/tor/notices.log Contact info [] Nickname rasptorholland BridgeRelay 1 ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed ServerTransportListenAddr obfs3 0.0.0.0:9030 DisableDebuggerAttachment 0 Both ports are forwarded, though I can't find proof that tor is actually using port 9030. Any suggestions? -J. Chase

2 1

Trying Trusted Tor Traceroutes
by Sebastian Urbach 08 Oct '14

08 Oct '14

Dear list members, We are happy to present the preleminary analysis results from TTTT: http://arxiv.org/pdf/1410.1823v1.pdf The conclusions are: 1. We have found that AS-path prediction techniques significantly overestimate ASes and IXes traversed by Tor traffic, calling into question the results of previous evaluations of the network-level adversary threat. 2. Our simulations show that Tor may currently be less vulnerable to an AS or IXP adversary than has been previously found. We also find that proposed path-selection algorithms to avoid a network adversary still leave a significant chance for users to be deanonymized over time due to the errors in path prediction, and these algorithms lead to significant rates of connection failures, even though in the large majority of cases the failures could be avoided with better measurement. 3. Thus our results suggest the importance of accurate measurement both for understanding Tor security and for improving it. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Less Traffic on my relay
by Tor Zilla 07 Oct '14

07 Oct '14

Hi All, I am a noob to the Tor community and its fun serving Tor as one of the relays. I am planning to setup multiple relays however before i jump into anything further i setup one machine as a non exit relay to test how much traffic i can route.. Not to forget i also read the article on torproject.org which mentions the life cycle of a relay.. Now its the 4th day of my relay and the traffic is almost nothing but as per the article i must see an increase in traffic on day 4.. The machine is ON for almost an hour now and the traffic is too less. Received : 3.62MB Sent : 1.6MB My dedicated bandwidth to Tor is 60 KB/s.. Do i need to keep the machine on 24/7 because as of now its just ON for 3 to 4 hours.. Assuming that the traffic is low on the entire Tor network is this kind of traffic normal or something is wrong on my side..? Your help will me much appreciated.. Thanks and Regards, Torzilla11

5 7

Tor metrics regarding bridges running transports
by Jan Nielsen 07 Oct '14

07 Oct '14

Hi all. I was wondering if these metrics exist? I couldn't find anything on tor metrics. They list the amount of users using transports but there is no information regarding the number of bridges running particular pluggable transports.

2 1

My relay hibernated unexpectedly
by Derric Atzrott 07 Oct '14

07 Oct '14

Hello all, I recently set up the relay zelltor. I just got a notification that it went down about 10 hours ago. From what I can tell it looks like it decided to hibernate and that it will be hibernating for the rest of the month. I think I may have configured something wrong because this was rather unexpected. I want it to hibernate at a certain point, but I do not think its reached that threshold yet. Arm tells me: Accounting (hard) 15 MB / 250 GB 598 KB / 250 GB Time to reset: 31:02:20:23 I have the following configured in torrc: AccountingMax: 250 GB AccountingStart: month 3 15:00 Tor's log files: [notice] Configured hibernation. This interval began 2014-10-03 15:00:00; the scheduled wake-up time is 2014-10-03 15:00:00; we expect to exhaust our quota for this interval around 2014-11-03 15:00:00 (all times local) [notice] Commencing hibernation. We will wake up at 2014-10-03 15:00:00 local time. [notice] Heartbeat: Tor's uptime is 3 days 12:00 hours, with 0 circuits open. I've sent 6.08 GB and received 6.08 GB. We are currently hibernating. [notice] TLS write overhead: 6% [notice] Circuit handshake stats since last time: 2039/2039 TAP, 753/753 NTor. [warn] eventdns: Address mismatch on received DNS packet. Apparent source was 216.69.185.43:53 [notice] Heartbeat: Tor's uptime is 3 days 18:00 hours, with 0 circuits open. I've sent 6.08 GB and received 6.08 GB. We are currently hibernating. [notice] TLS write overhead: 6% [notice] New control connection opened. Note: I stripped the timestamps out because I am viewing these on a different computer and had to retype them. My ISP caps me at 500 GB up+down data per month, which is why I've capped it at 250 GB. I was planning to adjust that down a little bit as needed when my next month's bill came in and I got to see how much overhead Tor produces above the 500 GB cpa. Clearly I've come nowhere close to that though, so I don't think my node should be hibernating yet... Any ideas? Thank you, Derric Atzrott

4 4

Arch Linux packages?
by Eric Hocking 05 Oct '14

05 Oct '14

Hi all, I looked through the Arch Linux repository, and wasn’t able to find any packages for Tor or arm. Does anyone use archlinux that could create a package for Tor and arm?

3 2

French Flag
by Sebastian Urbach 02 Oct '14

02 Oct '14

Hi, I saw that a lot of services around tor are using a bright blue in the french flag. It should be a dark blue like the one used in the Dutch flag for example ... The following services are concerned: Atlas Globe Compass Oniontip (already fixed, thanks Donncha) If there are more services around that i don't know about then i would like to ask if someone could check them as well. It hurts a bit to see the Tricolore like that ... Thanks -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Re: [tor-relays] scramblesuit
by Jan Nielsen 02 Oct '14

02 Oct '14

When I restart tor with that option enabled I get: " 2014-10-02 00:52:38,199 [WARNING] Obfsproxy (version: 0.2.3) starting up. 2014-10-02 00:52:38,199 [INFO] Entering server managed-mode. 2014-10-02 00:52:38,200 [INFO] No transports launched. Nothing to do." I noticed it says version 0.2.3 starting up. $obfsproxy --version gives me O.2.12 Why is tor starting the old version? This must be the reason it is not working since scramblesuit was only rolled into obfsproxy in version 0.2.6 . How do I get $sudo service tor start To start obfsproxy v0.2.12? On Oct 1, 2014 5:43 PM, <tor-relays-request(a)lists.torproject.org> wrote: Send tor-relays mailing list submissions to tor-relays(a)lists.torproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays or, via email, send a message with subject or body 'help' to tor-relays-request(a)lists.torproject.org You can reach the person managing the list at tor-relays-owner(a)lists.torproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tor-relays digest..." Today's Topics: 1. tor-relays (top mail) 2. tor-relays mailing list submissions (top mail) 3. Re: Bandwidth not being used by Tor on Gigabit dedicated server (Jon Daniels) 4. Re: Scramblesuit (isis) ---------- Forwarded message ---------- From: top mail <tpmail(a)safe-mail.net> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 08:49:53 -0400 Subject: [tor-relays] tor-relays tor-relays ---------- Forwarded message ---------- From: top mail <tpmail(a)safe-mail.net> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 08:50:49 -0400 Subject: [tor-relays] tor-relays mailing list submissions tor-relays mailing list submissions ---------- Forwarded message ---------- From: Jon Daniels <apexio(a)gmail.com> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 07:30:37 -0700 Subject: Re: [tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server Thank you for the reply. I have already (months ago) configured the max file limit to be 795552. Perhaps I'll try running more instances... On Tue, Sep 30, 2014 at 11:46 AM, Tom van der Woerdt <info(a)tvdw.eu> wrote: > I've often found my servers accidentally bottlenecked by the default open > file limit on some Linuxes. For example, on CentOS 6 this is 4096, which > for an exit node tends to mean ~50Mbit/s per process. > > A single process will not saturate 1Gbit/s. Judging by the hardware > (AES-NI support) you will need 3 or 4 instances running simultaneously to > max the link. > > Tom > > > > s7r schreef op 30/09/14 20:31: > > -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> It has nothing to do with the location (US). There are fewer US exit >> relays than other countries in Europe. >> >> Check the CPU usage too, usually CPU is the bottleneck on high port >> speed servers. Tor does not know yet how to do multithreading. >> >> Do you have AES-NI hardware acceleration at your CPU? This is very >> helpful too. >> >> Install htop (yum -y install htop) and it will tell you exactly how >> much each core is used. Let us know. I see that you confirm CPU load >> is not the fault, but probably you are checking it via a tool which is >> reporting the usage for ALL CPU (all cores) - try with htop and see if >> there is just one core @ 98% usage and others at less than 10%. >> >> If the CPU is not the bottleneck, there is something at your provider >> (probably throttling Tor traffic to balance the other non-tor users in >> the same datacenter). If you built the network infrastructure there >> and know for sure such thing is not implemented there, don't really >> know what to say. CPU / RAM and Network interface is all you can test >> to see if it is the bottleneck for Tor. If all these are off the list, >> there is something upstream you. >> >> I repeat, the location is not the fault here, and I encourage adding >> more exits in the US. >> >> On 9/30/2014 8:52 PM, Jon Daniels wrote: >> >>> Hi, >>> >>> My Tor node is not utilizing the bandwidth available to it. I have >>> tried setting RelayBandwidthRate to various values with no change >>> whatsoever in bandwidth usage. >>> >>> Running for 5 months with 99.77% uptime: >>> https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C8 >>> 06E6FDA4A1 >>> >>> My node has used a maximum of about 4MB/s or about 40Mbps. I've >>> been expecting it to use 10MB/sec to 30 MB/sec. It dropped from >>> 4MB/sec to around 1MB/sec now. >>> >>> OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL >>> RAM: 8GB Network connection: 1000Mbps >>> >>> Bandwidth tests show the server can easily send or receive hundreds >>> of Mbps. I have tweaked server settings trying to get the speed up >>> to no avail. >>> >>> >>> Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with >>> Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. >>> >>> Relevant config: >>> >>> DirPort 9030 # what port to advertise for directory connections >>> >>> RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) >>> RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s >>> (1600Kbps) >>> >>> DisableDebuggerAttachment 0 >>> >>> ORPort 443 >>> >>> ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 >>> # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # >>> finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept >>> *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 >>> # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # >>> LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # >>> kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept >>> *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy >>> accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over >>> SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # >>> kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept >>> *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS >>> management for firewall ExitPolicy accept *:989-995 # FTP over SSL, >>> Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 >>> over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept >>> *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec >>> ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept >>> *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy >>> accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy >>> accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility >>> Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) >>> ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept >>> *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy >>> accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy >>> accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy >>> accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC >>> ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # >>> XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market >>> ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC >>> ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC >>> SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # >>> HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy >>> accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # >>> Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept >>> *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS >>> ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept >>> *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept >>> *:10000 # Network Data Management Protocol ExitPolicy accept >>> *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept >>> *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP >>> ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept >>> *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept >>> *:64738 # Mumble ExitPolicy reject *:* >>> >>> In addition, there's another Tor node running at the same ISP (but >>> by a different person), on completely different hardware and a >>> different router, that exhibits the same issue: >>> >>> https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB04 >>> 42E900FB4C >>> >>> For background, I built and manage the network both servers are >>> hosted on and have been doing so for 20 years. I also built both >>> servers. The network is at less than 15% capacity, 99% of the >>> time. >>> >>> CPU load is always at 0.00. Based in the USA, west coast. >>> >>> Ideas? Is there simply less demand for tor traffic in the US? >>> >>> Cheers, Jon >>> >>> >>> _______________________________________________ tor-relays mailing >>> list tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> - -- >> s7r >> PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 >> PGP Pubkey: http://www.sky-ip.org/s7r@sky-ip.org.asc >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> >> iQEcBAEBAgAGBQJUKvcYAAoJEIN/pSyBJlsRft0IANm500IF63yielvNcKqVdXQl >> j1fe532wa+/Ui3x3CCAj05lAEGFZlIhRZG70HQql+A5tTHFOUQbMhkJloXs5OOMC >> XGwMy8f26A6ZbHd4YAtg4p1c6d7YRfd3QJD1k8yERoEG1jEOjtJANCsCuXCult7u >> NyXL1t9UD12KMbTckIchBdqr5k2wA9e+RI8O60jSIq3h06kJ7yDA5yO6JNAvVRPE >> 2FMCxrJ5Bu9wWhp7F4YvogMHXTlcVbVNubOe/D5oBumz7KjsjUPbshaWz3kbXJUY >> 939O2dB5h3OrZkz9MqnlnpPkqcA4yTFZT8J3cXqtnOvKZx9SXhpj6WAXmua/Mo8= >> =IYwa >> -----END PGP SIGNATURE----- >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> > ---------- Forwarded message ---------- From: isis <isis(a)torproject.org> To: tor-relays(a)lists.torproject.org Cc: Date: Wed, 1 Oct 2014 23:41:33 +0000 Subject: Re: [tor-relays] Scramblesuit Jan Nielsen transcribed 2.2K bytes: > Hi. > > I am trying to enable Scramblesuit for my bridge. I am wondering if there > is a method to verify that it is working, similar to how obfs3 shows > "registered server transport". There is not much out there about > scramblesuit but there is one mention that the log should show " registered > server transport scramble suit". > > Tor version is 0.2.5.8-rc > > Obfsproxy version 0.2.12 > > ExtORPort auto > > ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed > > Oct 01 03:03:28.000 [notice] Registered server transport 'obfs3' at ' > 0.0.0.0:39491' > > Is there something wrong with my config? One way to figure out if scramblesuit is running would be to enable logging, like this: ServerTransportPlugin scramblesuit exec /usr/bin/obfsproxy --log-file /var/log/tor/scramblesuit.log --log-min-severity info managed -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 1

Nokia n900 relay
by Franklin 01 Oct '14

01 Oct '14

Hi How to setup relay address on nokia n900?

2 1

Scramblesuit
by Jan Nielsen 01 Oct '14

01 Oct '14

Hi. I am trying to enable Scramblesuit for my bridge. I am wondering if there is a method to verify that it is working, similar to how obfs3 shows "registered server transport". There is not much out there about scramblesuit but there is one mention that the log should show " registered server transport scramble suit". Tor version is 0.2.5.8-rc Obfsproxy version 0.2.12 ExtORPort auto ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed Oct 01 03:03:28.000 [notice] Registered server transport 'obfs3' at ' 0.0.0.0:39491' Is there something wrong with my config? Thank you.

3 4

Failed to load Scramblesuit
by Christian 01 Oct '14

01 Oct '14

Dear fellows, maybe you can help out. And maybe I missed some information on my Tor version. I run an obfuscated bridge (Tor 0.2.5.8-rc (git-eaa9ca1011e73a9d)) on Ubuntu 12.04 and wanted to enable the scramblesuit pluggable transport. When changing my line in torrc to ServerTransportPlugin obfs3,scramblesuit exec /usr/bin/obfsproxy managed I get the following warning in the logs: [warn] The communication stream of managed proxy '/usr/bin/obfsproxy' 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. [notice] Failed to terminate process with PID '18171' ('Success'). Obfs3-only works like a charm without complaints. (ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed) I set my ExtORPort to "auto", pyptlib is installed, packages from obfsproxy and pyptlib are in the right locations and I use the shipped apparmor profile for Tor for Ubuntus. Even if I stop apparmor service, I don't get better results. I thought it was a permissions problem somehow as --log-min-severity=debug --log-file=/home/me/obfs.log won't even create the logfile so that obfsproxy fails from the very beginning. But, as I said, obfs3-only works without problems. Any ideas? Thank you in advance. Kind regards christian

2 1

Bandwidth not being used by Tor on Gigabit dedicated server
by Jon Daniels 01 Oct '14

01 Oct '14

Hi, My Tor node is not utilizing the bandwidth available to it. I have tried setting RelayBandwidthRate to various values with no change whatsoever in bandwidth usage. Running for 5 months with 99.77% uptime: https://globe.torproject.org/#/relay/1F6598EA09A82E7A5D3131E71A97C806E6FDA4… My node has used a maximum of about 4MB/s or about 40Mbps. I've been expecting it to use 10MB/sec to 30 MB/sec. It dropped from 4MB/sec to around 1MB/sec now. OS: CentOS 6.x 64bit latest CPU: Xeon E3 1230 MB: Supermicro X9SCL RAM: 8GB Network connection: 1000Mbps Bandwidth tests show the server can easily send or receive hundreds of Mbps. I have tweaked server settings trying to get the speed up to no avail. Tor v0.2.4.24 (git-549ec02c188842f6) running on Linux with Libevent 1.4.13-stable and OpenSSL 1.0.1e-fips. Relevant config: DirPort 9030 # what port to advertise for directory connections RelayBandwidthRate 30 MB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 30 MB # But allow bursts up to 200KB/s (1600Kbps) DisableDebuggerAttachment 0 ORPort 443 ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:110 # POP3 ExitPolicy accept *:143 # IMAP ExitPolicy accept *:194 # IRC ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:706 # SILC ExitPolicy accept *:749 # kerberos ExitPolicy accept *:873 # rsync ExitPolicy accept *:902-904 # VMware ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1220 # QT Server Admin ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1500 # VLSI License Manager ExitPolicy accept *:1533 # Sametime ExitPolicy accept *:1677 # GroupWise ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:1863 # MSNP ExitPolicy accept *:2082 # Infowave Mobility Server ExitPolicy accept *:2083 # Secure Radius Service (radsec) ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:2095-2096 # NBX ExitPolicy accept *:2102-2104 # Zephyr ExitPolicy accept *:3128 # SQUID ExitPolicy accept *:3389 # MS WBT ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:4643 # Virtuozzo ExitPolicy accept *:5050 # MMCC ExitPolicy accept *:5190 # ICQ ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5228 # Android Market ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8000 # iRDMI ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8074 # Gadu-Gadu ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8087-8088 # Simplify Media SPP Protocol, Radan HTTP ExitPolicy accept *:8332-8333 # BitCoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:9999 # distinct ExitPolicy accept *:10000 # Network Data Management Protocol ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* In addition, there's another Tor node running at the same ISP (but by a different person), on completely different hardware and a different router, that exhibits the same issue: https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB0442E900FB… For background, I built and manage the network both servers are hosted on and have been doing so for 20 years. I also built both servers. The network is at less than 15% capacity, 99% of the time. CPU load is always at 0.00. Based in the USA, west coast. Ideas? Is there simply less demand for tor traffic in the US? Cheers, Jon

4 4

tor-relays mailing list submissions
by top mail 01 Oct '14

01 Oct '14

tor-relays mailing list submissions

1 0

tor-relays
by top mail 01 Oct '14

01 Oct '14

tor-relays

1 0

Loki1 and Loki2 closed
by jason＠icetor.is 30 Sep '14

30 Sep '14

Hey fellow ops, Just an FYI today that Icetor lost two of it's fastest two exits that were hosted with Greenqloud here in Iceland, obviously would not recommend them as an ISP in the future regarding exit hosting. About two weeks ago we got notification that abuse notices were breaking their EULA and would be the reason for the termination. Today they shut down the nodes about 5 hours earlier than indicated, no ability to do data migration or save keys. Needless to say I'm not very happy with the entire situation and how it was handled. We'll soldier on with our remaining two exits and ifanyone is thinking of spinning up an exit in the future Icetor is still able to handle abuse contact for the relay. -Jason

1 0

Oniontip
by justaguy 30 Sep '14

30 Sep '14

So, https://oniontip.com is a great help for tor-relay runners We do need more donations imho Whoever made it, thank you - Justaguy

10 15

[warn] No unused circIDs found on channel without wide circID support
by tor-admin 29 Sep '14

29 Sep '14

Hi, since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this something to worry about? Regards, torland -------------------------------------------------------------------------- Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs in use by circuits, and 64 with pending destroy cells. (0 of those were marked bogusly.) The ones with pending destroy cells have been marked unusable for an average of 7594 seconds and a maximum of 16137 seconds. This channel is 18469 seconds old. Failing a circuit. Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of which 4 are active. It says it has 29535 destroy cells queued. Sep 28 16:07:24.000 [warn] Channel 93320 (at 0x7fbff4579d90) with transport TLS channel (connection 3245390) is in state open (2) Sep 28 16:07:24.000 [warn] * Channel 93320 was created at 1411894775 (18469 seconds ago) and last active at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 says it is connected to an OR with digest 4C733BAC82CC609ACC58AD95BFBFF04D5D06188C and no known nickname Sep 28 16:07:24.000 [warn] * Channel 93320 says its remote address is [scrubbed], and gives a canonical description of "[scrubbed]" and an actual description of "[scrubbed]" Sep 28 16:07:24.000 [warn] * Channel 93320 has these marks: !bad_for_new_circs canonical is_canonical_is_reliable !client !local outgoing Sep 28 16:07:24.000 [warn] * Channel 93320 has 0 queued incoming cells and 0 queued outgoing cells Sep 28 16:07:24.000 [warn] * Channel 93320 has 4 active circuits out of 4 in total Sep 28 16:07:24.000 [warn] * Channel 93320 was last used by a client at 0 (1411913244 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 was last drained at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last received a cell at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last transmitted a cell at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 has received 234 cells and transmitted 2497 Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 78.927350 seconds between received cells Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 7.396476 seconds between transmitted cells Sep 28 16:07:24.000 [warn] failed to get unique circID

2 1

Oniontip
by Sebastian Urbach 28 Sep '14

28 Sep '14

Hi, Mike, your questions are all valid. Remember where this project is coming from. Donncha put this together at the Dublin Bitcoin Hackathon and it was designed to give back a little bit to the Relay Operators. I never expected anything in return for my relays but im glad that onintip exists and the approach seems to be to give everybody a little bit back based on the consensus. Exit operators can get a lot of legal trouble and i acknowledge that but without Middle Relays, Guards, Bridges etc. TOR would not be possible. It seems to be always about the Exit's. There are different organizations for Exit's and now they should be preferred on oniontip.com ? It is hard not to feel like a second class Relay operator when you don't run an Exit. Im happy that there is a possibility like oniontip and btw. there is nothing similar on the torproject website. You can donate to the torproject via bitcoin but there is no way to choose who should receive this donation like you can do on oniontip.com Im not sure if it is necessary for oniontip to provide the best possible distribution of the donations from the projects point of view (diversity etc.) It seems to be a different approach just to give back to everybody and it has a certain amount of charme. It is easy to use and it seems to be working and becoming more and more popular. I like it. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

3 2

(no subject)
by I 27 Sep '14

27 Sep '14

Hej, Reportedly Pirate Bay runs virtual machines in someone else's clouds dodging revealing their IPs because traffic is handled by a load balancer. Why couldn't Tor be run in China, for example, using that method as there are cloud companies there? Robert

1 0

HAProxy + tor
by list-tor-relays＠nosur.com 26 Sep '14

26 Sep '14

Hello, My tor exit has been building up reputation for months but still fails to saturate a 100 Mbps line while barely using any CPU. Therefore, I recently decided to start a second tor process on the same server which is now slowly building up reputation. I gave the second process a different ORport in order not to affect the first process. Should that not be enough to saturate the line, I might even have to add a third process at yet other ports. I wondered whether the following is also possible: 1. Run tor process #1 on ORPort 8000, but advertise port 443 2. Run tor process #2 on ORPort 8001, but advertise port 443 3. Run tor process #3 on ORPort 8002, but advertise port 443 3. Run HAProxy on port 443; load-balancing between the three tor processes Obviously, this would require HAProxy to always route a circuit to the same tor process, since that tor process keeps track of the state of that specific circuit. Source IP stickiness ("balance source; hash-type consistent") would do that. Would such a setup work? Thanks, Bram

2 1

VPS in China
by I 26 Sep '14

26 Sep '14

Hej, Does anyone have an idea what might be done with a VPS in China? Robert

3 3

Estimating the value and cost of the Tor network
by Mike Perry 25 Sep '14

25 Sep '14

Hello everyone, I would like to put together some estimates on bounds of the current value and cost of the capacity of the Tor network as it is, and use that to generate some rough guestimates on what it would cost to grow it (assuming we solved all the complicated problems with respect to maintaining diversity and operator incentives). In order to make these estimates, I need some people to tell me: 1. Your node identity fingerprints. 2. How these fingerprints map to hardware, CPU cores, and uplink. 3. How much you are paying for this uplink per month. If you are paying less than market rate because of a friendly ISP, ideally you would also tell me what the standard market rate is at that ISP. If you have multiple nodes at multiple datacenters, please break these costs and fingerprints out individually rather than telling me aggregate information. I'd most like to hear from people who are doing the recommended best-practice of running one Tor process instance per CPU core, are paying for dedicated uplink at around 100Mbit/sec or higher at a datacenter, and who are not CPU bound on any of their Tor processes. If this does not apply to you, I'd still like to hear from you, but please tell me these details of your setup. Exit node data is most useful, but I am happy to hear about non-exits too. I suspect they may be much cheaper on average, and getting some data on this is also important. Unfortunately, bridges are not that useful at this time. You do not need to send this information publicly to the list. I am happy to receive it privately via GPG. My GPG key id is 0x29846B3C683686CC, and that key signs all of my mail to all torproject lists. You can get it here: https://pgp.mit.edu/pks/lookup?op=get&search=0x29846B3C683686CC -- Mike Perry

8 10

Bandwidth and weight fractions
by jchase 25 Sep '14

25 Sep '14

Dear Digest, If I take a look at my relay at atlas.torproject.org with the OR address of 83.163.171.103:9001 then I see on a 3 month graph that both my advertised bandwidth fraction and my consensus weight fraction are slowly declining. Concerning bandwidth fraction I assume this is a good thing, because if my bandwidth is stable then total bandwidth is going up (and my fraction is going down). Is the same true of my consensus weight fraction? If I'm going down, the total is going up? Thanks, JChase

1 0

Good hosting location for exit relay
by DerTor Steher 25 Sep '14

25 Sep '14

Hey, for a few days now I'm looking for an appropriate ISP for my new exit relay. There are a few problem I am facing now: 1.) Since I'm living in germany it isn't the very best to host an exit relay in germany, so I need to know which country is (law related) the best country I could host my VPS. 2.) The choice of a hoster. It's not easy to find a good and reliable and (if possible) cheap hoster which allows tor exit relays so I need to crawl to whole Good/Bad ISPs list for such providers. If I had the cash I would rent a server at Cyberbunker but it's to expensive to only run a relay there. I would appreciate if you could help me or at least give me some tips with finding the best country and provider. Thanks. :)

7 8

Re: [tor-relays] Call for a big fast bridge (to be the meek backend)
by David Fifield 25 Sep '14

25 Sep '14

On Mon, Sep 15, 2014 at 07:12:23PM -0700, David Fifield wrote: > The meek pluggable transport is currently running on the bridge I run, > which also happens to be the backend bridge for flash proxy. I'd like to > move it to a fast relay run by an experienced operator. I want to do > this both to diffuse trust, so that I don't run all the infrastructure, > and because my bridge is not especially fast and I'm not especially > adept at performance tuning. > > All you will need to do is run the meek-server program, add some lines > to your torrc, and update the software when I ask you to. The more CPU, > memory, and bandwidth you have, the better, though at this point usage > is low enough that you won't even notice it if you are already running a > fast relay. I think it will help if your bridge is located in the U.S., > because that reduces latency from Google App Engine. > > The meek-server plugin is basically just a little web server: > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… A couple of other requirements have shown themselves in helping set up a meek-server relay. The first is that it has to be a 0.2.5.x version of tor. This is so that the ExtORPort option will be supported. The ExtORPort option is needed in order to collect statistics on pluggable transports (see #4773). One of the lines you will have to add to torrc is: ExtORPort auto If your tor does not support the option, you will see in the log: [warn] Failed to parse/validate config: Unknown option 'ExtORPort'. Failing. The second requirement is that the relay needs to have either BridgeRelay or DirPort set. If neither of these options is set, the relay will not be a directory cache, and clients will not be able to bootstrap past "20%: Asking for networkstatus consensus." As I understand it, #12538 will make it so that every relay is a directory cache, but it is not committed yet. I'll check back privately with the people who offered to run a relay and check if setting these options is okay. David Fifield

1 0

Help collect hidden service usage stats?
by Roger Dingledine 24 Sep '14

24 Sep '14

Hi folks, If you are comfortable compiling Tor from git, and you want to help investigate what fraction of Tor network load comes from hidden service use, I have a shiny new git branch called hs-stats that will collect per-thirty-minute statistics about number of circuits and number of cells your relay sees that have to do with exiting, with hidden services, with circuits where you're not the final hop, and a fourth none-of-the-above category. https://trac.torproject.org/projects/tor/ticket/13192 It skips all circuits and cells that come from non-relays, which should help make sure the stats aren't useful for hurting anonymity. It doesn't automatically send the output anywhere -- it just writes it to its notice-level log for now. So you'll need to either send me the log lines, or add them to the trac ticket like I did here: https://trac.torproject.org/projects/tor/ticket/13192#comment:2 Preliminary results are that load from hidden services is actually a tiny fraction of overall load. A bonus use from these statistics would be to learn what fraction of load comes from exit connections vs middle connections, for relays with various consensus flags. And of course, it's possible there are bugs in how I'm doing the counting. I'll keep investigating to make sure I'm doing it right. Thanks! --Roger

1 0

How about a TWN entry about hosting locations?
by Jens Kubieziel 24 Sep '14

24 Sep '14

Hi, it seems quite much work for a person to collect information about hosting locations. So what do you think about putting a section into next TWN which links to a wiki page where everyone can share information about costs in different regions? -- Jens Kubieziel http://www.kubieziel.de Es genügt nicht, keine Gedanken zu haben. Man muß auch unfähig sein, sie auszudrücken. Karl Kraus

3 3

Alternative Nobel Prize
by Sebastian Urbach 24 Sep '14

24 Sep '14

Hi, The german magazine "der Spiegel" reports that Edward Snowden will receive the Alternative Nobel Prize. Congratulations Edward ! -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

2 1

A friendly reminder for all ScrambleSuit bridge operators.
by Yawning Angel 24 Sep '14

24 Sep '14

Hello all, This is a friendly reminder to all ScrambleSuit bridge operators that unless you are running tor-0.2.5.x, you should not be running a ScrambleSuit bridge. This is because the method for propagating the ScrambleSuit password (or any other future pluggable transport server side argument) for inclusion in the Bridge line served from BridgeDB was implemented in 0.2.5.x, and is not present in 0.2.4.x, and to make matters worse, 0.2.4.x has a bug that will allow this configuration to run instead of failing with an error[0]. If you are running a ScrambleSuit bridge with tor-0.2.4.x, it is useless. Users that happen to be served your ScrambleSuit bridge will not be able to connect, because the password is missing. Approximately 1/7th of the ScrambleSuit bridges in BridgeDB exhibit this behavior and we will most likely start filtering them on the BridgeDB side. Please see https://trac.torproject.org/projects/tor/ticket/13202 if you wish to know more about this. Best Regards, -- Yawning Angel [0]: Apparently this is not worth patching 0.2.4.x for, which I personally view as unfortunate.

1 0

Re: [tor-relays] Estimating the value and cost of the Tor network
by Tim 24 Sep '14

24 Sep '14

On 24 Sep 2014, at 13:38 , tor-relays-request(a)lists.torproject.org wrote: > Date: Wed, 24 Sep 2014 05:40:00 +0200 > From: Moritz Bartl <moritz(a)torservers.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Estimating the value and cost of the Tor > network > > Hi, > > Prices vary widely across different countries. We pay between $400 and > $1500 per Gbit/s per month in "popular and cheap locations". In a > scenario where we want to grow the network and at least keep the current > geographical diversity (or even grow it), we'd have to at least equally > strengthen less fortunate locations. > > The list of the top 20 countries [0] contains countries such as Russia, > Poland, Norway and Hungary, where international bandwidth is quite > expensive. Hopefully someone from this list can help us compile or find > estimates for pricing per country. It would be interesting to learn the > prices even for mid-size (~50-100Mbit/s+) relays in any country outside > of the top five countries, even more so for crazy places that don't make > the top 20. > > Another factor that we should not ignore is that, while it may be > possible to find a set of ISPs that allow mid-size exit relays, it gets > harder the more traffic you push, because of the additional workload > (and scariness) for the ISP from complaints. > > [0] https://compass.torproject.org/ > > -- > Moritz Bartl > https://www.torservers.net/ Mike, Moritz, Re: crazy places that don't make the top 20 I've noticed that most of the Tor network is concentrated in the northern hemisphere, particularly Europe and North America. I assume the distribution of authorities is similar. Apart from China, no Asia-Pacific country makes the top 20 in Tor compass.[1] And no southern hemisphere country makes the top 20 at all. The first Asia-Pacific countries after China are Japan at #29, then Singapore at #37. And unless I've missed something, the first southern hemisphere country is Australia at #42. Details aside, I'd love to see more routers and exits in countries other than the top 4 (Germany, France, Netherlands, United States). This helps spread failure risk, sovereign risk, and the risk from 3 letter agencies and the like. And it would make Tor faster for those in the southern hemisphere, Africa, and the Asia-pacific. But I don't know how much hope there is for this - I've tried to find pricing in Australia, and the figures I've found are: $8000 per month for 100Mbps.[2] $1500 per month for 25Mbps.[3] $800 per month for 10Mbps.[4] That seems ridiculously pricey… I'd rather wait for the National Broadband Network and run one on 100Mbps fibre at 1% of the price.[5] (Except bandwidth would not be guaranteed on a "home"-style plan.) Time to find a sympathetic university? Tim [1]: https://compass.torproject.org/?family=&ases=&exits=all_relays&by_country=T… [2]: http://www.intervolve.com.au/datacentre/ [3]: http://www.exetel.com.au/corporate/ip-transit-colocation [4]: https://www.xhostsolutions.com.au/services/dedicated-server-unmetered.cfm [5]: http://delimiter.com.au/2014/04/03/unlimited-100mbps-89-99-tpg-equals-top-n…

2 1

Good/Bad ISPs
by obx 23 Sep '14

23 Sep '14

I've updated the list of good/bad ISPs. It shows relay [ ] exit [ ] in front of every good ISP. Please verify that information is accurate. Special information, like anonymous hosting, would be appreciated. Thanks

1 0