Tor 0.2.1.14-rc released

by phobos | April 13, 2009

Changes in version 0.2.1.14-rc - 2009-04-12
Major features:

  • Clients replace entry guards that were chosen more than a few months ago. This change should significantly improve client performance, especially once more people upgrade, since relays that have been a guard for a long time are currently overloaded.

Major bugfixes (on 0.2.0):

  • Finally fix the bug where dynamic-IP relays disappear when their IP address changes: directory mirrors were mistakenly telling them their old address if they asked via begin_dir, so they never got an accurate answer about their new address, so they just vanished after a day. For belt-and-suspenders, relays that don't set Address in their config now avoid using begin_dir for all direct connections. Should fix bugs 827, 883, and 900.
  • Relays were falling out of the networkstatus consensus for part of a day if they changed their local config but the authorities discarded their new descriptor as "not sufficiently different". Now directory authorities accept a descriptor as changed if bandwidthrate or bandwidthburst changed. Partial fix for bug 962; patch by Sebastian.
  • Avoid crashing in the presence of certain malformed descriptors. Found by lark, and by automated fuzzing.

Minor features:

  • When generating circuit events with verbose nicknames for controllers, try harder to look up nicknames for routers on a circuit. (Previously, we would look in the router descriptors we had for nicknames, but not in the consensus.) Partial fix for bug 941.
  • If the bridge config line doesn't specify a port, assume 443. This makes bridge lines a bit smaller and easier for users to understand.
  • Raise the minimum bandwidth to be a relay from 20000 bytes to 20480 bytes (aka 20KB/s), to match our documentation. Also update directory authorities so they always assign the Fast flag to relays with 20KB/s of capacity. Now people running relays won't suddenly find themselves not seeing any use, if the network gets faster on average.
  • Update to the "April 3 2009" ip-to-country file.

Minor bugfixes:

  • Avoid trying to print raw memory to the logs when we decide to give up on downloading a given relay descriptor. Bugfix on 0.2.1.9-alpha.
  • In tor-resolve, when the Tor client to use is specified by :, actually use the specified port rather than defaulting to 9050. Bugfix on 0.2.1.6-alpha.
  • Make directory usage recording work again. Bugfix on 0.2.1.6-alpha.
  • When starting with a cache over a few days old, do not leak memory for the obsolete router descriptors in it. Bugfix on 0.2.0.33.
  • Avoid double-free on list of successfully uploaded hidden service discriptors. Fix for bug 948. Bugfix on 0.2.1.6-alpha.
  • Change memarea_strndup() implementation to work even when duplicating a string at the end of a page. This bug was harmless for now, but could have meant crashes later. Fix by lark. Bugfix on 0.2.1.1-alpha.
  • Limit uploaded directory documents to be 16M rather than 500K. The directory authorities were refusing v3 consensus votes from other authorities, since the votes are now 504K. Fixes bug 959; bugfix on 0.0.2pre17 (where we raised it from 50K to 500K ;).
  • Directory authorities should never send a 503 "busy" response to requests for votes or keys. Bugfix on 0.2.0.8-alpha; exposed by bug 959.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

April 15, 2009

Permalink

Can anybody be clear enough to say where to make changes so that I can have a spefic country ip only as exit node?

All you guys do is point to a page where nothing makes any sense. Tell me in a simple language which file to edit in the Tor Directory or how to execute commands which will help me get what i want. I am no computer geek so please if you consider my request.

I am using Vidilia 0.1.10, Tor 0.2.0.34 (r18423), QT 4.4.3

Thank you.

Best Regards.

With Tor 0.2.0.34, you cannot do this. It's not supported in that version of Tor. It's in Tor 0.2.1.x-alpha series. Right now, it involves editing your torrc configuration file. We're hoping someone can make progress and/or send us patches on being able to click the Vidalia map and turn this into "exit from this country" for the new circuits.

Bonus points if they do it on Marble-ized Vidalia.

If you happen to be using linux, TorK can do this "exit by country" already.

Anonymous (not verified) said:

April 16, 2009

Permalink

