Re: SIGHUP without effect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Hans, Scott, Hans Schnehl wrote: | What I tried to achieve is getting closer to the servers upper limits | in bandwidth/performance, therefore publishing descriptors with different | bandwidths, sometimes within relatively short times. What I did not know | is the authorities' not accepting so called 'cosmetic' changes within a | certain timeframe. This is perfectly logic and makes sense, explains | most my observations, though not all. Correct. dir-spec.txt says that relays generate and upload a new router descriptor when: - Bandwidth has changed by a factor of 2 from the last time a descriptor was generated, and at least a given interval of time (20 mins by default) has passed since then. (They further do in other situations, but this is the only one that is bandwidth-related.) The directory authorities perform the same check when deciding whether or not to store a router descriptor. But you are right, this doesn't explain why Tor should stop publishing descriptors afterwards. Scott Bennett wrote: | I first noticed that traffic had dropped to only a few, occasional | packets per second (not even every second). I then checked the most recent | consensus and status documents and found that MYCROFTsOtherChild was missing | from them. What log statements did you have in mind? Perhaps something like | Oops! I forgot to upload an updated descriptor, so I'm going into hiding? | It forgot to do it, so it had nothing to log. Ah, that's reasonable. Well, log statements are my primary source to see that something is going wrong. So in this case I wondered which log statement might have lead you to your conclusions. I didn't find one that was directly related, so I asked if there was another one I might have overlooked. After all, it could be something like There is something wrong with the descriptor I just wanted to upload, so I'll try again later (or something similar). So, it makes sense to turn on logging in this case (probably even on debug level) to track down this bug. | That was the next thing I | checked. If left unmolested, tor normally uploads a new descriptor to the | authorities about every eighteen hours, but if it forgets to do that, then | that's pretty much the death knell of its usefulness until it has been | restarted. Giving it a SIGHUP at this point does not then cause a new | descriptor to be uploaded, apparently regardless of ExitPolicy changes. Just to get this right: You changed your configuration once or multiple times to force Tor to upload new descriptors, and at some time later (about 18 hours) you realize that it has stopped publishing new descriptors, correct? At that point even changes to your exit policy don't make Tor publish a new descriptor any more, but you have to restart it. (All of this should be fine to do, I'm just trying to understand what is happening.) Okay, I'll try to reproduce the bug myself and have a second look at the code. However, if either of you finds out information that might help in finding this bug, please share. Thanks! - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImcLR0M+WPffBEmURAo9mAKCXg+7aQqQW4xdkP2cPIGVrY7NG9gCfQauy a3T02ufl9vCEXqt14jt0p/I= =2PjA -END PGP SIGNATURE-
Re: questions about MinUptimeHidServDirectoryV2 in 0.2.1.2-alpha
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Scott, Scott Bennett wrote: | The default of 24 hours ensures that hidden service directories are | available for the next few hours with a certain probability. The idea is | that there are hundreds of hidden service directories at some point | which are not authoritative any more, but provide a more scalable and | robust storage than the three authoritative ones can. Hidden services | and clients need to have a view as consistent as possible of which | hidden service directories are out there, so that clients can find | previously stored hidden service descriptors. The 24 hours have turned | | How is that different from the situation of normal directory mirrors? The big difference is that every hidden service directory is responsible for a certain set of hidden service descriptors and not all of them. If you run a hidden service you determine six responsible hidden service directories depending on a) the onion address of your service and b) the node identities of the hidden service directories. Then you store your descriptor on exactly those directories. Your clients need the same or at least very similar information about hidden service directories as you have. If their list of directories contains further directories or misses some of those that you know, your clients will end up requesting your descriptor from the wrong directories. A further difficulty comes from the fact that your clients and you might use consensuses with up to two hours time difference. A certain number of differences is tolerable by performing replication, but these shouldn't get too big. | In other words, it is already covered by the Guard and Stable | flags from the authorities, right? These flags have different purposes, and their definitions might change in the future (as might the definition of HSDir). Apart from that there needs to be an HSDir flag anyway to denote which relays want to participate in the hidden service directory. Admittedly, a further evaluation could compare the approach taken here with your approach to derive usefulness of a hidden service directory from Guard and/or Stable flags instead. Honestly, I don't know what the result would be. Seems that there's always work left to do. ;) | http://freehaven.net/~karsten/dirnodesminuptime.pdf | | It's very pretty, but, given the legend, which I assume denotes | uptimes in hours, the axis labels are not helpful. What exactly do | Directory Size and Time Index refer to? Directory Size refers to the size of the distributed hidden service directory, assuming that *all* relays that have their directory port open work as hidden service directory. Of course, this number differs significantly from the current number of hidden service directories. That's why one proposed change of proposal 143 (which is planned to be implemented in 0.2.1.x) is to make all relays with open dir port act as hidden service directories by default, with the possibility to opt-out. Time Index is admittedly a bad axis description, which however comes from the fact that I didn't know how to write month names at the appropriate places of the x axis in R. :) The x values denote the hours of evaluated consensuses between mid-January and end of March. The peaks that you see for minimum uptimes, e.g., of 4 to 16 hours are the days in that interval. Now compare the peaks of using no minimum uptime at all with those of requiring an uptime of 24 hours. If there would be no requirement for minimum uptime, replication would have to be increased significantly. | The option MinUptimeHidServDirectoryV2 is mainly there to perform tests | with the distributed hidden service directory without having to wait for | 24 hours. It is not required to set it in the public Tor network. (It | only has an effect on directory authorities anyway.) | | I understand that, though it is also useful for the operators of the | current authorities should the policy change. What I still don't see is | the need for a 24-hour delay before a server stops being only potentially | useful and becomes actually useful. Earlier today the HSDir count was | down to only *4*. How is it thus helpful to keep other servers from being | available for use? I think I have already answered these questions above. If I should have left out something, please ask. Hope this helps a bit more now. :) - --Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImcwL0M+WPffBEmURAiUkAJ9MIRiesdLEenA9BxSJJ4T6mC2fZACfYWNT 2Net1ADWsE/ywa7V1l4Iqtw= =IlPj -END PGP SIGNATURE-
Re: Abuse statistics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [EMAIL PROTECTED] @ 2008/08/05 07:24: So the profilers feed the spammers? :-) what's with the happy face? you get a kick out of this, playing detective? most of us already assume this is happening. we don't need your statistics. as is said in the FAQ, criminals already have better ways of doing things without Tor. -BEGIN PGP SIGNATURE- iD8DBQFImj2EXhfCJNu98qARCBiaAKCnLts9wbkAWrZg3Uk0F3+5XmketQCfZfvn 0qjxJlLaO5FHCjoQ6jjisro= =P3O3 -END PGP SIGNATURE-
