Re: [tor-relays] Politically correct?
On Fri, Oct 07, 2016 at 10:25:31PM +0200, torser...@datakanja.de wrote: > for simple - political - reasons, i began contributing otherwise wasted > bandwith to the tor network about half a year ago. And i am reading this > list. > If not, i am seriously reconsidering the futile attempt to engage into > offering something to the net, that could lead to unveiling users > activities opposed to what tor seems to promise. Tor currently has its place at low-level privacy only (research other corporations, and you are sitting in a competitive corporation, for example), and perhaps a little darknet research, all only as long as larger adversaries such as the USA or other Goverments are not entities you must hide from. For the future: - if you don't own it, you don't control it - if you don't control it, it -will- be used against you So, for longer term, we must build our own physical internet - N2N or Neighbour to Neighbour network. One has to start somewhere, so your local residential street, corporate offices, etc. - build out your own nodes, volunteer to do this for your corporate partners and / or neighbours. Encourage others. Spread the word. When 'the community' properly gets going in this direction, it'll probably be a good 10 years till we actually have widespread alternative physical networks, upon which Tor, I2P or future alternative virtual networks can be designed to work with, to increase privacy beyond what is possible today. We start now, from what we have (our current status) as of now. Might seem silly to say this, but some folks balk at "our own phy network" saying "that's too big, we'll never get there" etc etc. Which is simply counterproductive and false fatalism, and arguably subversively undermining. Remember to enjoy the journey :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] #torstrike
I concur with all you say below. Exceptionally well spoken. Evidently you have some solid experience in your corporate managerial role. Thanks for speaking up. On Sun, Aug 21, 2016 at 11:50:37PM -0700, Arisbe wrote: >Okay, so I've been concerned about the safety of at-risk Tor users since > all this shit broke. New employees at the >organizational structure serving as the main accuser, an all new board > with interrelationships and motivation >unknown, grenades rolled under office doors and all of the rest leaves a > bad taste in my mouth. I cannot, at this >time, recommend to a third world citizen, that (s)he trust the Tor > network. I hope that changes. >The issue is whether or not someone new in the Tor organization will, > accidentally or intentionally, put third world >users at risk. I cannot trust an all-new board. Tor needs to be on their > best behavior in order for me to >re-establish trust in the organization. >As a retired corporate manager I've seen these problems before. I have > several suggestions that I feel are must-do >tasks for the Tor Project: >1) Secure an independent investigator to look into the allegations > against Jacob. Either demonstrate that he is not >an honorable employee or reinstate him. No one should trust anonymous > claims that can ruin his career. If Jacob is >guilty, he should be prosecuted; >2) Board member should be open, accessible and available to employees and > node operators. Their background and >motivation for being a director of the Tor Project should be disseminated. > There interrelationship with other board >members should be known; >3) As one of the founders of Tor, Roger should openly discuss these and > all issues in a public manner (on the web >page, webinar, magazine article, etc.); >4) An organizational plan should be placed in the employment manual that > puts significant distance between coding >employees and directors; >5) Employees and directors should not operate nor have access to > authority servers. >I've operated a number of exits and guards for several years now > (including, as far as I know, the only Tor node in >Albania). [1] I will leave these operational for now but I expect changes > in this unprofessionally operated 501c3. >[1] > >A827646DD0F8B92A9963789529CEE3141FF74761 >4061C553CA88021B8302F0814365070AAE617270 >C80DF89B21FF932DEC0D7821F679B6C79E1449C3 >9B31F1F1C1554F9FFB3455911F82E818EF7C7883 >D3E5EDDBE5159388704D6785BE51930AAFACEC6F ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] #torstrike
On Sun, Aug 21, 2016 at 07:53:26PM -0600, Marcel Krzystek wrote: > ​What are the thoughts of relay operators on this? > https://ghostbin.com/paste/kmnzz > > I can be persuaded otherwise, and perhaps i'm being naive, but i believe > that operation of the network should remain independent from the politics > within the organization. Hi Marcel, Fact: Jacob Applebaum's directory authority was a target of NSA's XKEYSCORE: https://contraspin.co.nz/the-weaponising-of-social-part-3-the-resurrection-of-ioerror/ Fact: Jacob Applebaum got kicked from Tor Inc, prior to a proper investigation. Fact: The investigation done by Tor Inc, was run by the primary accusers of Jacob Applebaum. In the USA's war against Bradley Manning, Julian Assange, Wikileaks and Edward Snowden, Jacob Applebaum was a very high target, and caused the three letter agencies a lot of problems. So yes, operation of the network you use for -genuine- privacy needs, is very much dependent on those running the organisation. Fact: The ENTIRE board of Tor Inc got replaced after Jacob was given the boot! My conclusion: This was a coup, blunt and bloody, take no prisoners, respect no righteousness. My conclusion: The operation of the Tor directory authorities can no longer be trusted. My conclusion: The deployment of TBB by Tor Inc can no longer be trusted. Draw your own conclusions. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] suspicious "Relay127001" relays
On Tue, Jul 05, 2016 at 05:10:49PM +0200, Niklas K. wrote: > It's up to directory authority operators to deal with > suspicious/rogue/misconfigured relays by marking them as > invalid/rejected/badexit. > > Relay operators are not supposed to decide what other relays they may be put > in a circuit with (apart from notifying the network which nodes belong to the > same operator using MyFamily as you mention). > > FYI, *clients* do have the ability to exclude nodes using the ExcludeNodes > directive. In good news, 91 new high speed exits means Tor network should be truly blazing for a while :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts
On 5/20/15, s7r s...@sky-ip.org wrote: On 5/20/2015 12:07 PM, Tor User wrote: If I'm wrong about this, that's great - I'd love to see some documentation to explain it better if you have any links handy. But if I'm right, how can I configure our TBB clients to actually MAKE them use our TOR proxy as their entry node? I do not see any benefits in using a Guard on your local network, I just don't see the point of it. You can do the following: 1. The centralized Tor server, as explained above, means you have to run only one Tor instance for all the computers in your network. This means you don't need Tor on all of the other computers in your network, and the entry point (Guard) needs to be defined on the Tor I think the OP wants to treat their centralized Tor server as though it is a guard, which is why the term centralized Tor server perhaps clarifies the OP's thinking. As you highlight, with a centralized Tor server, a separate (local LAN) entry guard server doesn't make sense. centralized server (in your case relay) only, and it will affect all the clients in the network using it. You will not be able to see circuit info (such as path) on the computers using this centralized Tor server because they won't have access to the Tor control port, which is totally normal. The thought still lingers though - if one were to run TBB or a Tor node on each computer in a LAN, and treat the centralized Tor server as an entry guard by some manual configuration: a) This should be doable, workable, and be just fine/ok or in fact even better than having all local/LAN computers access Tor/internet through the SOCKS proxy of the centralized Tor server, b) It should be possible to set up such a configuration manually - force the centralized Tor server to be my (random LAN PC with tor instance eg TBB) entry guard to the Tor network, even though it does NOT have the guard relay, assuming I am the LAN admin, or that I trust the LAN admin, c) It should be better for security of each LAN PC - since they are sort of participating natively in the Tor network, since they begin their own hop in/at their local PC, and so don't have to rely nearly so much on the LAN admin and the SOCKS proxy running on that centralized Tor server - is getting from my PC to a SOCKS proxy on some other PC even secure at all, or is some other security layer now needed to protect/hide agains LAN eavesdroppers?, d) Because each LAN PC has its own tor node (eg TBB with manual config), they can see their full circuits in the wider Tor network - with all circuits always beginning at the (manually configured) centralized Tor server configured as my permanent Tor network entry guard node, e) TBB just works from a all the various Tor project customizations for Firefox are baked in, it's much harder for me to f*** it up somehow - and I think this is one of the most critically important benefits that should not be so readily discarded with: On the computers in your network you can just use Firefox with some privacy plugins and route all traffic (including DNS) through the polipo proxy, running on the Tor centralized server / relay. since just install some privacy plugins and route DNS through SOCKS/polipo can so easily fail big time! If there's any chance of adversarial eavesdropping or browser attacks, surely you want to start from a just works as far as most Tor devs are aware within the known limits etc position, and add the minimal browser config/ manual Tor config on top of that? What happens when a TBB security fix comes out - does one assume that normal firefox does not need that? Does one assume that a normal firefox upgrade, in the face of the full set of manual TBB like customizations (assuming you even implemented them all, and implemented them all correctly) and that you do -not- need to do a full firefox reinstall? There are SO many unanswered security questions for an end user (or LAN admin trying to be responsible on behalf of their LAN PC users) that I feel it is dangerous to suggest something other than use TBB, with absolute minimal manual config on top, e.g. disable Javascript :)! ... Want a centralized Tor server and a Guard relay at the same time? Just run the relay someplace else, and use StrictNodes and EntryNode on that server. I doubt this is what you want since you installed Tor Browser on the computers in the network as well. TBB, albeit with some (hopefully minimal) manual customizations, ought be the recommended way by my reasoning... the only question is how to achieve a sane setup, optimizing for a particular scenario - in this case, the OP is optimizing for a LAN environment in which it appears that the OP may be the admin, and therefore that the OP has a certain trust in him/her self :) It might, just possibly, also be the case that other individuals who use that LAN environment, place some level of trust in their LAN admin too. In the face of even a minimal level of additional trust which is
Re: [tor-relays] Subpoena received
On 4/21/15, Dave Warren da...@hireahit.com wrote: On 2015-04-20 10:31, Speak Freely wrote: A foreign sovereign can command anything to anyone... without a reasonable expectation that anyone will follow it. Even in Canada, I am not obliged to respond to American subpoenas unless and until my government commands me to. Only your sovereign can command you to do anything. A foreign sovereign has zero right to anything outside of it's own purview. Keep in mind that if you do respond at all, the US court may claim to have waived jurisdictional arguments and consented to the jurisdiction, in which case a court order can be enforced cross-jurisdictionally in certain cases. Spamhaus learned the hard way when they hired a US lawyer to represent them and that lawyer responded incorrectly and enabled the lawsuit to become binding upon themselves despite the lack of physical presence within the US. While they ultimately prevailed on their appeal to the greatest degree still available, they were unable to vacate the default judgement entirely (only the amount), so while they ended up paying a nominal amount and winning for more useful purposes, they technically lost the case. Had they failed to appeal or lost the appeal, the resulting order would have been binding and enforceable in UK courts because Spamhaus's actions consented to the plaintiff's choice of jurisdiction. This is very interesting. In Australia, consent to give evidence and be cross examined, can later be withdrawn. The principle AIUI (IANAL) is that where consent can be given, and is given, such freedom to give is also the freedom to take away and therefore consent can be removed at any time. To be safe though, I would recommend that any party giving conditional consent to appear, in any jurisidiction including their own jurisdictions ordinarily binding upon themselves, to enter a formal Conditional Appearance, specifically limiting the extent of the jurisdiction consented to, and reserving the right to withdraw consent upon written notice to that court (or any high court if the case goes to any such court on appeal etc). I am quite surprised that Spamhaus's lawyer(s) failed to do this, failed to give conditional consent for Spamhaus to appear in the jurisdiction, failed to formalise Spamhaus' consent to appear, and failed to advise Spamhaus that once given, their conditional (or full, for a time) consent to appear could be withdrawn and that it ought to have been withdrawn, and in fact that the lawyers should have immediately withdrawn Spamhaus' consent to appear when that was needed. I do have a fair idea why Spamhaus' American lawyers 'overlooked' all these things. On the criminal side, you can also be extradited in certain cases. Kim Dotcom is still working through the complexities of this particular situation. So I would highly recommend engaging a lawyer to verify that your actions don't waive any arguments or otherwise consent to anything that can be enforced across borders. The point is, the lawyers that Spamhaus engaged may well have fucked them over, intentionally or otherwise. I highly recommend engaging common sense, verify everything you otherwise assume, and assume your lawyers are not acting in your own interest and need to be micro managed. E.g., insist on the address for service being you and you personally, then send copies of all documents you choose for your lawyer to view, to your lawyer, keeping the originals. Likwise, e.g. having your lawyer send all documents they produce on your behalf, to you, and you keeping a copy before you sending said document(s) to the relevant parties (which may be the court itself). Oh, and insist on a detailed schedule of fees before engaging them. Keep a Strong, Short, Tight leash on your lawyer!! (And no, odds of any of this impacting a simple Tor operator are not very high unless you're otherwise a high profile or high value target) Good luck people :) Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 'relay early' attack detection at the infrastructure level
On 8/2/14, Roger Dingledine a...@mit.edu wrote: On Sat, Aug 02, 2014 at 03:38:51PM +1000, Zenaan Harkness wrote: the RELAY_EARLY cell has common legitimate uses. How can we distinguish an attack from those? Correctly-behaving Tor relays never send RELAY_CELL cells backwards (towards the client) on the circuit. Gah. I should have written RELAY_EARLY above. Sorry for the confusion. So if you see one, it's somebody not following the protocol. Might be a stupid question sorry, but why not just block such relay-early packets coming in the wrong direction? New relays do block them. Actually they close the circuit and warn, since once somebody has violated the protocol like this, it's unwise to let them continue interacting with you. Or is that what you meant? ACK. Thanks. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Oubound Ports
On 7/11/14, Greg Moss gmos...@gmail.com wrote: Thanks for the help. I have my ORport and DIRport defined in torrc and forwarded through the firewall up to the Tor Relay. I was just wondering in regards to outbound traffic from the server itself. What type of tor server did you decide to run (relay, exit, bridge)? I feel you are rushing things a little. Do some more reading. Personally I suggest an exit relay, but without informing yourself first, how can you make an informed choice? An exit may be worse, or better, given your needs/ intentions of what you want to achieve here. In the event it gets compromised I really hate to open all ports outbound let alone possible DNS leaks and what not. Appoligize if this doesn't make since I just fired this thing up yesterday and want to make sure it is secure. You want secure. OK, so does everyone. So what's your threat model? If you are worried about a compromised tor server, and consequent information leaks, perhaps set up whonix? If you are just impatient, just run TBB. If security is genuinely important, and you rush things, you are MUCH more likely to come unstuck. If you are in a time sensitive situation, and (picking a random offtopic thought here :) wanting to do some leaks, the best thing might be to find someone you trust (who is reasonably technically literate), and pass the material to them, ask them to post it to various drop boxes and provide it (anonymously and/ or without any phone calls etc made) to their own trusted friends etc, to get the info out there. Do this with a few different people, if you have trustworthy friends/ contacts. Your situation sounds like you are impatient. Go do some reading, and good luck, Zenaan -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of Zenaan Harkness Sent: Thursday, July 10, 2014 6:47 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Oubound Ports On 7/11/14, Greg Moss gmos...@gmail.com wrote: Newbie to Tor but have a Debian server up and running as a relay. Do I need to filter outbound traffic from the tor server on my firewall. If yes what ports would I need to open. I am also have a good look a Tails any suggestions would be helpful. Sounds like you need your config file to read. Try: /etc/tor/torrc That will likely answer your question (hint, the answer is at least one, inbound and outbound). Do read the material on torproject.org - there's lots of it, and much of it useful to you if you are running a relay, some of it directly so. You might also check out whonix.org Enjoy teh awesome tehclonogy :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays or exits: which is needed?
On 7/6/14, michaelb...@riseup.net michaelb...@riseup.net wrote: I'm (hopefully) going to be running a few high-speed Tor servers sometime in the near future. Which type of Tor server (exits vs. relays) is needed the most right now? I thought there used to be a FAQ on this, suggesting exit relays. I do believe exit relays are the most in demand, and most needed to make Tor enjoyable to use for the broadest number of people. If there is an excess of exits (won't happen any time soon), they can just be used as normal relays anyway, so it is ultimately better for the network to have more exits, at least at this point in time, AFAIUI. Right now all I can find doco wise is: https://www.torproject.org/docs/tor-relay-debian 9. If you run an exit relay (great!), don't miss out on our Exit Guidelines, including setting your reverse DNS hostname to make it obvious that you're a Tor exit relay, and serving the Tor exit notice page on your DirPort. Please do read in detail: https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines as well as everything else of any relevance to you at torproject.org Welcome, and awesome to see solid support for the free speech networks, in this case tor :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On 6/16/14, grarpamp grarp...@gmail.com wrote: On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar jer...@massar.ch wrote: If an operator does not want you on their site, do not circumvent it. You are thus stating: I want to circumvent a site's decision to block me. No, you are still not understanding a (not so delicate, yet very important) distinction... - IP blocking is NOT blocking a particular single user context (ie: 'you', 'me', joe, jane, anonuser1543), it is blocking whoever happens to be using that IP [1]. In my opinion, that is wrong because it takes out innocent users and thus I'm happy to suggest any number of ways to push back against it until this effectively 'anti-innocent' model changes. This is foundational I say - some of us are willing to give up a little (or a lot) of convenience, for the long term benefits/ freedoms which we anticipate and strive for. Today we have an abundance of libre/free software. When Richard Stallman, and later others, sacrificed their time and their statutory proprietary-ownership possibilities, for the long term vision, they did not have the abundance that has since been created - their sacrifice was MUCH greater than ours today. Yet the spirit of sacrifice/inconvenience for the longer term greater good, lives strongly in some of us. I wholeheartedly support those who live this principle. Rock on! Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Usefulness of very limited exit policy nodes?
With the bandwidth level you (Matt) are suggesting I haven't suggested any bandwidth levels. You might be referring to Phil I suspect. :) Sorry about mixing up the thread participants. Should have said OP. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Usefulness of very limited exit policy nodes?
On 5/27/14, Matt Puckey m...@puckey.org wrote: On Tue, 27 May 2014 16:04:00 +1000 Phil p...@urbanoia.net wrote: Opinions please - is it worthwhile running an exit node on a home DSL connection with limited bandwidth and exit policies? It all depends on whether or not you want to 'put up' with the potential 'hassle', which could be slightly different compared to as if it was in a datacenter somewhere. If your ISP is informed that you're an exit node, then great. Just remember, you will be mixing your own personal traffic with Tor traffic, that is the main issue I think you might face. I honestly think that you would be better off being a bridge, especially if you have a change of public IP address every now and then, like most home lines. I read a lot of the torproject.org website before running our exit node, and I found the issues laid out to be reasonable from my perspective - when we believe in something like free speech, or freedom of travel, some of us (like myself) feel a conscientious duty to take a stand to promote that which we believe in, as I did. The website said full exits are needed the most, from the tor network perspective, so that's what I decided to set up. With the bandwidth level you (Matt) are suggesting, I think a full exit would even be fine from that point of view. I ended up cross grading to a business level plan with our isp iiNet (Australia), in order to get a static ip, since the effect of ip changes was too severe on the exit traffic (in my personal opinion) since it usually meant an effective network drop out once a day. Then Telstra (the upstream national/backbone isp) started changing the ip address much more frequently - probably because that had a positive effect on their overall network availability, with minimal customer complaints. So I cross graded and got a static IP. There was a brief day or so when Telstra's ip changing came back into play, and an incorrect ip was being alternately assigned to the correct ip address. Once that was sorted, the connection (gracemissionstor fwiw) has been pretty rock solid, except for the occasional rural power outage we experience. Oh, when I cross-graded, I did speak at some length with the iiNet tech guy about our intention to run our free speech node being a TOR exit node, how that helps wikileaks and various minorities around the world to experience a level of freedom of speech which is not otherwise possible. They were cool with that. So, primarily I recommend: Speaking with tech support of your isp, and ask them some question about running a tor free speech exit node and are there are any issues you need to keep in mind when you set that up on their network. In this way, you begin to build a relationship of open communication and readiness to respond to any issues that may (or may not) arise. Make sure you are diligent in the guides/recommendations on the torproject.org website, such as having a valid contact email address etc etc. Good luck :) Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay recommended upgrade procedure?
On 3/19/14, Zenaan Harkness z...@freedbms.net wrote: On 3/19/14, Moritz Bartl mor...@torservers.net wrote: You should add the torproject repository, and then just let it upgrade whenever there is a new version. There's no need to reboot or wait, having the upgrade process restart the service is fine. Your relay will not lose its flags during short downtimes like that. Thank you, I did that. The Debian install script evidently gives tor 30 seconds to disconnect, since it did stop tor after 30 seconds. Then it went through the normal upgrade process, I kept my existing config file and voi la - tor was no longer running! This bit does not seem quite optimal - surely tor ought to have been auto restarted. Anyway a quick service tor restart started it again and yes, flags intact. HOWEVER: killing tor in 30 seconds seems to me a little harsh on all those anonymous connections that were previously going through my exit relay. Can those clients (if they need) pick up their connections after about 3 minutes? It appeared that all connections were completely gone when I finally got tor restarted, which makes sense but: Is there are a gentler way such as don't take new connections, notify clients we are going down for an upgrade but allow continuation for say up to 10 or 30 minutes? There is of course MaxAdvertisedBandwidth - so ought this option be set to say zero for say 10 or 20 minutes, before stopping/upgrading the server (either manually by admin, me, or assuming admin config allows this)? Would that be better or could that be worse eg for privacy, correlation attacks etc? Should I forward this question (or rather, create a thread) optimal tor relay upgrade protocol on tor-talk? TIA Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay recommended upgrade procedure?
HOWEVER: killing tor in 30 seconds seems to me a little harsh on all those anonymous connections that were previously going through my exit relay. Can those clients (if they need) pick up their connections after about 3 minutes? It appeared that all connections were completely gone when I finally got tor restarted As soon as your relay goes away the circuits will be cut, and the streams that clients had on those circuits will be cut too. Whether those clients will automatically reconnect those streams on new circuits depends on the application. Is there some longer term sense in having a SOCKS protocol enhancement to have the SOCKS/TOR server notify applications connecting through it, that it intends to shutdown the relay/socks facility at X minutes into the future? In the tor relays itself, this would of course need some TOR control channel or protocol where the 'relay reboot in X minutes' gets propagated back to the end users of the channels through this relay/ exit node. Although 'reconnect' is robust enough, prima facie, a little more niceness for the users would be a good thing, I'd think. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] log: Error binding network socket to 203.217.31.172: Cannot assign requested address
From here: Mar 27 16:50:35.000 [warn] Error binding network socket to 203.217.31.172: Cannot assign requested address to here: Mar 27 23:56:46.000 [warn] Error binding network socket to 203.217.31.172: Cannot assign requested address I got 828 of those messages. Why no socket number, or more information in the logs to debug this? Although it only happened in that time frame above - not happening any more. TIA Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] log: DNS servers not contactable (but only for a few seconds)
Notwithstanding the short DNS outage as shown in the logs, I added a couple of extra Australian DNS servers to resolv.conf since previously I only had the primary and secondary DNS servers as assigned by the ISP. Just wondering if there's anything else I should do to increase robustness on this front. TIA Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Are zealous connections to directory port common?
On 03/10/2014 01:14 PM, Tora Tora Tora wrote: I just recently allowed the directory ports of my relay to be listed and noticed that some IPs are a bit overzealous in connecting to the directory port. As in 108 connections within a minute zealous. Is this unusual? I think it is unusual. Are you just checking the tor log to see this? Anyone knows the answer? It happened again with another IP establishing 400+ connections to directory port within a minute. Me thinks it was not a good idea to display the directory port. Maybe try installing some ip blacklist or dynamic firewalling? rblcheck is a debian package which may be relevant. Maybe time to do some more research... Good luck Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Are zealous connections to directory port common?
On 3/14/14, Tora Tora Tora t...@allthatnet.com wrote: On 03/13/2014 09:37 PM, Zenaan Harkness wrote: I think it is unusual. Are you just checking the tor log to see this? OK, so I am being DOSed then. Sorry I can't say, it just doesn't sound right. I've only run a relay for a few weeks, and down the last week. Good luck Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-relays Digest, Vol 38, Issue 6
On 3/5/14, herojide...@live.com herojide...@live.com wrote: PLS how does relay work and how can I set up my system to work with relay You need to read the docs. Go to torproject.org and start there. If you don't yet use GNU/Linux you might try Fedora or Debian but probably _don't_ change OS _and_ start running a relay at the same time. Although it's not 'hard', there is a learning curve. Good luck, Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] procedure for TBB to use localhost relay
I am running a tor relay - gracemissionstor - and have begun providing the relay name to friends who would like to use TBB. What I have not been able to google yet properly, is what startup/connection procedure is best for those using TBB, _and_ are on the local network - many people come and go here and there, and connect to the Internet from the LAN/internal network. Should those connecting in this way, simply select the default connection options, and add gracemissionstor into the final I need to use a bridge relay screen, or is there a preferred way to connect - I am running the TOR SOCKS proxy for example. I would like to be able to explain to people how to use TBB and connect to the local TOR relay when they are connected to the LAN - either via SOCKS or otherwise - but of course, it does not make sense to have TBB connect through TOR relay SOCKS (on the local network TOR relay), just to thereafter be tunnelled through the TOR network, just to thereafter establish _another_ connection back to the gracemissionstor relay, thereby having all Internet access travelling multiple times through the TOR network unnecessarily. Does this make sense? There ideally ought be a TORButton config option, or similar, to connect using local TOR relay SOCKS port and an easy way to let the TBB know (perhaps on each startup default to safety option) that (eg on next boot) we are no longer on a trusted local network. E.g. when TBB starts up (at least first time, and there SHOULD be option to have TBB ask _every_ time), and the user chooses use SOCKS proxy to connect to Internet, then when TBB connects to the SOCKS proxy, the TOR relay which is that SOCKS proxy ought notify the TBB that it is in fact connected to the desired (if the TOR relay name matches of course) TOR relay. Of course, it would _also_ make sense for TBB to SSL encrypt its connection to the local tor relay SOCKS port. This might all be wishful thinking and pie in the sky, but please forgive my enquiry if so - I don't yet have a full understanding of these things. TIA Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] procedure for TBB to use localhost relay
On 2/28/14, Zenaan Harkness z...@freedbms.net wrote: I am running a tor relay - gracemissionstor - and have begun providing the relay name to friends who would like to use TBB. What I have not been able to google yet properly, is what startup/connection procedure is best for those using TBB, _and_ are on the local network - many people come and go here and there, and connect to the Internet from the LAN/internal network. Solved this one, at least for the moment: accept defaults for first two startup steps: Proxy not required Ports not filtered then for relay bridge choose IP:port of internal relay, eg: 192.168.5.5:9001 SSH (with port-forwarding and no command only if desired) could be used to encrypt a SOCKS connection - but I don't really know how this would work. Anyway, above seems to work for internal host - LAN-internal TOR relay configuration. Thanks Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
On 2/24/14, Jeroen Massar jer...@massar.ch wrote: On 2014-02-24 09:32 , Zenaan Harkness wrote: I saw a hint of some interesting output by arm: flags: Exit, HSDir, Running, V2Dir, ValidleDebuggerAttachment 0' to your torrc and restarting tor. For more information see... This bit leDebuggerAttachment 0' to your torrc and restarting tor. For more information see... disappeared pretty quick. arm needs a few more details from Tor than it can easily get, effectively it wants to ptrace the Tor process to collect these details. Hence you'll need to set in torrc: DisableDebuggerAttachment 0 That will allow it to collect these details. See also the description for that option in: https://www.torproject.org/docs/tor-manual.html.en Thank you. The man page (or something) said that tor would not be able to apply that option whilst running. Nevertheless I added the option into torrc so that next time tor gets restarted, I shall be able to use arm properly. I'm on Debian and did a service tor reload (not restart) and tor crashed! I didn't realise immediately, took may be a minute to realise and restart. Anyway apologies to any connections that were going through this relay. Should I report a bug to Debian? Also, this morning, my relay is back up, but no longer with HSDir flag. Is this due to setting that option in the torrc file? And if so, I guess it is recommended to disable that option? PS Apologies for forgetting the subject line. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
On 2/25/14, Roger Dingledine a...@mit.edu wrote: On Tue, Feb 25, 2014 at 10:15:11AM +1100, Zenaan Harkness wrote: I'm on Debian and did a service tor reload (not restart) and tor crashed! I didn't realise immediately, took may be a minute to realise and restart. Anyway apologies to any connections that were going through this relay. Should I report a bug to Debian? First check your logs -- it's likely that it's not a crash, but rather Tor read the new torrc file and either couldn't parse it or refused to switch to the new parameters. I ran service tor status, and it was definitely dead. What twigged me was rerunning arm and arm began with running some wizard for new site configuration, so I knew something had gone wrong, checked the service and sure enough it was not running. service tor start and all was back and running within a minute or less, and arm showed me as much. So definitely tor stopped running - in a way that was deterministic (I did run the service tor reload command) but totally unexpected - tor should never stop running (or crash) with just a config file reload! Also, this morning, my relay is back up, but no longer with HSDir flag. Is this due to setting that option in the torrc file? And if so, I guess it is recommended to disable that option? To disable which option? You should leave HidServDirectoryV2 alone in general, and let the Tor directory authorities decide whether you're stable enough to be used. DisableDebuggerAttachment 0 This is the only change, the one which subsequent to adding that option, and running service tor reload, tor apparently stopped running, as above. So the only change that I am aware of that could have caused the HSDir flag (as shown in arm) to go away, was either that option (DisableDebuggerAttachment 0), or simply the fact that the relay crashed (or somehow otherwise stopped running). I am very new to running a relay and still getting up to speed - I imagine I will be for a while yet, so thanks everyone for your patience :) Regards Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (no subject)
On 2/25/14, Roger Dingledine a...@mit.edu wrote: On Tue, Feb 25, 2014 at 02:27:22PM +1100, Zenaan Harkness wrote: tor should never stop running (or crash) with just a config file reload! Alas, I disagree. The alternative is that it *doesn't* stop running, yet you think it's using the new torrc file when it isn't. That would be a worse kind of surprise. Unless you have a third alternative that is better? I agree that the current state is not great. That said, we *do* have a partial answer, in the init script itself -- it runs Tor with --verify-config to make sure that the config file itself is parseable. So the remaining trouble is when the config file is parseable, but the requested changes are incompatible with Tor's current state. Aha. Thank you. What would be preferable from my personal POV is that an attempt to load the config file would fail with an error output to the console. In debian, there are six standard options for service management: status start stop reload restart force-reload reload ought not cause the daemon to stop. Sometimes daemons have restart and force-reload be the same thing. force-reload is where the daemon might be restarted if there is a config file change which cannot be effected otherwise. At least, that's my understanding, although I'm not an expert sorry. DisableDebuggerAttachment 0 This is the only change, the one which subsequent to adding that option, and running service tor reload, tor apparently stopped running, as above. Yes. Please read your Tor logs where it explains why. https://www.torproject.org/docs/faq#Logs So the only change that I am aware of that could have caused the HSDir flag (as shown in arm) to go away, was either that option (DisableDebuggerAttachment 0), or simply the fact that the relay crashed (or somehow otherwise stopped running). It's the latter -- the HSDir flag is a function of the stability of your relay. See https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1867 Thank you for the pointers and clarity. Very much appreciated. Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/21/14, grarpamp grarp...@gmail.com wrote: something I did to ntpd.conf (probably adding servers above the default debian entries which are: server 0.debian.pool.ntp.org iburst The order doesn't matter. Though if DNS is not up before ntpd on boot, specified poolnames won't resolve and I think it's still a oneshot so only servers listed by ip would be loaded. see ntpq -np while listing a bogus hostname, a poolname, and an ip. Well I have a couple of IP listings now, and I haven't seen the ~2minute jump since adding them. So things have definitely improved on that front. I still see rather wild deltas (upwards of a second sometime), but at least it doesn't get worse than that: Feb 22 11:26:38 lt8 ntpdate[4832]: step time server 192.189.54.17 offset 0.762756 sec Feb 22 11:31:48 lt8 ntpdate[4836]: adjust time server 203.59.7.248 offset -0.052660 sec Feb 22 11:37:00 lt8 ntpdate[4839]: adjust time server 203.23.237.200 offset 0.283965 sec Feb 22 11:42:11 lt8 ntpdate[4841]: adjust time server 203.23.237.200 offset 0.151871 sec Feb 22 11:47:26 lt8 ntpdate[4843]: adjust time server 150.101.247.149 offset 0.470046 sec Feb 22 11:52:35 lt8 ntpdate[4845]: adjust time server 27.106.200.45 offset 0.063318 sec Feb 22 11:57:46 lt8 ntpdate[4847]: adjust time server 130.102.128.23 offset 0.090110 sec Feb 22 12:03:00 lt8 ntpdate[4851]: step time server 192.189.54.17 offset 0.515640 sec Feb 22 12:08:12 lt8 ntpdate[4853]: adjust time server 192.189.54.17 offset 0.308896 sec Feb 22 12:13:20 lt8 ntpdate[4855]: adjust time server 118.88.20.194 offset -0.162371 sec Feb 22 12:18:33 lt8 ntpdate[4860]: adjust time server 128.184.218.53 offset 0.302422 sec Feb 22 12:23:44 lt8 ntpdate[4915]: adjust time server 203.161.12.165 offset 0.162629 sec Feb 22 12:28:54 lt8 ntpdate[4922]: adjust time server 203.161.12.165 offset 0.035504 sec Your comment above reminds me of something else I saw: log.3.gz:Feb 19 09:55:50.000 [warn] eventdns: All nameservers have failed log.3.gz:Feb 19 09:59:07.000 [warn] Your system clock just jumped 100 seconds forward; This only happened once or twice back then. What this leads me to is a couple of things - have a couple ntp servers listed as ip address in case there is dns problems, but also I think that one thing that may have affected me is I had essentially no throttling/bandwidth shaping on the tor relay - and if the uplink/upload gets satturated, this used to be a problem for bittorrent (still is I think) and probably for tor relay too - if certain outgoing packets don't make it out in a timely manner, then problems happen. So I have set my RelayBandwidthBurst to 90KB (KiB) (and non-burst to 80KB) - it's an ADSL2 connection pretty close to the exchange, so the full 1MiB upload is generally possible, I think. I'll see how I continue to go at 90KB. Thanks all, Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay unresponsive
Somewhat regularly, I get relay unresponsive with a heartbeat delta of about 12seconds. Could this mean my upload pipe is still saturated and I need to throttle back slightly? recent arm log: 13:12:56 [ARM_NOTICE] Relay resumed [6 duplicates hidden] 13:12:31 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 13:12:20 2014) 12:11:34 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 12:11:20 2014) 11:10:33 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 11:10:20 2014) 09:30:24 [NOTICE] Heartbeat: Tor's uptime is 2:18 hours, with 146 circuits open. I've sent 14.23 GB and received 9.69 GB. 09:09:20 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 09:09:07 2014) 09:08:30 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 09:08:19 2014) 07:16:39 [NOTICE] Self-testing indicates your DirPort is reachable from the outside. Excellent. 07:12:43 [NOTICE] Performing bandwidth self-test...done. 07:11:31 [NOTICE] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. 07:11:26 [NOTICE] Your IP address seems to have changed to 203.158.36.137. Updating. 07:09:25 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 07:09:12 2014) 07:08:04 [ARM_NOTICE] Relay unresponsive (last heartbeat: Sat Feb 22 07:07:51 2014) 03:30:24 [NOTICE] Heartbeat: Tor's uptime is 5:52 hours, with 189 circuits open. I've sent 12.95 GB and received 12.78 GB. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] schedule tor relay uptime/ bandwidth
I know tor relay bandwidth usage per period can be configured, but is it possible to schedule a tor relay to sleep during business hours, and only operate after hours? TIA Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/20/14, grarpamp grarp...@gmail.com wrote: Since you say it repeats you oppurtunity to check the system clock first: - configure tor to syslog added - send an ntpdate -q pool to syslog every 5min, remove when solved. Do you mean disable ntpd daemon, and run this instead? Sounds easy enough, I imagine: service ntp stop; while true; do ntpd -gqn -l /var/log/syslog; sleep 5m; done service ntp start Something like -L seems to be needed but -L doesn't stop, the following - I don't know what these sorts of lines are (reading docs now, but it might take a while to figure it out) - ie I don't know why ntpd listens on LAN: 20 Feb 18:31:26 ntpd[22655]: Listen normally on 3 eth1 192.168.5.2 UDP 123 BTW, looks like ntpd has the same options as ntpdate, intended for the same functions (at least on Debian, says ntpdate is deprecated). Now, here's the last short while of this ntpd script output: ntpd: time slew -0.015558s ntpd: time slew +0.062676s ntpd: time set +0.191404s ntpd: time set +0.187068s ntpd: time slew -0.029898s ntpd: time slew +0.027801s So it seems that the slew is somehow not being set properly, or rather, now that ntpd is being run every 5 minutes, it gets to add about .2 of a second pretty regularly (I'll continue to watch of course), so something definitely seems amiss. I'm not loading the system default ntpd config file. It looks like time could be running slow and being _not_ updated, except a few times a day, resulting in the 2-3minute jump. - send *.* to /var/log/all What's that mean? I need just a little more handholding sorry. Is this intended to be a torrc config? It sounds like a good idea to send everything to one log file for a while, till I debug this. I'll get back to this, but just for the moment, I notice some interesting repeating lines all over daemon.log re ntpd (but not recently): ... daemon.log:Feb 18 03:10:08 lt8 ntpd[2845]: peer 203.24.120.194 now valid daemon.log:Feb 18 03:15:37 lt8 ntpd[2845]: peer 203.59.9.110 now invalid daemon.log:Feb 18 03:28:34 lt8 ntpd[2843]: adjusting clock frequency by 18.354661 to 3.931566ppm daemon.log:Feb 18 04:08:41 lt8 ntpd[2845]: peer 203.59.9.110 now valid daemon.log:Feb 18 04:15:29 lt8 ntpd[2845]: peer 118.88.20.194 now invalid daemon.log:Feb 18 04:15:34 lt8 ntpd[2845]: peer 130.102.2.123 now invalid daemon.log:Feb 18 04:15:47 lt8 ntpd[2845]: peer 203.171.85.237 now invalid daemon.log:Feb 18 04:15:52 lt8 ntpd[2845]: peer 202.127.210.37 now invalid daemon.log:Feb 18 04:16:01 lt8 ntpd[2845]: peer 202.147.104.52 now invalid daemon.log:Feb 18 04:30:05 lt8 ntpd[2845]: peer 203.59.9.110 now invalid daemon.log:Feb 18 04:59:11 lt8 ntpd[2845]: 10 out of 20 peers valid daemon.log:Feb 18 04:59:11 lt8 ntpd[2845]: bad peer from pool 0.debian.pool.ntp.org (130.102.2.123) daemon.log:Feb 18 04:59:11 lt8 ntpd[2845]: bad peer from pool 0.debian.pool.ntp.org (202.127.210.37) daemon.log:Feb 18 04:59:11 lt8 ntpd[2845]: bad peer from pool 1.debian.pool.ntp.org (203.59.9.110) ... nothing similar in today's daemon.log though. and see what you find around where the date lines start to slide or jump past each other. Graph it with rrd/gnuplot if you want. epoch format helps there. Your timekeeping is probably just broke somewhere, sounds like it. ie: your system has bad clock drift and also can't sync because there's a firewall blocking ntp, so off goes your time. Check that first. Here's what I'm getting every 5 minutes: Feb 20 18:46:59 lt8 ntpd[22662]: ntpd 4.2.6p5@1.2349-o Sat May 12 09:07:18 UTC 2012 (1) 20 Feb 18:46:59 ntpd[22662]: proto: precision = 2.514 usec 20 Feb 18:46:59 ntpd[22662]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Feb 20 18:46:59 lt8 ntpd[22662]: logging to file /var/log/syslog 20 Feb 18:46:59 ntpd[22662]: Listen and drop on 1 v6wildcard :: UDP 123 20 Feb 18:46:59 ntpd[22662]: Listen normally on 2 lo 127.0.0.1 UDP 123 20 Feb 18:46:59 ntpd[22662]: Listen normally on 3 eth0 192.168.5.2 UDP 123 20 Feb 18:46:59 ntpd[22662]: Listen normally on 4 eth0 fe80::202:8aff:fe21:77f1 UDP 123 20 Feb 18:46:59 ntpd[22662]: Listen normally on 5 lo ::1 UDP 123 20 Feb 18:46:59 ntpd[22662]: peers refreshed 20 Feb 18:46:59 ntpd[22662]: Listening on routing socket on fd #22 for interface updates 20 Feb 18:47:12 ntpd[22662]: ntpd: time slew +0.027801 s again, I don't (yet) understand why ntpd is Listening as seen above. there appears to be no problems with firewall, that I can tell yet anyway (also eg the logs above - I've done some grepping etc over the last few days of logs and everything outgoing appears to work, and incoming ORPort DIRPort are successfully forwarded and the relay is chugging away nicely within its limits. Also Internet generally works (downloading debian boot cd for example) - and no ntp server connection failures I could spot in the logs just before. It's not your isp since you say you're using ntpd against external debian pool and odds are not someone stuffing you bogus timedata. Though your ntp
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/20/14, grarpamp grarp...@gmail.com wrote: - configure tor to syslog added 'Log syslog' The example in etc/torrc is 'Log notice syslog' which I uncommented. - send an ntpdate -q pool to syslog every 5min, remove when solved. Do you mean disable ntpd daemon, and run this instead? Sounds easy enough, I imagine: service ntp stop; while true; do ntpd -gqn -l /var/log/syslog; sleep 5m; done service ntp start I meant remove it when solved so you don't forget and you're banging on the pool every 5 for eternity. -l /var/log/syslog - this is potentially overwriting or blocking this file which is managed by syslogd in syslog.conf, pick another new file, or just better to use ntp.conf logconfig option. if you were running ntpd during problems, and ntpd was not working right, then ntpdate would be just a tool to separately query and print external pool time without impact to running system, for comparing with system time. Thank you. Restarted ntpd, installed ntpdate, running this script: while true; do sleep 5m; ntpdate -qsv 3.debian.pool.ntp.org; echo ---; done ... ntpd disciplines kernel clock by calculating drift from the net and feeds back small rate deltas to kernel. no ntpd - no discipline - lots of drift... then these manual slews and jumpsets happen for people setting time manually, which is non ideal, get the daemon running right on its own. Tor said 100sec forward, so it maybe sees what look like the forward jumps above as accumulated. ntpd would not do that if running right, so check for some ntp thing in crontab maybe making your jump. # cd etc; # grep -in ntp cron*/* cron.daily/ntp:3:# The default Debian ntp.conf enables logging of various statistics to cron.daily/ntp:4:# the /var/log/ntpstats directory. The daemon automatically changes cron.daily/ntp:9:statsdir=$(cat /etc/ntp.conf | grep -v '^#' | sed -n 's/statsdir \([^ ][^ ]*\)/\1/p') Nothing special at all - just standard debian ntp install. I've now gone and added some ntp servers from telstra, iinet and ntp.org. So it seems that the slew is somehow not being set properly, or rather, now that ntpd is being run every 5 minutes, it gets to add about .2 of a second pretty regularly (I'll continue to watch of course), so something definitely seems amiss. I'm not loading the system default ntpd config file. It looks like time could be running slow and being _not_ updated, except a few times a day, resulting in the 2-3minute jump. Maybe ntpd is not working/running and cron is maybe doing manual sets. I've restarted ntpd and running the above script as mentioned. Will post some output soon. # service ntp status NTP server is running. - send *.* to /var/log/all intended to be a torrc config? It sounds like a good idea to send everything to one log file for a while, till I debug this. man syslog.conf Thanks. Looks like debian defaults to rsyslog. Anyway, I know what you are referring to now, thanks (I'm a bit green, although have been reported to have at least 1.5 brain cells - though some dispute this as being biased sample). interesting repeating lines all over daemon.log re ntpd (but not nothing similar in today's daemon.log though. ntp automatically chooses who it thinks is best to listen to among given peers. Good. Well now I have a number of ntp servers listed, hopefully it shall improve the situation. If [system ntp]date is set, then under ntpd running for 15min+, if ntpq -np does not show one asterisk(*) in front Only one of ntpd or ntpdate should be doing the actual timing. For most people that means 'ntpd -g' starting as daemon at boot, with 'ntpdate -q' and 'ntpq -np' as just cli checks. Thanks. That's what I'm doing now. TOR relay docs should perhaps include, for debian add your isp's ntp servers, and possibly a few from ntp.org, to your /etc/ntpd.conf (and check this file is sane). OK, grepping logs time...: Feb 20 23:51:35 lt8 ntpdate[29233]: adjust time server 130.102.2.123 offset -0.024247 sec Feb 20 23:57:31 lt8 ntpdate[29289]: adjust time server 54.252.129.186 offset 0.018113 sec Feb 21 00:02:38 lt8 ntpdate[29329]: adjust time server 59.167.170.228 offset 0.025050 sec Feb 21 00:07:46 lt8 ntpdate[29377]: adjust time server 121.0.0.41 offset 0.017704 sec Feb 21 00:12:53 lt8 ntpdate[29380]: adjust time server 203.206.205.83 offset 0.004626 sec Feb 21 00:18:00 lt8 ntpdate[29395]: adjust time server 27.116.36.44 offset -0.003997 sec Feb 21 00:23:08 lt8 ntpdate[29411]: adjust time server 118.88.20.194 offset -0.003071 sec Looking very hopeful - convergence of time offset on the way. I guess something I did to ntpd.conf (probably adding servers above the default debian entries which are: server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst I'll check it again in the morning. Next stop, looking into the cgnat issue (occasionally the IP change appears to cause all clients
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/19/14, Zenaan Harkness z...@freedbms.net wrote: On 2/19/14, Alexander Makarov ice.turbul...@gmail.com wrote: Could you show the log? Current and previous tor logs attached. What is also interesting is IP address seems to change rather frequently from the ISP (iiNet in this case - a home ADSL2 connection, but off-net, so it's a resell of Telstra). Telstra could be running carrier grade NAT or something perhaps? Looks like IP address changes may be coming faster until there's a 99% conversion to IPv6. I also note an early morning torrc file read (log.1) - there are no changes in the torrc file since the 17th, so except that I run service tor reload, I do not expect tor to re-read the torrc file; is this normal?: Feb 19 07:35:19.000 [notice] Read configuration file /etc/tor/torrc. Guess I need to get into coding again - or at least code review... this doesn't make sense to me though - the log message should say a bit more than it does (eg confirmed no change or changes to BLAH and BLAG... the message as it reads is enigmatic to the point of consternation. Can you rebuild you kernel with debug option and check what kernel events have the same timestamps I could install a debug kernel - Debian makes them available. How would I check kernel events - just check the logs? Happy to investigate... might need some hand holding on the process. Installed Debian's ...-dbg kernel package. Apparently it's just symbols - no new kernel. I've asked on debian-user for assistance in the recommendation to check kernel events. Thanks Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
My tor logs (running on Debian) are showing this warning: [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work. I tried running openntpd as well as ntp packages (debian), and both display the same problem - once or twice a day I get this jump in time of in the order of a couple of minutes. Any idea why? TIA Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/18/14, Alexander Makarov ice.turbul...@gmail.com wrote: On 18.02.2014 22:02, Zenaan Harkness wrote: My tor logs (running on Debian) are showing this warning: [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work. I tried running openntpd as well as ntp packages (debian), and both display the same problem - once or twice a day I get this jump in time of in the order of a couple of minutes. Any idea why? Maybe problem with hardware clocks? OK, I just checked that the time is very close to correct local time (within a couple seconds as best I can tell), and ran hwclock --systohc But, surely the log warning would only happen once? - that's the whole point of running ntp I thought... See how my node goes over the next day or two, Thanks Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/18/14, D.S. Ljungmark spi...@aanstoot.se wrote: On Tue, Feb 18, 2014 at 12:02 PM, Zenaan Harkness z...@freedbms.net wrote: My tor logs (running on Debian) are showing this warning: [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work. I tried running openntpd as well as ntp packages (debian), and both display the same problem - once or twice a day I get this jump in time of in the order of a couple of minutes. Are you on a virtual machine? Do you control the VM host? If not, it could be that your host is migrating your VM, or not scheduling it properly, which causes time drifts inside the VM. No VM, an older 32-bit box, 1GiB RAM, no swap. On 2/19/14, Andreas Krey a.k...@gmx.de wrote: It may just be that your machine completely hangs for a while occasionally; that will look to tor like a clock jump in that direction. Either hard disk timeouts of some kind, or serious swapping. If VM then also possibly the entire VM being starved occasionally. Default Debian ntp servers/ config: server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst etc ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
On 2/19/14, Alexander Makarov ice.turbul...@gmail.com wrote: On 18.02.2014 23:39, Zenaan Harkness wrote: On 2/18/14, Alexander Makarov ice.turbul...@gmail.com wrote: On 18.02.2014 22:02, Zenaan Harkness wrote: My tor logs (running on Debian) are showing this warning: [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work. I tried running openntpd as well as ntp packages (debian), and both display the same problem - once or twice a day I get this jump in time of in the order of a couple of minutes. Any idea why? Maybe problem with hardware clocks? OK, I just checked that the time is very close to correct local time (within a couple seconds as best I can tell), and ran hwclock --systohc But, surely the log warning would only happen once? - that's the whole point of running ntp I thought... See how my node goes over the next day or two, Well, the time jump still happens, roughly 5hrs apart, 2-3 minute jump. Could you show the log? Current and previous tor logs attached. What is also interesting is IP address seems to change rather frequently from the ISP (iiNet in this case - a home ADSL2 connection, but off-net, so it's a resell of Telstra). I also note an early morning torrc file read (log.1) - there are no changes in the torrc file since the 17th, so except that I run service tor reload, I do not expect tor to re-read the torrc file; is this normal?: Feb 19 07:35:19.000 [notice] Read configuration file /etc/tor/torrc. Can you rebuild you kernel with debug option and check what kernel events have the same timestamps I could install a debug kernel - Debian makes them available. How would I check kernel events - just check the logs? Happy to investigate... might need some hand holding on the process. Thanks Zenaan log Description: Binary data log.1 Description: Binary data ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