Ok I downloaded Tor 0.2.1.14- rc and edited the torrc with this:

#Use Exit Nodes in DE
ExitNodes {de}
StrictExitNodes 1

And when I launch the program, the message log says:

Apr 16 13:59:27.093 [Warning] No specified exit routers seem to be running, and StrictExitNodes is set: can't choose an exit.
Apr 16 13:59:27.093 [Warning] failed to choose an exit server

Without the StrictExitNodes it doesn't give "de" exit ip.

Any solution you know for this?

Thank you.

Exit selection is a combination of country and port in your configuration. Perhaps no exit nodes in Germany allow an exit to the ports you desire.

Anonymous (not verified) said:

April 29, 2009

Permalink

anyways since this didn't work for me, I spent $99 buying unlimited ip license from Cloakfish which actually uses tor technology but is more efficient regarding geo-ip. I could pick up the end nodes with there program and it served my purpose.

So if Tor fixes this thing I would love to donate.

And might you be kind enough to tell us how we all shell do to "properly integrate" tor with a "geoip service" then, so that TOR is working as it should do.

The only way that seems to work is if you check for nodes in Germany & pick some nodes & use there fingerprint or nicknames, here is the fastest one now, example:

ExitNodes routor, weltbank, Piratenschatzi, FoeBuD3, gpfTOR4
StrictExitNodes 1

I wouldn't recommend using weltbank thou, behaved strange in the past...

The ExitNodes {de} or ExcludeNodes {de} is still not working, maby admin can tell us all why this command after several versions still doesn't work.
& why do you force people to use such an unsecure thing as javascript & cookies to make comments.

I think the cookies are required for the CAPTCHA, so they can know which person was assigned which CAPTCHA.

I have JavaScript disabled and haven't needed to enable it to comment here.

I have needed to load images, though. I have images disabled. Also, a lot of links are invisible unless you highlight the text or load the background image.

Anonymous (not verified) said:

May 22, 2009

Permalink

Well javascript is not needed but you have to turn on cookies for it to work, for a privacyrelated site i think you should not force people to use cookies either.

Trying:
ExitNodes berwick,NoMoBushWars,innerspace,extrapolator,bloxortsipt22,rhnetfsck,q867401q,WesCSTor,wchtfd
StrictExitNodes 1

For nodes in Atlanta, Georgia and Connecticut, USA does not work either, using
Tor 0.2.1.14-rc (r19307)

The entire ExitNodes function does not seem to be working...

Where do I go to get fingerprint codes to try that?

Anonymous (not verified) said:

May 22, 2009

Permalink

Your right, ExitNodes function does not work until they fix the geoip data issue. Now it only works some times not always as it should.

If you go to this page:
https://torstatus.blutmagie.de/
then you have to there you have to check one node at a time to get the fingerprints, you then take the info, for example
7BC0 E733 55F8 917F F69B F32D C1F5 6BB5 9F9E 67A5
and remove every space in between and add a $ before the number, like this
$7BC0E73355F8917FF69BF32DC1F56BB59F9E67A5
that is what you use in ExitNodes, they really made it easy to choose witch country's to use and not to use, don't you think.....

Anonymous (not verified) said:

April 24, 2009

Permalink

With the newest versions of Firefox and TOR, Firefox and the computer stop responding for a few seconds frequently. During these interruptions you can type text or scroll but nothing will happen on your screen for a few seconds and then all typed text will appear quickly and if you scrolled, it would scroll. I tested hardly to find out that the reason was TOR and had to uninstall it.

Anonymous (not verified) said:

April 24, 2009

Permalink

It's network related, if I turn off Internet, no problem. It's 2.4 GHz.

Anonymous (not verified) said:

May 08, 2009

Permalink

The problem can be turned off if you just disable the Torbutton in Firefox. When you need it, you can enable it and use it.

Anonymous (not verified) said:

April 26, 2009

Permalink

Thank you for a great program, just a question:

Tor / Vidalia needs a file with the name geoip in the Tor configuration directive for some of the functions to work properly.
No version of Tor / Vidalia i have tried(including the latest) creates such a file, why?

