Re: [tor-relays] (no subject)
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 Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ExtORPort notice
Delton Barnes delton.bar...@mail.ru writes: Upon upgrading obfsproxy to 0.2.6 and Tor to 0.2.5.1-alpha-dev (git-f63b394d90583b77+96972c4) for scramblesuit, I got this in the Tor log: Feb 15 04:40:03.000 [notice] We are a bridge with a pluggable transport proxy but the Extended ORPort is disabled. The Extended ORPort helps Tor communicate with the pluggable transport proxy. Please enable it using the ExtORPort torrc option. How should this be set? What does it do? I saw some web pages suggesting ExtORPort 6699 for statistics-gathering purposes. Hm, that log message can indeed be more helpful. I opened a ticket about this: https://trac.torproject.org/projects/tor/ticket/11043 Feedback is welcome. For what it's worth, the easiest way to set up the Extended ORPort is to put: 'ExtORPort auto' in your torrc. Tor will figure out an appropriate port number for you. The Extended ORPort is used for statistics gathering for now. In the future it will be used for more functionality (to orchestrate rate limiting, etc.). See Kostas' mail for more information. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] crypto error while checking RSA signature: padding check failed
On Fri, Feb 21, 2014 at 10:46 PM, Zenaan Harkness z...@freedbms.net wrote: Occasionally (such as just now) I have seen these two errors in arm: │ 13:21:25 [WARN] crypto error while checking RSA signature: padding check failed (in rsa routines:- │ RSA_EAY_PUBLIC_DECRYPT) │ 13:21:25 [WARN] crypto error while checking RSA signature: block type is not 01 (in rsa routines:- │ RSA_padding_check_PKCS1_type_1) Are they anything to worry about? Zenaan Probably not. It probably means that some bytes got corrupted on the network, not that somebody's trying an attack. (If somebody _were_ trying an attack, this would be a stupid one, since it wouldn't work against any Tor software I'm aware of.) peace, -- Nick ___ 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 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. 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. --Roger ___ 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
