Re: tor-browser bundle on XP
On Wed, Jan 14, 2009 at 10:20 PM, mikel.ander...@juno.com wrote: > ... it doesn't work on my limited-user accounts. Specifically, the Vidalia > control panel status reads, "connecting to a relay directory failed(no route > to host)". Is this due to the lack of administrator rights? the "no route to host" can be caused by many things, and may not be impacting the ability for Tor to function. can you try running vidalia with notice or info loglevel to see if a failure is reported? vidalia.exe -loglevel notice -logfile log.txt (don't send a full log to the list of course :) i would also be curious if the MSI based installer bundle works better when installed as unprivileged user: https://data.peertech.org/files/demo/updater/index.html best regards,
tor-browser bundle on XP
Y'all, I've recently started experimenting with the tor-browser bundle. I have successfully installed and used it on my XP administrator account but find it doesn't work on my limited-user accounts. Specifically, the Vidalia control panel status reads, "connecting to a relay directory failed(no route to host)". Is this due to the lack of administrator rights? Is there a workaround? Regards, Mikel Click for free info on Hollywood careers and quit your boring job. http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw1TzidHtF3ZUrOlB54DCE4lCoz9BtXERqCXWHmGCKj5nTt8V/
Re: cannot compile 0.2.1.10-alpha
Nick and coderman, thank you for your responding. I downloaded the 0.2.1.10-alpha source tarball again and configure it and make it. It succeeded this time. It's running normally as a client now. And then I come back to the first tarball I've downloaded a few days ago, re- configure it and make it again, also succeed this time. I just don't know how could this happen. The compiling is totally according to the instructions for building Tor from tor-win32-mingw-creation.txt in the 'doc' file. But it's from 0.1.2.19 source tarball. I've compared this instructions with the new ones from the new source version(say 0.2.1.10-alpha). No big differences except the versions: I use MinGW-5.1.3.exe, openssl- 0.9.8g.tar.gz and libevent 1.3e. I'm wondering if I should change the versions later. But the compiling did succeed with those older versions. It seems it's not affected. The config.log is rewritten since I reconfigured it. So I'm afraid I have lost the script before the successful compiling now. At last, here's a question which confuse me for a long long time. Everytime when my PC is running as a relay, even for a little while, I cannot reach any web pages later. I'm not sure if it has something to do with the PC itself. The configuration is as follows: Pentium 4 CPU 2.93GHz, 502MB RAM, Windows XP Professional(version 2002) Service Pack 3 the bandwidth limits and the exit policies for my relay are both default in Vidalia, that is >1.5Mbps. On Thu, Jan 15, 2009 at 1:37 AM, Nick Mathewson wrote: > On Tue, Jan 13, 2009 at 08:38:34PM -0800, coderman wrote: > > On Tue, Jan 13, 2009 at 7:59 PM, zmj wrote: > > > windows xp+sp3+mingw > > >... > > > > how did you invoke configure? > > > > what version of mingw? > > It would also be helpful to have a copy of the config.log script that > configure generated, since something seems to have gone wrong there. > The file torint.h is only supposed to define ssize_t if the platform > has no ssize_t, but it seems that yours has one in sys/types.h that > autoconf did not detect. > > (The config.log file will be very big. Please do not email it to the > whole list. Just compress it and send a copy to me and coderman, if > you could.) > > thanks, > -- > Nick Mathewson >
Re: Asynchronous bandwidth limiting
Hi everyone, just a quick follow-up on what I've done: John Brooks wrote: > bandwidth globally, not per-port. In that case, it may be a good idea for > Sebastian to disable the dirport to keep outgoing traffic roughly equivalent > to incoming, since outgoing is his limitation. I have disabled the directory on my server to a) ensure maximum bandwidth and traffic are available to OR b) ensure symmetry between incoming and outgoing bandwidth/traffic usage I have currently established both limiting and accounting to see which performs better. Depending on the distribution of load on my node I will probably adjust these values. It has been pointed out to me in a private eMail that I have mixed up 'asynchronous' and 'asymmetric' in the my eMail's subject line. For the record, it should have been 'Asymmetric bandwidth limiting'. Thanks for the help and hints. Sincerely, S. Lechte signature.asc Description: OpenPGP digital signature
Re: Questions about gathering information and statistics about the tor-network
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Sebastian, Sebastian Schmidt wrote: > Hi, I'm writing a tool right now to gather some longtime statistics > about the tor-network. That sounds like a fun project! :) I'm a bit in a hurry and cannot answer your posting in detail, sorry for that. But let me give you some pointers now. Well, first of all, I should say that your concerns about possibly endangering anonymity of Tor users are very important. The data you collect should not be usable to deanonymize Tor users. For example, you mention collection of data on entry nodes (and that you don't want to collect them, okay). What you should _not_ do is collect precise data about who connected to your entry node at what time. Someone else could collect similar data on their exit nodes what targets are requested at what time. Both data sets don't pose a risk on their own, but put together... *ouch* A better way to collect such data would be to aggregate them over, say, 24 or 48 hours, aggregate them by country instead of memorizing single IP addresses, and round them up to multiples of 8 or 16. That's about how geolocations of directory users can be collected right now. If you wanted to experience a few dozen enraged privacy researchers, you should have been at last PETS when a study on the Tor network, 'Shining Light in Dark Places: Understanding the Tor Network', was presented. Apart from the authors' consideration to make their data available to the research community in an 'anonymized way' (I don't recall their full plan for anonymizing them), that paper is a good read! ;) So, the right way to collect data about an anonymity network is for sure a hot topic. Prepare for a lively discussion here. ;) Anyway, I wanted to give you some pointers. Did you know that gathering good statistics of the Tor network is on the 3-year roadmap (Section 5.7)? https://svn.torproject.org/svn/tor/trunk/doc/roadmaps/2008-12-19-roadmap-full.pdf This should really not stop you from doing your own statistics! We have just started with that and there's definitely enough fun work left to do. :) But maybe some thoughts in that document are interesting for you. Also, you might be interested in an analysis of bridge usage in Tor. The bridge authority Tonga collects data about all bridges in the network in order to give them out to bridge clients. These data are also archived for later statistical analysis. The approach of evaluating these data might be interesting for you. The data model is more or less the same as for non-bridge data. Ah, and please keep in mind that this is only an early draft of the analysis *cough*. If you want, you can find the evaluation scripts in the parent directory of the same SVN repository: https://svn.torproject.org/svn/projects/dir-stats/trunk/bridge-stats/report/bridge-stats-2008-12-25.pdf There will be some more statistics on the Tor network within the next weeks. My plan is to evaluate archived network statuses, router descriptors, and extra-info documents of the past 12 months to get a better idea on the network growth and related facts. Further, I'd like to evaluate geolocations of client requests to the directory authorities and directory mirrors. And I want to finish that bridge data analysis. So, to answer one of your questions: Yes, people are interested in such statistics. :) If you have ideas on what data should be collected (and how that can be done in an anonymity-preserving way) or what statistics should be performed with existing data, your input is most welcome! And sorry again for ignoring most of your posting. I'll try to get to it the next days. Thanks! - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJbmLC0M+WPffBEmURAtRzAJwIbTfQk2gJ9f8KGv3fxjiF4dsqqgCgzq5o V33eHw/Q8GdBIzvWFsZL5kw= =KVOW -END PGP SIGNATURE-
Questions about gathering information and statistics about the tor-network
Hi, I'm writing a tool right now to gather some longtime statistics about the tor-network. I want to plot these hourly taken information (e.g. with gnuplot) to offer plots on a daily/weekly/monthly/yearly base about the tor-network. I think this is usefull (for the tor-development and the interested users) to observe the development of the tor-network over the time like: is the number of nodes growing/shrinking, are routers positions spreading more around the world over time or starting to even more concentrate on some countrys like the US, Germany,.. , number of and relation of exit-to entry-/middle-nodes, average uptime of the nodes, development of which ports are being blocked by the nodes, is the average bandwith of the network growing or shrinking and so on... There are some informations which can be easily collected by the single server-descriptors by simply asking the control-port like: the number of nodes, with geoiplookup and their IP's also their country, the uptime and the blocked ports and stuff like this. But there are some informations which are interesting too which aren't as easily to gather: 1.) the number of users: this would be a cool information but I don't know if there's at the moment any way also even just to roughly estimate the number of users. There are in my opinion just two places where such informations could a bit reliable be gathered but both are out of the game because of the current implementation to offer a good security. And one way (place) to get a rough estimation not of the number of users but if this number is growing or shrinking. a.) the entry-nodes: every entry-node knows (or can know) how many individual users ( at least individual IPs ) are connecting to it right now. But because we don't know how many different circuits a user has open at one moment, we can't say how many users we have in total even if all entry-nodes would report the number of currently individual connections it has. Only workaround would be throwing all the information of all entry-nodes with all IPs of all users in one pot. But this would be a very very bad idea. So gathering the number of users based on entry-nodes is not going to work (at least not if we want the network to be as safe as it is at the moment). b.) the directory-servers: if all clients would ask the directory-servers in a constant intervall for new information we could gather the number of requests per dir-server per 24h hours and divide it with the interval lenghts. But this has two problems: one is that not every client is on 24h per day so the information would be pretty unreliable even if we would guess an average time a client is online within 24h. The other is that the implementation (https://svn.torproject.org/svn/tor/trunk/doc/spec/dir-spec.txt under 5.1) isn't a static interval for all clients but more randomly choosen. So also this is no option by a matter of fact that we don't know how long each client is up and the random interval. c.) the number of downloads of a new released tor version: the number of downloads of a new stable release of the tor-client could give an hint if the number of users is growing or shrinking. Of course this could just be collected on the tor-project page and thus would just be a snippet of all downloads/users because there are e.g. many users of modern operationsystems ( yes some small bang against MS/MacOS/Sun ;) ) which offer a packagemanagment-system and don't compile by hand. Those downloads and updates can't be count but even this snippet of downloads of a new stable-version (maybe within one week after it has been released) could give some impression if we compair this number to prior releases if the average number of users is growing or shrinking. 2.) the network health: network health can be understood in many different ways. One aspect I thought of would be the comparison of the bandwith all nodes are offering compaired to the bandwidth which is acutally used under the premise that we have enough users to consume all the bandwidth the nodes do offer (and I think we can safely make this premise). A good network health would mean under this condition that the bandwith which is acutally used is nearly the same as the bandwith the nodes offer. This gives an estimation of how good is tor on building circuits. If there are some nodes which aren't used all the bandwith they have to offer and other nodes which are nearly breaking under the bandwith they are asked for it means tor isn't doing well on assembling circuits. Also interesting would be here the number of connections each node has compaired with the bandwith it offers but the number of connections isn't exported at all. At least I couldn't find it in the service-descriptor. I came to think about this by simple tests. Building a circuit with three really fast nodes gives you more bandwidth than building a circuit with three really slow nodes. But on a healt net
Re: cannot compile 0.2.1.10-alpha
On Tue, Jan 13, 2009 at 08:38:34PM -0800, coderman wrote: > On Tue, Jan 13, 2009 at 7:59 PM, zmj wrote: > > windows xp+sp3+mingw > >... > > how did you invoke configure? > > what version of mingw? It would also be helpful to have a copy of the config.log script that configure generated, since something seems to have gone wrong there. The file torint.h is only supposed to define ssize_t if the platform has no ssize_t, but it seems that yours has one in sys/types.h that autoconf did not detect. (The config.log file will be very big. Please do not email it to the whole list. Just compress it and send a copy to me and coderman, if you could.) thanks, -- Nick Mathewson