Is it really meant that i have to manually type in all the geoIP information for all the 4 294 967 296 IP adresses by hand, in that case it would take me quite some time.......

Any info about why Tor/Vidalia does not create this file(in windows version).
Without it the functions of excluding nodes by country would of course not work.

Don´t you wan´t people to be able to exclude nodes by country???

Anonymous (not verified) said:

April 27, 2009

Permalink

Old version nodes still running
On February 8th, Tor 0.2.0.34 was released,
you then said:

"This release marks end-of-life for Tor 0.1.2.x."

If this is true why do you still allow old version nodes to run ?

Version 0.1.2.19 that is known to have been used by nodes that used it to spy on traffic it is still used by 6% of all nodes. It was released 2008-01-17, that's over a year ago.
Even earlier versions are run by 7% of the nodes. When are you gonna stop the possibility to run a node on these old(& potentially dangerous) versions(theres really no good explanation why fast nodes like Kryten or TSL with 4800KB bandwidth still is running an old 0.1.2.19 version, unless it's modified).

End of life means we're not supporting the code any more. There will be no more updates or fixes applied to this version.

As you know, we don't control the nodes. If volunteer operators want to run older versions with known exploitable code that puts their operating system at risk, that's their choice.

Most people simply run what's in their distribution repositories, and in many cases, that's 0.1.2.x.

Tor clients don't trust any relay, so the risk is more on the relay OS side than it is for tor clients.

Anonymous (not verified) said:

May 18, 2009

Permalink

Thanks for answering.

"As you know, we don't control the nodes. If volunteer operators want to run older versions with known exploitable code that puts their operating system at risk, that's their choice."

Wouldn't it be very easy, just to add in the code to only allow nodes to run the latest 2 stable/unstable releases or versions released the last 6 month or something similar ?

Old relay nodes of course also puts Tor clients that use them at risk !

At least do this for fast nodes, i would understand that a chines node with 5KB/s bandwidth could have problems to find and download the latest updates but not an US or DE node with bandwidth of 1000+ KB/s

"End of life means we're not supporting the code any more. There will be no more updates or fixes applied to this version."

As versions 0.2.0.33, 0.2.0.32, 0.2.0.31 & 0.2.0.30 was released earlier wouldn't the release of version 0.2.0.30 on the 15 july 2008 have been the one that meant the "end of life" for the 0.1.2.x versions, if that was what you meant by that comment?

Anonymous (not verified) said:

May 07, 2009

Permalink

About the command CircuitBuildTimeout, before version 0.2.1.(9?) in the torrc one has been able to change this to lower values than 30, thats no longer the case, I think this is bad for one's privacy and bad for the overall speed of Tor, example:

If 2 of the 3 nodes in the circuit build fast (less than 2 sec) and the 3rd takes up to 28 sec then it's obviously either
1 overloaded, and it would be better if some people(that change this value in torrc) waited less than 30 sec to try to build another circuit)or
2 even worse it's doing some bad thing like an timing attacks(and you would absolutely not use it then.).

It would of course not be good for ones privacy to use values like 2, 3 or similar but one should definitely be able to use values like 10-29, the choice should really be up to people them selfs, not be forced upon them to use these high values.

Why do you make changes to Tor that purposely decreases peoples speed ?
Are you going to implement this bad thing in the stable version too ?

You're right that in the older versions you could configure it to prefer the
circuits that completed faster. Letting users set it too low is a bug: if
everybody did that, the relays would get overwhelmed with circuit creation
requests, making everything slower, and leading all the Tor clients to
unwittingly launch DoS attacks on the network. We can't allow that.

The right answer is to have every Tor client automatically track how long it
takes to build circuits, and then discard circuits that take more than a
standard dev above the mean. For more details, check out Section 5.2 of the
performance.pdf document I posted about here:
https://blog.torproject.org/blog/why-tor-is-slow
and also proposal 151:
https://git.torproject.org/checkout/tor/master/doc/spec/proposals/151-p…

We hope to have this dynamic-timeout-calculation feature in the Tor 0.2.2.x
series. In the mean time, let's all try not to make the Tor network fall over.

