Re: Is gatereloaded a Bad Exit?
Am 14.02.2011 14:41, schrieb morphium: So, with everything said, could we now please Un-BadExit the nodes that were affected? the whole discussion didn't change my mind. I still support the idea of flagging them as bad exit. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
On 31.01.2011 10:52, morphium wrote: As I stated above, it's not a good idea to BadExit them, because it puts more load on the servers, that DO support https i.e. - and makes them slower. I disagree Morphium's position mainly for the same reasons Mike and Jake already pointed out. If the operators really care about their nodes they'll certainly contact Tor admins. Damaging Tor's reputation in the public due to exit sniffing imo is much more worse than loosing some bandwidth. And I don't see ANY point in BadExit'ing 5 random Nodes, suggesting that no one could capture your unencrypted traffic now. those five high bandwidth nodes with suspicious exit policies haven't been chosen randomly. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Repeated messages from me
I apologize for sending repeated messages to this list. My K9 Android mail app on the cell phone seems to be out of control. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor relay on vserver exeeding numtcpsock
On 12.01.2011 22:02, coderman wrote: On Wed, Jan 12, 2011 at 7:57 AM, Klaus Layer klaus.la...@gmx.de wrote: ... Error creating network socket: No buffer space available errors. The numtcpsocks parameter limit is set to 550 on the vserver. Before asking the ISP to increase the value I would like to ask you what a reasonable value of this parameter would be. 550 is ridiculous. it should be at least 4096, more if they are accomodating. here's some data for the machine running my four nodes: anonymizer2:~# netstat -tn | wc -l 54157 anonymizer2:~# netstat -tn | grep ESTABLISHED | wc -l 30708 regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: geeez...
Am 12.01.2011 22:48, schrieb Moritz Bartl: Did you run a Tor exit at home? I'm not sure if they come and seize your home computer if the Tor server is hosted in a data center. Olaf seems not to have run into big trouble yet (or maybe he was quick on replacing the hardware). running an exit in a German data center isn't a big deal. Size really matters and provides you a certain amount of safety. But as am employee working for a German Telco, I advise you not to run an exit node at home behind a DSL subscriber line. Do not do this! Two days ago my local police officer told me he's regretting that I might have to shut down blutmagie this year. So German law enforcement isn't Tor operator's enemy in general. Saturday at eighthundred I'll be a German Army's soldier in GFM Augustdorf barracks again, protecting the galaxy against aliens. http://www.informationfreeway.org/?lat=51.91590673350628lon=8.769514491697844zoom=14layers=BF00F0 regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: blutmagie law enforcement inquiry stats
On 11.01.2011 06:19, Orionjur Tor-admin wrote: Do they describe causes their requests? usually not in detail and besides that I don't care. In most cases it is fraud or stalking. Requests from BKA (some kind of German FBI) or via Berlin state department are more sophisticated and related to bomb threats, threatened politicians, school massacres, and so on in other countries. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: blutmagie law enforcement inquiry stats
On 10.01.2011 22:07, Andrew Lewis wrote: What do they typically ask for, and is it from any place in particular? they always ask for a relation between an ip address (the one of my exit node) in conjunction with a time stamp, and an individual. Usually I'm asked for user's inventory data Bestandsdaten and session data Verbindungsdaten. In other words they ask: Which of your users was assigned the ip address 192.251.226.205 at $TIMESTAMP? - Please provide us with all of your data related to this individual. I'm not sure what do you mean with particular place. Do you ask if the requests originate from a certain law enforcement agency? They don't. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: blutmagie law enforcement inquiry stats
On 11.01.2011 11:15, Matthew wrote: What does this mean? sorry, I meant I didn't visit countries with oppressive regimes during the last three years. Don't know if they'd like me entering their country even when coming in peace as a tourist. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: blutmagie law enforcement inquiry stats
On 11.01.2011 15:48, Nils Vogels wrote: I think Olaf is expressing a concern, rather than a real-life situation for him. yes indeed, I did. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: blutmagie law enforcement inquiry stats
Am 10.01.2011 20:42, schrieb Roc Admin: This is interesting. Could you detail time consumed in resolving the requests and any problems you ran into with authorities? this morning arrived the first fax in 2011 requesting user data. Police is back again from Xmas vacation ;-) Using my template composing the answer and sending it thru a fax machine usually takes less than 15min. I never did run into difficulties with police so far. However I'm not sure what will happen at certain country's airport immigration. In most cases the police officers are quite polite and almost happy to close their file cause the trace ends. I suppose it's much more easy to deal with law enforcement if you appear 25 times a year on police's radar than only once. At least they tend to believe my words. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
torstatus.blutmagie.de stats 2010
http://twitpic.com/3mfnv7 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: torstatus.blutmagie.de stats 2010
just uploaded access stats for Nov 2007 until Dec 2009, too. http://twitpic.com/3mqufi http://twitpic.com/3mqu1u http://twitpic.com/3mqtmi yrs *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
forum hacks
Hi, are folks from 27c3 trying to break into web forums today? Never got so many abuse complaints within a few hours in the last three years. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor 0.2.2.20-alpha is out (security patches)
hi, 0.2.2.20-alpha doesn't compile on my Debian x86_64: ./configure --prefix=/ --disable-asciidoc --enable-openbsd-malloc make leads to make[3]: *** No rule to make target `OpenBSD_malloc_Linux.o', needed by `libor.a'. Stop. typescript output can be founde here: https://trac.torproject.org/projects/tor/attachment/ticket/2306/typescript.2 Just opened ticket 2306. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
torstatus IPv6
Hi, according my Apache log files the ratio between IPv6 and IPv4 access to torstatus.blutmagie.de is about 1:100. Domestic as well as foreign government agencies do not appear very much IPv6 enabled. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Very low performance in CriptolabTORRelays*
On 03.12.2010 08:40, Daniel Franganillo wrote: Well, im not asking for help to run a Tor relay, I did it for more than a year without problems. Im asking for help to gather intel so I can make an statement to our ISP (I work at a Dept. in a univeristy) to unblock Tor. why don't you ask them? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
On 25.11.2010 08:17, Damian Johnson wrote: The reason the operators of the largest tor relays (Blutmagie, TorServers, and Amunet) operate multiple instance is because this is the best way in practice for utilizing large connections. yep, all four blutmagie nodes are running on a single quad core cpu. The Tor application doesn't scale very well with the number of cores. Thus starting multiple instances on a single piece of hardware is the cheapest option to make use of a gigabit uplink. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
Am 25.11.2010 03:38, schrieb Theodore Bagwell: ** I speak primarily of torserversNet_ numbers 1-5, and PPrivCom___ numbers 004-052. hi there, would you mind to broaden your research covering blutmagie1-4? Its last 24h sustained bandwidth is higher than the cumulated bandwidth of all torserversNet and PPrivCom relays. Currently about 25% of all traffic reported by relays flagged as exit is routed thru blutmagie (50090 KBytes/s of 191341 KBytes/s Tor network's total). This doesn't trouble you? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
Hi, would it be noticed if an adversary modifies Tor's source code in order to report a fake observed bandwidth (a few KB), fake uptime data, and Windows as OS to the directories? Probably nobody will notice even if those relays carry a significant amount of traffic. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
IPv6
Hi, will Tor clients take any advantage from an exit node with IPv6 connectivity? cheers Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: AdvTor
On 09.10.2010 11:38, Anon Mus wrote: Prior to end August 2010, if this kind of message was received I just used to close the circuit and try again. Usually it would resolve by the 3rd try. I tested these exits to see if they could resolve other urls, they did so with ease, no errors. But at the end August every time I closed the circuit I got one of the blutmagie,blutmagie2,blutmagie3,blutmagie4 exits again and these could not resolve the DNS of webcrawler.com. So I did a little investigation and found that ALL these were not resolving this DNS but simple (web based) one hop proxies put on at the end of tor (globally) could resolve this dns. hi there, please let me know if there's something wrong with blutmagie's dns resolution. dig webcrawler.com works perfectly from shell. By the way: My employer Telefonica O2 is shutting down the local office end of Q1 2011. Besides my job this might lead to the loss of the special deal for hosting blutmagie exit node. I doubt to get 200 TB traffic each month for free somewhere else. http://www.thelocal.de/money/20101008-30361.html regards Olaf - blutmagie operator *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: blutmagie TNS / v0.2.2.15 nodes
Am 25.08.2010 12:35, schrieb Karsten Loesing:
On 8/25/10 12:10 PM, Olaf Selke wrote:
blutmagie Tor network status site apparently displays incorrect
bandwidth values for all nodes running version 0.2.2.15. Unlike other
tns sites blutmagie calculated bw as an average from the extra-info data
instead of using the bw peak value.
[...]
This might be related to:
Changes in version 0.2.2.15-alpha - 2010-08-18
- Relays report the number of bytes spent on answering directory
requests in extra-info descriptors similar to {read,write}-history.
Implements enhancement 1790.
There are now two new lines dirreq-read-history ... and
dirreq-write-history ... containing the bytes spent on the dir
protocol. Maybe TNS greps for read-history and not ^read-history
when parsing descriptors?
yes exactly!
And cause the dirreq-history data lines are displayed behind the
ordinary read/write history data, the script summed up the dirreq
bandwidth. Thus blutmagie tns mistakenly displayed the (correct)
directory request bandwidth for all 0.2.2.15 nodes. This is fixed now.
regards Olaf
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: $keyid of my server
Am 19.08.2010 17:49, schrieb Orionjur Tor-admin: After I write there MyFamily 90ECA7259B93B08FEC9872B2A1C065A0C05B2EE4,9087CA232B155B415AD81C0D3F636FC898246DEB I have the next errors output when I reatart my Tor daemon: prepend each fingerprint with a $ sign. Once I made the same mistake. The docs afaik doesn't mention it. Here's my exit nodes' config option: MyFamily $6297B13A687B521A59C6BD79188A2501EC03A065,$67EC84376D9C4C467DCE8621AACA109160B5264E,$66CA87E164F1CFCE8C3BB5C095217A28578B8BAF,$7B698D327F1695590408FED95CDEE1565774D136 Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: My relay never shows up
Am 11.08.2010 15:20, schrieb Praedor Atrebates: I am running a tor relay called Stonekeep. is it you? http://torstatus.blutmagie.de/router_detail.php?FP=a0470c0ea30c3a4d58048db134b8f9e7c6b52d6c Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: nameserver stats
Anders Andersson wrote: Qualified guess: These might be so-called BitTorrent trackers. These tracker URLs are embedded in torrent files that you download. You can download these torrent files from various sources, not necessarily (even rarely) from the site itself. When you load these torrents into a BitTorrent client, the client tries to contact all the trackers embedded in the file, and will probably try every 5 minutes or so. Smarter clients would give up or use incremental/exponential back-off, but there are probably enough dumb clients out there to compensate. attached you'll find the top 100 3rd level domain dns stats from the last four weeks. Still a lot of BitTorrent trackers... Olaf inline: 3rd-level-domains.png
Re: shadowserver.org
alex-...@copton.net wrote: Does anybody have experience with those guys? never heard of them. They never complained about Blutmagie exit. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] another proxy, but not open source :-(
Ted Smith schrieb: I wonder if they'll sign the binary blobs they distribute; it would be very easy for the police in any country to distribute their own backdoored version (via sneakernet) and just arrest everyone who uses it. I wonder why they're so exclusively focused on Iran. Their mission is to provide safe, unfiltered Internet to the people of Iran How do their users know it's not the Mossad behind the project? Anyway, I don't care. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: nameserver stats
Dyno Tor wrote: Interesting. Olaf, I notice BT destinations seem mapped to nxdomain or servfail. BT stands for BitTorrent, right? Do you do this purposely to reduce abuse reports, or is that done by your upstream provider? neither, the nameserver running on this machine does caching only knowing nothing but the root servers from its config. So there's no upstream provider's ns used. I can't explain the nxdomain and servfail mapping. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
nameserver stats
Hi, in case one might be interested in dns statistics of an exit node generated by the Dns Statistics Collector tool DSC (*). Data only include requests originating from blutmagie Tor exit. No other hosts' traffic is taken into account. The query rate on the graphs' x-axis has to be approximately doubled since there's a second nameserver used I don't collect data from. http://selke.de/pics/tld.png http://selke.de/pics/2nd-level-domains.png http://selke.de/pics/3rd-level-domains.png Olaf (*) http://dns.measurement-factory.com/tools/dsc *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Network Status Reports
Jon schrieb: I am just curious as to why of the known mirror's that show the network status reports, why there is such a discrepancy between blutmagie reports and the others? Is blutmagie using a different config in reporting than the others? It appears blutmagie numbers are a lot lower than the other mirror reports as far as I can tell. you are right. Blutmagie uses a different bandwidth calculation using average bandwidth values instead of peak load. I've adopted some code written by Kasimir Gabert from his tns 4.0 trunk version. Btw Kasimir's trunk tns site http://trunk.torstatus.kgprog.com uses the same calculation like blutmagie. This algorithm fulfilled Roger's wish #2 from his wishlist posted on this list two years ago: http://archives.seul.org/or/talk/Jan-2008/msg00300.html There are two other non standard tns 3.6.1 gimmicks introduced on Blutmagie. 1.) Hovering mouse pointer over the a flag shows the city as a tool tip and clicking on a flag opens router's location in Openstreetmap. 2.) In table Aggregate Network Statistic Summary at page's bottom there's a row Total Bandwidth of displayed Routers. If you narrow down your choice of displayed routers for example by required flags exit=yes it will display the total sum of last 24 hour average sustained exit loads. Olaf inline: tns.png
Re: Running a stable exit node without interference (Was blutmagie quad core upgrade)
M schrieb: Okay, that cleared things a lot. I Guess that authorities treats that ip-range as an ISP. yes, as Timo already pointed out, my own Ripe assignment does the trick. Authorities treat me like an isp. I have been thinking a long time how to run a stable exit node without getting constantly in trouble. Your own Whois-data on your ip-range (abuse-contact etc) could help a lot. definitely! Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
blutmagie quad core upgrade
hello, blutmagie exit node has replaced its former socket 775 core2 duo E8600 cpu by a socket 775 core2 quad Q9650. Furthermore memory is upgraded from 4 to 8 GB. Instead of one heavily loaded core which probably has been bad for latency there are now four moderately loaded tor processes running. Blutmagie, blutmagie2, blutmagie3, and blutmagie4 are announced as one family and each core runs safely below 100% cpu load which is hopefully good for latency ;-) BandwidthRate each process is set to 6000 KB. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Washington DC Exit Node?
Andrew De Souza schrieb: Are there any working exit nodes with an IP address in Washington DC? I have looked at http://torstatus.kgprog.com/ and found no DC exit nodes (there is one Washington State). However, rather than manually checking every single exit node from USA on ip2location.com can some one please tell me if they know of a DC exit node according Maxmind's geoip data currently Bigbooty is the only exit node located in Washington DC. Just have a look at my Kraut-tech tns site http://torstatus.blutmagie.de, filter to exit yes at page's bottom, view html source code and search for Washington. (ctrl-u and ctrl-f in Firefox). In normal browser view hovering the mouse pointer over a router's flag shows a tool tip with city and country code, and left clicking the flag opens the location on openstreetmap.org. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: anonymizer2:~# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 319 1000* PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 2075m 1.1g 25m R 95.2 29.4 2020:29 0 tor That CPU usage looks pretty high to me, but I still don't know what you were accustomed to seeing tor use before, so is it higher so far? Lower? cpu usage is always near 100% as long as being swamped by new circuits. Cpu load seems to rather depend on the number of established tcp connections than on the provided bandwidth. With openbsd-malloc resident process size usually has been far below 1gb even after one or two weeks. Process now with glibc malloc is still eating up memory and I'm sure it will crash within the next days. Total memory is 4 gb: anonymizer2:~# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 344 1000* PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 2702m 1.6g 26m R 88.5 41.8 3383:56 1 tor Okay. But, again, I'd still like to know whether the hugepages are helping tor's CPU load or hurting it, and I would need some historical clues, even if just estimates, to know the answer to that. in any case it doesn't hurt with respect to cpu load. I'm lacking programming skills to make hugepages work with OpenBSD_malloc_Linux coming with the tor sources. So hugepages might reduce load be roughly about 20% with the side effect of getting a memory leak from glibc malloc. @tor developers: Is there any good news for better scalability regarding multiple cores? regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: Olaf, if you're awake and on-line at/near this hour:-), how about an update, now that blutmagie has been running long enough to complete its climb to FL510 and accelerate to its cruising speed? Also, how about some numbers for how it ran without libhugetlbfs, even if only approximate, for comparison? (The suspense is really getting to me.:^) tor process is still growing: anonymizer2:~# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 319 1000* PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 2075m 1.1g 25m R 95.2 29.4 2020:29 0 tor It hard to tell after only one day how throughput is affected. Pls give me some more days. In the meanwhile everybody can do his own assessment from mrtg data http://torstatus.blutmagie.de/public_mrtg There are additional non-public graphs for environmental data monitoring like temperatures, fan speeds, and other super secret stuff which gives me a hint if someone is messing with my hardware. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
Christian Kujau wrote: On Tue, 13 Apr 2010 at 05:58, Scott Bennett wrote: and straighten us out. Remember that Olaf runs the highest-load-bearing tor node in our whole network, and there are at least two or four dozen others that should be considered heavyweight relays that are also on LINUX systems. ...and some of them are running on old notebooks and the tor process is only a few megabytes in size :-| In the end of all days tor traffic has to pass thru the exit nodes. About 50% of all traffic leave tor network thru the top 15 exit nodes only. If they can't cope with their load all nifty tor ports for smartphones, dsl routers or whatsoever acting as entry or middle man will be in vain. However, if it turns out that using hugepages in Linux would help larger Tor installations (and superpages can be recommended for *BSD systems[0] as well), maybe this can be documented somehwere under doc/ or in the wiki. But let's see how Olaf's experiment turns out. process size is still growing: anonymizer2:~# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 313 1000* It appears memory consumption with the wrapped Linux malloc() is still larger than than with openbsd-malloc I used before. Hugepages don't appear to work with openbsd-malloc. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
pimp my tor network status (tns), bandwidth sum
Hi, based on Kasimir's recent work evaluating the much more realistic read/write bandwidth history from extra-info data I've pimped my tns site with an additional info of the sum bandwidth of all routers displayed in the current view. It's located in the first line of the Aggregate Network Statistic Summary | Graphs / Details table near page bottom (the one without a percent value). Displaying all routers in the default view this bandwidth value doesn't say very much, but if you narrow down your choice with for example required flags exit = yes you'll see in the Total Bandwidth of displayed Routers row the sum bandwidth of all exit nodes being about 57.000 KByte/s for the last 24 hours. http://torstatus.blutmagie.de have fun, Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: It appears memory consumption with the wrapped Linux malloc() is still larger than than with openbsd-malloc I used before. Hugepages don't appear to work with openbsd-malloc. Okay, that looks like a problem, and it probably ought to be passed along to the LINUX developers to look into. yes, but I don't suppose this problem being related to hugepages wrapper. Linking tor against standard glibc malloc() never worked for me in the past. Always had the problem that memory leaked like hell and after a few days tor process crashed with an out of memory error. Running configure script with --enable-openbsd-malloc flag solved this issue but apparently it doesn't work with libhugetlbfs.so. After 17 hours of operation resident process size is 1 gig. PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 21716 debian-t 20 0 1943m 1.0g 24m R 79.4 26.9 927:51.27 1 tor On the other hand cpu load really seems to be reduced compared with standard page size. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: In any case, your Xeon(s) ought to be able to benefit considerably from running your gargantuan tor process in 4 MB pages instead of 4 KB pages. the old blutmagie exit running in 2007-2009 which serves my tns pages is equipped with two Xeon cpus from the old P4 Prestonia architecture. The exit node anonymizer2.blutmagie.de has one c2d E8600 cpu. Cause tor process basically spends all cpu time within one thread, a slower clocked quad/multicore wouldn't speed up anything. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
huge pages, was where are the exit nodes gone?
Scott Bennett wrote: Either I forgot (probable) or you didn't mention before (less probable) that you had moved it to a newer machine. Whatever you're running it on, superpages or LINUX's huge pages ought to speed tor up considerably by drastically reducing TLB misses. (I wasn't suggesting that you revert to older hardware. I was thinking that you were still running tor on the Xeon- based machine.) I just setup hugepages (1024 pages a 2 MB) according this hint http://www.pythian.com/news/1326/performance-tuning-hugepages-in-linux/ anonymizer2:~# echo 1024 /proc/sys/vm/nr_hugepages anonymizer2:~# cat /proc/meminfo | grep -i hugepage HugePages_Total: 126 HugePages_Free: 126 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB Does tor process automagically take advantage from hugepages after restarting the process or has tor source code to be modified? regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: Now that you've had tor running for a while, what does a cat /proc/meminfo | grep -i hugepage show you? Also, 126 such pages equal 256 MB of memory. Is that really enough to hold your entire tor process when it's going full tilt? I thought I had seen you post items here in the past that said it was taking well over 1 GB and approaching 2 GB. tor process crashed with out of memory error ;-) Apr 13 11:06:39.419 [err] Out of memory on malloc(). Dying. After restarting the tor process HugePages_Total and HugePages_Free still had a value of 126, so I assume tor didn't use them. Eventually I disabled them. cheers Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Scott Bennett wrote: BTW, I know that there are *lots* of tor relays running on LINUX systems whose operators are subscribed to this list. Don't leave Olaf and me here swinging in the breeze. Please jump in with your LINUX expertise and straighten us out. in case of someone being interested in blutmagie exit's low level stats: http://torstatus.blutmagie.de/public_mrtg regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: huge pages, was where are the exit nodes gone?
Arjan schrieb: http://libhugetlbfs.ozlabs.org/ From that website: libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. ok, just started tor with this wrapper. Looks like it's working as expected: anonymizer2:~/tmp# lsof -np `cat /var/run/tor/tor.pid` | grep libhugetlbfs.so tor 21716 debian-tor mem REG8,11452825390654 /usr/local/lib64/libhugetlbfs.so anonymizer2:~/tmp# hugeadm --pool-list Size Minimum Current Maximum Default 2097152 100 107 1000* anonymizer2:~/tmp# cat /proc/meminfo | grep -i hugepage HugePages_Total: 107 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:7 Hugepagesize: 2048 kB Keep you posted how it changes performance. Will go to sleep now, Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
no traffic but still a lot of open tcp sessions
Hi list, for some unknown reason my exit stopped publishing its descriptor. Bandwidth dropped to below 3 MBit/s and the number of new tcp connections dropped to less than 10 per second. Both seems to be reasonable. Good! But the tor process still owns about 8000(!) open tcp sessions in established state. I don't have a good explanation what these sessions are used for? Cause kernel tcp timeout parameters like tcp_timeout_established are set to rather small values, the sessions must be really alive. Since the pictures are small I dare to attach graphs for cpu load, new tcp conn/s, and open tcp sessions to this mail. regards Olaf inline: anonymizer2.blutmagie.de.tcpo-day.pnginline: anonymizer2.blutmagie.de_2-day.pnginline: anonymizer2.blutmagie.de.tcp-day.png
Re: [or-talk] where are the exit nodes gone?
Kasimir Gabert wrote: On Sun, Apr 11, 2010 at 9:01 AM, Scott Bennett benn...@cs.niu.edu wrote: On Sun, 11 Apr 2010 15:23:16 +0200 Olaf Selke olaf.se...@blutmagie.de wrote: [snipped] maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. You might communicate with Kasimir Gabert about that. I think he said some months ago that he was going to do that for his torstatus stuff, so what you want might already be written. I've been really busy these past numerous months, but that code is written. You can find it in the trunk version of TorStatus. fyi bandwidth bar for torstatus.blutmagie.de now calculates according Kasimir's new code evaluating the more realistic daily average from extra-info instead of the observed peak bandwidth. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Roger Dingledine schrieb: No, that 1755 was total Running relays. For comparison, there are 1541 running relays in the consensus right now. You might like http://metrics.torproject.org/consensus-graphs.html#exit-all the same graphs for the average observed bandwidth would be great regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: Observed by what? If it has anything to do with the numbers given in the consensus documents, then the only value such graphs would have would be for the purpose of comparing those graphs with the values reported by the relays themselves. The values in the consensus documents alone are, a priori, worthless. yes, the max and the burst bandwidth are not so much worth for statistic purposes. As I mentioned some says ago, MaxAdvertisedBandwidth 2500 KB config option leads to an real average bandwidth (measured by mrtg) of about 16000 KB on blutmagie exit. A higher MaxAdvertisedBandwidth value is killing the cpu with the number of new conns/s. Is it possible to use the average observed bandwidth reported by the relays? Knowing the number of exit relays doesn't help very much without knowing about the total provided bandwidth. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [or-talk] where are the exit nodes gone?
Scott Bennett schrieb: I see I missed the implication in Olaf's main complaint above, which is that the authorities are advertising more capacity for his node than his node is advertising. relax, I'm not complaining. We are all volunteers not being payed for writing tor code. Checking the current (i.e., valid-after 2010-04-11 10:00:00) consensus, I see that the authorities have decided to volunteer 2560 KB/s on behalf of node blutmagie, which is indeed greater than 2500 KB/s, though only 2.4% greater. yes, I noticed that without mentioning it on this list. It appears to be a common misunderstanding in coding between 2^10 and 10^3. (For some reason, my current directory files don't seem to contain a descriptor for blutmagie at all. I don't know why, but I assume that it will prove to be a temporary situation.) did my node stop publishing its descriptor again? Traffic has dropped about 80% within the last hours. Have a look at the attached graph. But the total exit usage question cannot be answered at present because nothing reports that information at present. maybe I take your advice and add php code at blutmagie tns to sum up the extra-info average rate data and print the so calculated bandwidth instead of max observed one. Regarding superpages: Is it possible to figure out how much cpu time being wasted in address translation with on-board means like vmstat? But I'm certainly not going to migrate my tor node to Windows. Never ever! ;-) regards Olaf inline: anonymizer2.blutmagie.de_2-day.png
where are the exit nodes gone?
hi there, on my exit node blutmagie the ratio of real bandwidth divided by advertised bandwidth has increased within the last three month by a factor of three. The MaxAdvertisedBandwidth 2000 KB config parameter leads to 135 MBit/s real bandwidth. Well known TNS sites like http://torstatus.kgprog.com sorted by bandwidth lists only two exit nodes within the top twenty. clueless Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: (FWD) [or-cvs] [tor/master] let people test the RefuseUnknownExits idea
Olaf Selke schrieb: I'll keep you posted if this new feature reduces cpu load or the number of open tcp connections. just for the records, on my router RefuseUnknownExits=1 doesn't change neither the number of concurrent cons nor cpu load regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: (FWD) [or-cvs] [tor/master] let people test the RefuseUnknownExits idea
Roger Dingledine wrote: For those who a) run an exit relay, and b) like running the latest git master, here's a new feature for you to test out. Let me know if it breaks, works brilliantly, stays suspiciously silent, etc. hi there, seems to work as expected. My exit now logs about 1000 messages per hour Attempt by [scrubbed] to open a stream from unknown relay. Closing. I'll keep you posted if this new feature reduces cpu load or the number of open tcp connections. Bandwidth is not an issue but blutmagie exit still suffers from high cpu load. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [OT] more censorship, government-issued spyware coming to France
Scott Bennett schrieb: Perhaps more people in Europe will have to relearn the hard way why the right of the people to keep and bear arms must be held inviolate. yes! 7.62mm full metal jacket http://twitpic.com/15p8wr yrs Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [Kraut] inquiries from law enforcement authorities
Eugen Leitl wrote: On Wed, Feb 17, 2010 at 11:22:09PM +0100, Olaf Selke wrote: It really has become an advantage providing my own pi address space. You don't have your own ASN, though? no overengineering ;-) Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
tns and GeoLite City
Hi, don't know if it's for good or bad, but stimulated by recent discussion on this list I've extended my tor network status page with maxmind's GeoLite City data. Hovering over the country flag now display as tooltip the city and a click on the flag opens a new browser tab or window showing the location on Openstreetmap using geoip's latitude and longitude data. Pls have a look here http://torstatus.blutmagie.de Have to go to sleep now ;-) cheers Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
bridge relay: GeoIPFile config option
Hi, am I right the bridge relay config option GeoIPFile means the path to GeoIP.dat provided by MaxMind? Starting tor as a bridge relay on a Debian box logs errors like [warn] Unable to parse line from GEOIP file: \001 [warn] Unable to parse line from GEOIP file: [warn] Unable to parse line from GEOIP file: \377\341\377\377i [warn] Unable to parse line from GEOIP file: \341\377\377\264 [warn] Unable to parse line from GEOIP file: \001 [warn] Unable to parse line from GEOIP file: \001 and so on. What am I missing? regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: bridge relay: GeoIPFile config option
starslights wrote: I have found the cause, on windows it's seem due of a wrong path , tor search Geoip on wrong folder. I have copy -paste the Geoip-cache in the right folder and have renname it as geoip. After that it have worked. this appears to be a different issue. In my case tor perfectly looks at the right place for the geoip file. Intentionally setting GeoIPFile option to an invalid path leads to an expected error message: [warn] Failed to open GEOIP file /usr/local/share/GeoIP/foo.bar. regards, Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[Kraut] inquiries from law enforcement authorities
hi there, if somebody being interested in exit gateway statistics: Since beginning of this year I've got seven inquiries from German police, one from Dutch and one from English police. With a monthly average bandwidth of 125 MBit/s (monitored by mrtg on interface level) this leads to about 0,5 inquiries/(MBit/year) for a German exit node. regards, Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: bridge relay: GeoIPFile config option
Roger Dingledine schrieb: On Tue, Feb 16, 2010 at 10:36:23PM +0100, Karsten Loesing wrote: On 2/16/10 6:17 PM, Olaf Selke wrote: am I right the bridge relay config option GeoIPFile means the path to GeoIP.dat provided by MaxMind? No. Tor can only handle the text-based ip-to-country database, but none of Maxmind's databases. You can the database that Tor understands in src/config/geoip in the sources: http://gitweb.torproject.org//tor.git?a=blob;f=src/config/geoip;h=31c721a9fe1d554e6a404b046eeaa4d83162f49b;hb=HEAD Or do you want to use Maxmind's database for some reason? If so, you can probably convert the text-based one (not .dat) easily. Tor actually understands several variants of geoip db format -- but all ascii, none binary. it might be a good idea to mention the supported geoip formats in the tor manual ;-) https://www.torproject.org/tor-manual.html @Karsten: So far I didn't try to understand tor's source code regarding bridges' geoip stuff. I supposed it to be MaxMind's format since it's used and proven to work by the well known tor network status web sites. The free maxmind one is intentionally crippled, which makes me not so optimistic about its future. the free of charge MaxMind's db works perfectly to match the country. Determining state/region, city, US postal code, and so on requires the non crippled version. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: bridge relay: GeoIPFile config option
Roger Dingledine schrieb: On Tue, Feb 16, 2010 at 11:21:56PM +0100, Olaf Selke wrote: The free maxmind one is intentionally crippled, which makes me not so optimistic about its future. the free of charge MaxMind's db works perfectly to match the country. Determining state/region, city, US postal code, and so on requires the non crippled version. Really? I am under the impression that they have four databases: 1) crippled (gpl) country db, 2) non-crippled (commercial) country db, 3) crippled city db, 4) non-crippled city db. here's a comparison between the free of charge (gpl) GeoLite Country and the commercial GeoIP Country version http://www.maxmind.com/app/geolitecountry Accuracy seems to be 0,3% different and update interval differs. Don't get me wrong, I'm not trying to convince tor developers to switch over to MaxMind's product. My intention only has been to understand the bridge relay startup errors. I was mistaken about the geoip db format even I rtfm. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
AW: tor exit-node abused, takedown by ISP,
If US law doesn't apply, why should one care about dmca notices? Regarding my exit node I simply ignore them. Olaf -- Gesendet von meinem Palm Pre
Re: Memory usage on relays
Scott Bennett wrote: On Tue, 19 Jan 2010 10:18:46 +0100 Olaf Selke olaf.se...@blutmagie.de wrote: LD_PRELOAD/foo/bar/libssl.so /foo/bar/libcrypto.so in /etc/init.d/tor? Yup. It looks to be missing an equal sign. :) What?! ;-) You are right, it's a copypaste error. Temporarily using an icc compiled openssl lib /etc/init.d/tor reads: LD_PRELOAD=/home/icc/tmp/openssl-0.9.8k/libssl.so /home/icc/tmp/openssl-0.9.8k/libcrypto.so start-stop-daemon --start --quiet --oknodo \ [...] Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Memory usage on relays
Nn6eumtr wrote: Binaries are staticly linked so that someone can't substitute a replacement library. Otherwise you can replace the library or set LDPRELOAD to implement a variety of attacks. can you give an example what's wrong with LD_PRELOAD/foo/bar/libssl.so /foo/bar/libcrypto.so in /etc/init.d/tor? That's how I enable special openssl versions on Debian. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Memory usage on relays
John Brooks wrote: This topic has been addressed before, but then the answer was often to use/wait for 0.2.1.x or switch to another allocator. ./configure --enable-openbsd-malloc solved this memory leak issue on my Debian box. Currently tor is using 354m resident memory and 20k open tcp sessions. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: QoS and Tor on Ubuntu 9.10
Matias Meier schrieb: I’m running tor server on a 100/100mbit dedicated machine which runs ubuntu 9.10 x86. Currently I’m sharing 1mb/s (8mbit/s) with the tor network. But I want to share more bandwidth with the tor network. But on my server are running also other services. Because of this I want to ask here, if it’s possible that a linux guru can write a little QoS script for me with “tc filters”. I need two different classes for traffic shaping. I don't think you need any nifty QoS features as long as you don't let tor eat up all bandwidth, cpu cycles, sockets, and kernel tcp table space. Just set BandwidthRate parameter in torrc to a reasonable low value. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Failed to decode requested authority digest
hello, since a couple of days tor logs an error condition about every 32 hours. Even looking at the code I don't really understand the cause. Jan 07 00:56:46.100 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 08 09:48:38.437 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 09 17:35:39.847 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Jan 11 01:05:58.288 [warn] Failed to decode requested authority digest 14C131%2027B6B5%20585769%2081349F%20E2A2AF%20E8A9C4. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: how much to use big relays (was Re: bloxortsipt)
hi, is there still any ongoing development to let tor take better advantage from a multi-cpu system than only performing onionskin decryption? With NumCPUs set to 8 my node looks like this: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ P COMMAND 8823 debian-t 20 0 607m 343m 28m R 84.3 8.7 4273:39 1 tor 14972 debian-t 20 0 607m 343m 28m S 2.7 8.7 0:02.52 1 tor 14971 debian-t 20 0 607m 343m 28m S 1.3 8.7 0:00.96 1 tor 14965 debian-t 20 0 607m 343m 28m S 0.7 8.7 0:00.42 0 tor 14966 debian-t 20 0 607m 343m 28m S 0.7 8.7 0:00.12 0 tor 14967 debian-t 20 0 607m 343m 28m S 0.7 8.7 0:00.04 0 tor 1 root 20 0 10324 684 572 S 0.0 0.0 1:24.63 1 init 2 root 15 -5 000 S 0.0 0.0 0:00.00 1 kthreadd [...] The main thread is running near 100% leaving the other five threads more or less idle. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: I exclude all bloxortsipt nodes in my tor use
Roger Dingledine schrieb: You might instead ask about blutmagie, which at an advertised 41200 KB is 3% of the Tor network. I'm pushing hard with all kind of gcc/icc compiler optimizations but at about 170 MBit/s throughput the E8600 cpu is running at its limits. Unfortunately server bios doesn't come up with overclocking features. Nevertheless I catch Roger's point. Is it a good idea exiting so much/many (never really understood the difference ;-)) tor traffic thru one exit gw? If it is not, I'm certainly going to reduce exit capacity by torrc config. https://torstatus.blutmagie.de/index.php?SR=BandwidthSO=Desc Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: How to exactly determine country of an exit node
Nico Weinreich wrote: So, do I have to check ever the whois for an ip or is there another way to be sure to use a german server? what do you consider a German server? - a server with a German ip address according to the ripe db - a server physically located in Germany - a server with an ip address reverse resolving to a .de domain - a server operated by a German individual Recently I dumped my own dns cache into a perl script and compared the ip addresses stored with those from an open danish dns server poisoned with the danish dns blocklist. I found a lot of blocked servers within the Chinese tld .cn using ip address space from the US. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: How to exactly determine country of an exit node
Nico Weinreich schrieb: I've visited http://torstatus.all.de to get some tor servers from germany. I thought it's enough to look on the country flag, but I've noticed a strange entry on this page. I found a router with name bleakgadfly5 file:///C:/Users/Nico%20Weinreich/Desktop/TOR/router_detail.php?FP=f1a05306b76358908111e15396e663344a186888 which belongs to germany (at least all.de claims so) with ip 217.114.215.227 and the hostname of this server is hosted-by-vps-hosting.co.uk. You can see the .co.uk domain and a whois for this ip gave a GB for country. So, do I have to check ever the whois for an ip or is there another way to be sure to use a german server? I supposed all.de using a stale GeoIP db version. https://torstatus.blutmagie.de using a more recent GeoIP database correctly shows GB for this tor node. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: How to exactly determine country of an exit node
Nico Weinreich schrieb: Olaf Selke schrieb: I supposed all.de using a stale GeoIP db version. https://torstatus.blutmagie.de using a more recent GeoIP database correctly shows GB for this tor node. OK. Could it be that this ip address changed the owner in the past and because of this your GeoIP db shows the correct country and all.de shows the wrong country? yes, I think so. Since the new /26 GB net is part of the much larger /20 DE network I assume it to be recently assigned to a customer from the uk. I thought about to cache the whois query for an ip address locally in a file. So I have to renew the local cache after a given time to be sure, changes in ripe db are taken into account. why do you want to reinvent the wheel instead of sticking with Maxminds GeoIP db? BTW: do the tor status homepages show the available servers in real time? yes it does, as well as the other tns servers are supposed to ;-) Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[Kraut] Re: tor-proxy.net
Benjamin S. schrieb: I don't know if anonymouse is logging and if so, under which circumstances they give those logs. I do log, because I'm sitting in Germany where I'm forced to do so by the data retention law. to make a long story short: I'm on Bundesnetzagentur's radar since at least one year by police's request regarding obligation for data retention §113a TKG Vorratsdatenspeicherung. In June 2009 there has been some correspondence in writing between the Bundesnetzagentur and my lawyer. In the end they no longer threatened me with a fine for violating German data retention law. Thus my exit node still neither collects any data nor do I store any (already not existing) logs for six months. Even I'm law-student, so I know a little bit 'bout when I have to give away the logs and when not. (you can read about this here[1]) Germany situation is such that you have to hand over your logs on authority's request. There's no choice to retain them. Olaf * the German Bundesnetzagentur is similar to the Ofcom in the UK. http://en.wikipedia.org/wiki/Ofcom *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
ro...@26c3
hi, in a few minutes Roger is speaking at the 26C3 in Berlin. Live wmv stream is avail here http://streaming-26c3-wmv.fem-net.de/saal2 or other formats here http://events.ccc.de/congress/2009/wiki/Streaming Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
100 TB
HoHoHo, exit node Blutmagie made 100 TB tor traffic since last reboot. anonymizer2:~# ifconfig eth0 | grep bytes RX bytes:110156275888000 (100.1 TiB) TX bytes:113494749822712 (103.2 TiB) regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: US Customers: anyone helping me?
rather expensive but worldwide shipping http://cgi.ebay.de/Sun-X6762A-Crypto-Accelerator-1000-375-3089_W0QQitemZ300369444042QQcmdZViewItemQQptZCOMP_EN_Servers?hash=item45ef69fcca Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: directory server tor.dizum.com
Olaf Selke wrote: since a couple of days my tor node logs a problem with tor.dizum.com: Nov 11 13:30:42.034 [warn] http status 404 (Not Found) reason unexpected while uploading descriptor to server '194.109.206.212:80'). the error vanished with v0.2.2.6. Has dizum's address been changed or was it a typo in v.0.2.2.5? Now it's .212 again. anonymizer2:~/tmp# diff tor-0.2.2.5-alpha/src/or/config.c tor-0.2.2.6-alpha/src/or/config.c | grep 194 194.109.206.214:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755, 194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755, Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Danish TPB DNS Blocks
tor-opera...@sky-haven.net wrote: Ideally, you run your own caching resolver and have every other host in the local site use that caching resolver, which uses the root DNS servers as hint servers. yep, that's what I did early this year when in German politics the discussion about dns blocking arose. The Blutmagie exit node is querying another server under my control running the caching dns proxy pdnsd. http://en.wikipedia.org/wiki/Pdnsd have a nice weekend Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: directory server tor.dizum.com
Alex de Joode wrote: I restarted the fw/ rules and tor, does it work now ? no Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: directory server tor.dizum.com
Olaf Selke schrieb: Alex de Joode wrote: I restarted the fw/ rules and tor, does it work now ? no I mean I'm sorry but it still appears not to work ;-) Is blutmagie the only node unable to upload its descriptor? Nov 16 15:34:25.636 [warn] http status 404 (Not Found) reason unexpected while uploading descriptor to server '194.109.206.212:80'). Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
directory server tor.dizum.com
hi list, since a couple of days my tor node logs a problem with tor.dizum.com: Nov 11 13:30:42.034 [warn] http status 404 (Not Found) reason unexpected while uploading descriptor to server '194.109.206.212:80'). Is the directory server tor.dizum.com being down? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [warn] Error binding network socket: Address already in use
Drake Wilson wrote: Quoth Olaf Selke olaf.se...@blutmagie.de, on 2009-11-10 07:54:57 +0100: It sounds like you're running out of outgoing ports to use for connections. yes, but only about 27000 tcp connections have been open That's getting close to the limit. Usually only high-numbered ports are used for outgoing connections. Since you mention you are running Linux, you may wish to check /proc/sys/net/ipv4/ip_local_port_range and possibly widen the range to see whether that helps. E.g., the default range on my system appears to be 32768--61000, which allows at most 28232 outgoing TCP connections that are not bound to specific ports, and fewer if some of the ports are stuck in wait states. /proc settings (as you are probably aware) are usually changed using echo and shell redirection, so you would use # echo 24576 65000 /proc/sys/net/ipv4/ip_local_port_range thx, it appears you are right: anonymizer2:~# cat /proc/sys/net/ipv4/ip_local_port_range 32768 61000 anonymizer2:~# echo 24576 65000 /proc/sys/net/ipv4/ip_local_port_range anonymizer2:~# cat /proc/sys/net/ipv4/ip_local_port_range 24576 65000 Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [warn] Error binding network socket: Address already in use
Drake Wilson wrote: # echo 24576 65000 /proc/sys/net/ipv4/ip_local_port_range one question again: why don't set it to 1024 65535? Is there any good reason to exclude a certain port range besides the ports below 1024 from being chosen as local port? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
[warn] Error binding network socket: Address already in use
Hiho list, after increasing bandwidth I get log entries [warn] Error binding network socket: Address already in use What does this mean? Average cpu load is about 85%. Platform is Debian Squeeze x86_64. Never seen this before with lower bandwidth and cpu load. regards Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [warn] Error binding network socket: Address already in use
Drake Wilson schrieb: You're probably an exit node, right? yes I am It sounds like you're running out of outgoing ports to use for connections. yes, but only about 27000 tcp connections have been open Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Less OT: Here's a Solaris crypto acceleration branch to try.
Roger Dingledine schrieb: On Wed, Oct 14, 2009 at 07:47:36PM +0200, Olaf Selke wrote: http://interloper.org/tmp/tor/2009-02-27-tor-callgrind-0.png That callgraph looks like it didn't handle much traffic. 10% of the cpu time was spend loading the geoip file? Looks like he captured the call graph soon after he turned on his Tor. does this one look more reasonable? It's generated with about 1 Mbit/s traffic during data collection. http://selke.de/pics/tor-callgrind.png Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Less OT: Here's a Solaris crypto acceleration branch to try.
Andrew Lewman schrieb: On 10/14/2009 02:18 PM, Roger Dingledine wrote: Looks like he captured the call graph soon after he turned on his Tor. Yes, the callgraph was to see what code pathways are called on startup of my relay at the time. sorry, I wasn't aware of this. Nevertheless the time spent in aes crypto appeares to be overestimated. openssl speed aes gives 200.000k bytes per second on my active exit node with aes-128 cbc. Since this is more than 1 Gbit/s aes crypto in theory and on the other hand 1 Mbit/s traffic costs about 1% one core cpu cycles in real world I supposed only about 10% cpu cycles spent in openssl aes crypto. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: My tor exit node is STILL gone from the node list
Alexandru Cezar schrieb: It seems as if the node is unreachable from some of the authority servers, but I have no idea what to do about that. My ISP says that routing is fine and everything should work as expected. I don't understand why the node stays listed for a few hours before disappearing. Can someone please help me get this 100EUR/mnth node up again? traceroute from blutmagie ends at amsix peering anonymizer2:~# traceroute 89.248.169.108 traceroute to 89.248.169.108 (89.248.169.108), 30 hops max, 60 byte packets 1 195.71.90.1 (195.71.90.1) 0.557 ms 0.547 ms 0.541 ms 2 xmws-gtso-de01-vlan-176.nw.mediaways.net (195.71.109.218) 1.381 ms 1.475 ms 1.522 ms 3 rmwc-gtso-de01-ge-0-2-0-0.nw.mediaways.net (195.71.12.57) 28.666 ms 28.665 ms 28.681 ms 4 rmwc-amsd-nl02-gigaet-2-0-0.nw.mediaways.net (195.71.254.182) 11.460 ms 11.458 ms 11.454 ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 *^C Olaf
Re: My tor exit node is STILL gone from the node list
Lee schrieb: Considering how many places block ICMP, traceroute is not a good way to determine connectivity. telnet 89.248.169.109 80 works for me and traceroute doesn't: oops, you're right! The same here. I didn't notice that before. Nevertheless blocking icmp at peering points is very unusual. Maybe path mtu discovery is broken if icmp is completely blocked. Olaf
Re: secret_id_key
Roger Dingledine wrote: So before mid June, relays had either Guard flags or Exit flags but never both. My guess is that having both of those flags makes clients less willing to use you as the middle hop, so your traffic drops. it looks your explanation being correct. Traffic dropped again as the new key blutmagie regained its guard flag. cheers Olaf
secret_id_key
Hi, about three weeks ago my exit node traffic dropped from about 45 MBit/s to 10-20 MBit/s. There's no explanation regarding network connectivity or server environment. Within the last three weeks the traffic didn't recover to the former value 40 MBit/s until I generated a new identity. With a new secret_id_key file the traffic recovered to the old value after one day. Does anyone have an explanation for this? Olaf inline: anonymizer2.blutmagie.de_2-week.png
Re: DNS statistics from node operators
Olaf Selke schrieb: Olaf Selke schrieb: Jacob Appelbaum schrieb: I was actually hoping to get statistics from you specifically, so I'm glad that you responded! ok, just got the patch. Keep you posted... tor now has been running for 17 hours: Jun 04 18:02:06.269 [notice] Our DNS cache has 7667 entries. Jun 04 18:02:06.269 [notice] Our DNS cache size is approximately 2772880 bytes. it doesn't change Jun 05 20:15:13.405 [notice] Our DNS cache has 7250 entries. Jun 05 20:15:13.405 [notice] Our DNS cache size is approximately 2632768 bytes. Olaf
Re: DNS statistics from node operators
Olaf Selke schrieb: Jacob Appelbaum schrieb: I was actually hoping to get statistics from you specifically, so I'm glad that you responded! ok, just got the patch. Keep you posted... tor now has been running for 17 hours: Jun 04 18:02:06.269 [notice] Our DNS cache has 7667 entries. Jun 04 18:02:06.269 [notice] Our DNS cache size is approximately 2772880 bytes. Olaf
Re: DNS statistics from node operators
Jacob Appelbaum wrote: I'm looking into some simple DNS related statistics in the Tor network. Specifically, I wrote a small patch that tells an operator the total number of cached entries for their node. I'd like to know about your DNS cache size, especially if you run a fast node! how does tor dns caching work? My exit gw's tor process size increases by about 50 MB each TB of tor traffic. Olaf
Re: DNS statistics from node operators
Jacob Appelbaum schrieb: I was actually hoping to get statistics from you specifically, so I'm glad that you responded! ok, just got the patch. Keep you posted... Olaf
Re: A tor error message prior to crash
Nick Mathewson schrieb: On Mon, May 11, 2009 at 01:33:41PM -0400, Praedor Atrebates wrote: I finally picked up a log entry that is associated with vidalia/tor failing at random moments: May 11 13:30:49.177 [err] Error from libevent: event_queue_insert: 0xa2e6d68(fd 33) already on queue 2 What does this mean and how do I fix it? I have a patch in the repository that might fix it. If you can build from source, please try out the latest maint-0.2.1 branch to see whether the bug is gone for you. (There might be some warning messages in the log that start with Bug. If there are, please let me know.) Nick's patch really fixed the problem. My exit node isn't crashing any longer. Current uptime is 12 days. Olaf
Re: A tor error message prior to crash
Praedor Atrebates schrieb: It isn't a matter of how I feel, it is simply a fact. If my tor relay server is going to keep crashing randomly, then I cannot operate it because I do not have the time to babysit it and keep restarting it. this is my very simple workaround for bug 957: anonymizer2:~# cat /etc/cron.d/check */5 * * * * root( /etc/init.d/tor start ) /dev/null 21 Debian's start-stop script doesn't start tor twice if it's already running. yrs Olaf
Re: A tor error message prior to crash
Praedor Atrebates schrieb: I finally picked up a log entry that is associated with vidalia/tor failing at random moments: May 11 13:30:49.177 [err] Error from libevent: event_queue_insert: 0xa2e6d68(fd 33) already on queue 2 there's an existing bug report for this issue: http://bugs.noreply.org/flyspray/index.php?do=detailsid=957 Got already about a dozen core dumps triggered by libevent. yrs Falo
Re: Nameserver messages on tor's logfile
Olaf Selke schrieb: Andrew Lewman schrieb: It would be good if you could open a bug report and include gdb bt output or debug logs around the crash. http://bugs.noreply.org/flyspray/index.php?do=detailsid=957 Also, which version of libevent are you running? libevent-1.3e.so.1.0.3 still the same problem tor coredumping with libevent-1.4. Maybe it's a x86_64 issue? I don't remember so many crashes within such a short time on my old 32 bit Debian platform. It's about one crash every two TB on my new x86_64 box. Olaf
Re: Nameserver messages on tor's logfile
Andrew Lewman schrieb: It would be good if you could open a bug report and include gdb bt output or debug logs around the crash. http://bugs.noreply.org/flyspray/index.php?do=detailsid=957 Also, which version of libevent are you running? libevent-1.3e.so.1.0.3 Olaf
Re: Nameserver messages on tor's logfile
Hans de Hartog schrieb: Tor's logfile irregulary receives the following messages: May 01 20:38:14.542 [warn] eventdns: All nameservers have failed May 01 20:38:15.034 [notice] eventdns: Nameserver 127.0.0.1 is back up May 01 20:52:01.832 [warn] eventdns: All nameservers have failed May 01 20:52:02.942 [notice] eventdns: Nameserver 127.0.0.1 is back up May 02 09:23:49.074 [warn] eventdns: All nameservers have failed May 02 09:23:49.503 [notice] eventdns: Nameserver 127.0.0.1 is back up May 02 12:52:15.519 [warn] eventdns: All nameservers have failed May 02 12:52:25.533 [notice] eventdns: Nameserver 127.0.0.1 is back up May 02 12:53:52.209 [warn] eventdns: All nameservers have failed May 02 12:53:52.296 [notice] eventdns: Nameserver 127.0.0.1 is back up I'm running tor 0.2.0.34 on FreeBSD 7.1-RELEASE and FWIW, I'm also running the standard nameserver locally: BIND 9.4.2-P2. It started after being up (as exit-relay) for about 8 days and after that, I see those messages several times per day. My libevent-version is 1.4.10 Why is this happening? I don't see anything logged by the nameserver so it must be libevent who thinks that the nameserver fails. I've seen this with all Linux versions within the last two years. No matter if 32 or 64 bit code. I don't believe my nameservers being unreachable. And using pdnsd as nameserver tor constantly core dumps. Olaf
Re: Nameserver messages on tor's logfile
Olaf Selke schrieb: I've seen this with all Linux versions within the last two years. No matter if 32 or 64 bit code. I don't believe my nameservers being unreachable. it just crashed again: May 05 17:42:38.539 [notice] eventdns: Nameserver a.b.c.d is back up May 05 19:24:20.166 [warn] eventdns: All nameservers have failed May 05 19:24:20.254 [notice] eventdns: Nameserver a.b.c.e is back up May 05 19:39:49.350 [err] Error from libevent: event_queue_remove: 0x7fc040aa5668(fd 0) not on queue 1 Olaf