Anonymous (not verified) said:

May 18, 2009

Permalink

Thank you for your answer.

According to Figure 5 in the performance.pdf around 85-90% of the circuits are created within 7 seconds, and around 70% within 5 seconds, so could you please allow people to choose values of 5-10 seconds for CircuitBuildTimeout in coming Tor versions.

Otherwise you would create an unnecessary security risk for people that either would have to accept higher risk for timing attacks and similar or be forced to use an old insecure version of Tor, both a bad thing of course.

This should be allowed at least until you fix this new approach in the coming 0.2.2.x or later versions.

Anonymous (not verified) said:

May 19, 2009

Permalink

Regarding the ExitNodes feature:
"ExitNodes node,node,...
A list of identity fingerprints or nicknames of preferred nodes to use for the last hop in the circuit. These are treated only as preferences unless StrictExitNodes (see below) is also set.

StrictExitNodes 0|1
If 1, Tor will never use any nodes besides those listed in "ExitNodes" for the last hop of a circuit."

Do I understand correctly that ExitNodes DO NOT WORK with either:
1. Country codes like {de} or {us} OR
2. comma-separated nicknames like: berwick,NoMoBushWars,innerspace...
???

Can anyone confirm this? Does anyone have experience with the ExitNodes feature actually working anywhere?

Thanks!

Anonymous (not verified) said:

May 21, 2009

Permalink

O.K. I just tried this:

In the torrc file located at:
C:\Documents and Settings\Username\Menú Inicio\Programas\Tor\torrc

I am adding these commands to the file, just before "#ExitPolicy accept:"

ExitNodes {us}
StrictExitNodes 1

Save changes. Reboot my Windows XPSP2

Bring up Tor, connect.

Go to http://internetfrog.com

It tells me that:
The Location of Your IP Address, 213.112.108.203, is:

-, - - SWEDEN

What am I doing wrong?

Thanks!

You are not doing anything wrong, it's TOR that has, shall we call it a bug in the way it works when choosing/avoiding nodes according to country,
As far as i understand it, you have to have a file in your tor-map with the name geoip. Tor/Vidalia is not creating this file for you(at least not in windows), you have to create it yourself, if you have created this file and it does not already have data for the IP that vidalia/tor wants to use as exit(,entry or middle) it will use the IP without checking first if it matches the condition you have set up.
Please change this now so that Tor NEVER use an IP that you don't have info about in geoip file, if you use any countrycode commands in any of these torrc commands: ExcludeNodes,ExcludeExitNodes,EntryNodes,ExitNodes.

Tor Browser Bundles do not come with the geoip file, yet. So exitnodes by country won't work.

It appears the geoip file for the Vidalia Bundle for 0.2.1.14-rc wasn't included in the package.

And yes, in order to choose by country, you have to have the geoip file working.

Anonymous (not verified) said:

May 23, 2009

Permalink

Thank you for your answer.

What i want to know is:
Were do i get this(complete) GeoIP file in a format supported by Tor/Vidalia ???
So that my Vidalia/Tor always respect my configuration in torrc.

Why is the GeoIP file not included ?

If the file is not included, why don't you ask the user during installation process if they want to download the complete file or if later a user has any GeoIP-dependent command in his/hers torrc-file why don't Tor/Vidalia then ask/download the complete file if user wants that.

The lack of geoip file in the vidalia-bundle for 0.2.1.14-rc is a bug. Normally, the geoip file is in the vidalia-bundle packages.

You can download the geoip file from http://git.torproject.org/checkout/tor/master/src/config/geoip

You want to put it in your Data Directory, which is
"C:\Documents and Settings\{username}\Application Data\Tor\" by default.

Anonymous (not verified) said:

May 23, 2009

Permalink

Thank you very much for the GeoIP file, now i feel a litte bit more secure as a Chines concerned about the Tibetan people.

Hopefully i can now avoid the Chines governments Tor nodes in the future.

Anonymous (not verified) said:

May 23, 2009

Permalink

On the ReleaseNotes for version 0.2.0.30 - 2008-07-15 its stated that - Tor now includes an IP-to-country GeoIP file. I find that hard to believe as version 0.2.0.30 even is smaller than the previous one.

"It appears the geoip file for the Vidalia Bundle for 0.2.1.14-rc wasn't included in the package."

Ever since the release of version 0.2.1.6-alpha - 2008-09-30, the first one supporting per-country relay selection, no versions(0.2.1.6A - 0.2.1.14RC) of VidaliaBundle have included this geoIP file how could you then say that they support this function, when it's not working without the missing geoIP file !!

With StrictExitNodes 1 set then....

2 is the alternative that works most of the times, sometimes it mysteriously disregards from the condition you have setup thou.

1 is not working if you don't have made an geoip file or an older tor version(0.2.1.14 is the one that's working best so far), but even with an geoip file it's not going to work with nodes that are new of have dynamic IPs since you don't have any data before, then tor disregards from your setup and uses a node that might be against what you have setup.

Anonymous (not verified) said:

May 22, 2009

Permalink

Thanks for the "country filtering" on exit nodes. (Assuming it works fine on Linux as I have no problem to update/import geoip file)

Do you plan to add the same feature for exit policy for those who are so kind to accept to be an exit nodes.

As more and more countries are voting laws to filter the internet, the lack of such a feature could dicourage people to run an exit node, and at the end of the line TOR will be useless due to network congestion on too few exit nodes.

You already have the ability to filter where you want your exitnode to connect if you for example wants to block the Country: AMERICAN SAMOA you simply block there 4,096 IP adresses by adding:
reject 202.70.112.0/20:*
Not to complicated ?
Also those countrys are kind enough to do the job for you by providing false DNS information for the adresses they claim do something bad.

Anonymous (not verified) said:

May 23, 2009

Permalink

Sorry, but looking at the geoip file, it does seem so simple to block a country.
I transformed the GeoIP to XML and sorted nodes to random country.
For one signle country, I easily end up with more than 10K ranges to reject.
Might be simpler for U.S. because of IANA IP dispatching, but U.S. is not the only country in the world ;-)
So if I try to inject 10K block/accept ranges to TOR... I doubt it would be very glad !.. I might even reach internal limits and disrupt the network publishing so many exit block ranges.

Blocking a small(internetwize) country is easy maby 1-10 lines needed, medium country's 10-100 lines & the large ones needs 100s or even 1000+ lines like the USA, Germany, UK and so on, basically they don't want you as a private person to block a whole (large) country. It would of course be very easy for someone like a NSA field agent and so on to have a precompiled blocklists if they would need to use the TOR network.

Using blocklists of 10000+ lines do work(unless you have a computer from prehistoric time), just try and see for yourself.....

Anonymous (not verified) said:

May 24, 2009

Permalink

Ok then.

I'll improve my XSL transform so that it gives me an output I can just paste to /etc/torrc in order to block/accept countries.

Anonymous (not verified) said:

May 24, 2009

Permalink

Yes I mean "exit policy" for those who accept to donate bandwith AND be and exit node.

Fact is that filtering exit policy against ports is not reliable.

One could parameter it's P2P software to run on port 443 or even 80. So if you accept to run an exit node and allow these ports, you could as well end up appearing as participating in illegal P2P which is bound to prosecution in more and more countries.

So I'll be more confident to run an exit node if I can ban those countries.

Other possible improvement would be to be able to filter against protocol, eg HTTP for example, as Wireshark can do. That would be more reliable.
Of course one can use HTTP Tunneling, but then he will need another HTTP server, outside TOR, to "unpack" what was tunneled and go to the real target.

And thanks for the link, I'll fil some "feature requests".

I don't think you can solve that entirely by filtering some country's like RO,BG or whatevet you had in mind.

If you have a long list of countrys you would like to ban you would have to get iplists from several reliable sorces, merge them together & end up with 100-1000s IP blocks
or you would have to overban IPs by using whole x.x.x.x/8 blocks to get the list down, maby you should go for only being entry+middlenode until your country gets an resonable policy against Tor nodes.

Anonymous (not verified) said:

May 27, 2009

Permalink

So I tried (assuming geoip bundle with TOR is the "reliable" source) blocking FR + unallocated gives me 19K lines of
ExitPolicy reject so.me.ip.addr

Side effects are :
- starting TOR or Vidalia take 100% CPU for around 1min
- In /var/log/tor/log I get messages :

[warn] router_dump_router_to_string(): Bug: descriptor policy_write_item ran out of room!
[warn] router_rebuild_descriptor(): Bug: Couldn't generate router descriptor.

So definitely no, trying to feed so many rejects in TOR doesn't properly work !

And by the way... if you though listing exactly US IP gives a small result, you are very wrong... I get 27K lines of rejects !

So you're right, as long as such a behaviour is not implemented as it is for ExitNodes, I'll go down running as only entry+middlenode.

... and I have more accurate data to post to the bug list now !

US is the country with most IP ranges of cource.

Tor's GeoIP is not a reliable source, but it's better than nothing...

The GeoIP is by nature not 100% reliable data, you have for example a number of very fast nodes on Tor network that has fake country for there IP.

The data for your CountryIP can easily be faked if you have static IP

Go for country IP instead, source for both where ISP is located + where internet access is located.

one source gives for FR:
# Total Networks: 1,848 = you should have about 1.8k lines for FR
# Total Subnets: 68,933,568 = and about 68.9M IPs for FR

You could decrease the list by overblocking IP series with many separate blocks on insead of using all those one's.
For France you could for example block 193.0.0.0/8, 194.0.0.0/8, 195.0.0.0/8... instead of
193.0.128.0/18,193.0.192.0/19,193.0.245.0/24,193.16.156.0/24,
193.16.159.0/24........

" [warn] router_dump_router_to_string(): Bug: descriptor policy_write_item ran out of room!
[warn] router_rebuild_descriptor(): Bug: Couldn't generate router descriptor.
So definitely no, trying to feed so many rejects in TOR doesn't properly work !"

Do you only have small amount of memory on your computer ?
How many blocklines is it accepting and how much memory do you have installed ?

>> one source gives for FR:
>> # Total Networks: 1,848 = you should have about 1.8k lines for FR

Your approximation is correct. In the GeoIP file I have, it leads to 1970 lines for France.

>> Do you only have small amount of memory on your computer ?
> >How many blocklines is it accepting and how much memory
>> do you have installed ?

Not at all. I have 4GB and only 800MB used from my Ubuntu running full of services (Apache, MySQL, OpenVPN,....)

ps -aux | grep tor

Gives me a strange 98,8% memory used for TOR process.
Could there be a parameter so that it allocates more memory at TOR startup ?

I did also have a warning about rising file handlers (ulimit) to 32K (don't have the exact text I did a rm /var/log/tor because logs where growing too big to be readable !)

Tor obviously handles these exitpolicys worse than the internal policy's in clients torrc on your OS, it's strange, probably they don't want people to use that kind of large exitpolicyfilters.

The blocking of all the small unallocated IPranges would probably be the problem, are they giving you 17800 ranges
and the actually now allocated to FR according to the geoIP you use 1900 ranges.
or is the geoIP file wrongly giving you 19700!! ranges for France.

Anyway solution skip the blocking of small unallocated IPranges
use an Country to IP list for determining what to associate with FR, block these IPs, you should get around 1850 IPranges.
if Tor can't handle these either simplify the blocking policy by overblocking.
France have for example ~440 IP ranges on the 193.x.x.x range , blocking the whole 193.0.0.0/8 would decrease your list to ~1410 IPranges.
France have for example ~500 IP ranges on the 194.x.x.x range , blocking the whole 194.0.0.0/8 would decrease your list to ~910 IPranges
France have for example ~140 IP ranges on the 195.x.x.x range , blocking the whole 194.0.0.0/8 would decrease your list to ~770 IPranges
France have for example ~80 IP ranges on the 91.x.x.x range , blocking the whole 91.0.0.0/8 would decrease your list to ~690 IPranges
France have for example ~80 IP ranges on the 217.x.x.x range , blocking the whole 217.0.0.0/8 would decrease your list to ~610 IPranges
Keep doing this until you have a number your Tor client accepts.

I saw you where using the "stable" version 0.2.0.34 have you considered trying the Alpha/ReleaseCandidate version series maby the 0.2.1.15RC handles these things better?

Anonymous (not verified) said:

May 29, 2009

Permalink

I saw you where using the "stable" version 0.2.0.34 have you considered trying the Alpha/ReleaseCandidate version series maby the 0.2.1.15RC handles these things better?

Anonymous (not verified) said:

June 03, 2009

Permalink

I haven't try yet doing the same with 0.2.1.15RC

At the moment I just took it from the launchpad TOR-Team repository.

I think I might get a try... if weather is bad during my next holidays... to understand the code, and do-it-myself, blocking by country.

But of course, supposing I get to something, it cannot be commited to trunk development like that as protocol has to be changed to say "Hi, I am an exit node that blocks {PL}, {HU}, and accept {CA}"

santiago (not verified) said:

September 15, 2009

Permalink

I am using

StrictEntryNodes 1
EntryNodes thenode
StrictExitNodes 1
ExitNodes thenode

Can I set up for example the relay ?

StrictRelayNodes 1
RelayNodes thenode ?

Thanks

ali (not verified) said:

November 13, 2009

Permalink

  • ILGIN Ajans haber
  • Siir Guzel Soz Hikaye Ask Mektuplari
  • Oyun oyna Flash Oyunlar
  • Yedemin ilan Deposu
  • Tatil Gezi
  • Tatil Gezi
  • Canli Spor

    • da

  • Spor Haberleri
  • Ulusal Haber
  • Ajansnlar
  • ILGIN HABER
  • Kaplıca Termal Sağlık Şifa Rehberi
  • Fanatik Spor Haberleri
  • Taraftar Spor Haberleri
  • Film Dizi Belgesel Albüm Yaşilçam Filmleri
  • Türkçe Altyazı Altyazı Çevirileri
  • Sinema Vizyon Filmler
  • Film Seyret izle Dizi Seyret izle Online
  • Dizi Film izle seyret
  • Vizyon Sinema Film izle seyret
  • Fragman izle seyret
  • Sosyal imleme
  • Haber Column
  • Örgü Elişi Dantel Oya Örnekleri Modelleri
  • Diyet Egzersiz Zayıflama Sağlık Güzellik
  • Resim Boya
  • Vizyon Sinema Vizyondaki Filmler
  • Vizyon Filmleri İzle Seyret

    • Anonymous (not verified) said:

    January 09, 2010

    Permalink

    adasd

    Anonymous (not verified) said:

    January 19, 2010

    Permalink

    Thank you very nice post.very good thanks

    dizi izleme sektörünün yeni lideri olmak için yola çıkmıştır bu sitemizde ise dizi izlenir ve dizi seyret vardır. en iyi dizileri son bölümleri online izleyebilirsiniz.ve online dizi izleyebilirsinizkurtlar vadisi pusu izleyebilirsiniz.aşkı memnu izleyebilirsiniz.ezel izleyebilirsiniz.tüm bölümleri izleyebilirsiniz.son bölüm izleyebilirsiniz.online dizi izleyebilirsiniz.canlı dizi izleyebilirsiniz.full dizi izleyebilirsiniz.aşk ve ceza izleyebilirsiniz.geniş aile izleyebilirsiniz.bölüm izleyebilirsiniz.dizisi izleyebilirsiniz.
    oyun oynayabilirsiniz.

    Anonymous (not verified) said:

    January 20, 2011

    Permalink

    I would appreciate your help in solving this problem. TOR running perfectly before, now I am getting these error messages:
    No specified exit routers seem to be running, and StrictExitNodes is set: can't choose an exit.
    failed to choose an exit server

    Vidalia: 0.2.7
    Tor: 0.2.1.25
    Qt: 4.6.2
    Firefox 3.6.13

    Thanks for any assistance you may provide.