[tor-relays] [warn] Error relaying cell across rendezvous; closing circuits
I run the non-exit relay 8F6A78B1EA917F2BF221E87D14361C050A70CCC3 Today I noticed two [warn] lines in the Tor log file that I have not seen before: [warn] Error relaying cell across rendezvous; closing circuits [warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/core/or/command.c:577 (first at ../src/core/or/relay.c:343) (on Tor 0.4.8.12 ) I assume this is more of a FYI for the developers than for me as an operator. I'll keep an eye out to see if they appear more times. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Warn:
I got the below message on my relay #2. It's been in operation for a year and a half. First time I've ever got one of these. 0re7:26:40 [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [505 similar message(s) suppssed in last 57840 seconds] OK > Both relays operate on Digital Ocean Droplets Bandwidth on both 2 MBs Burst 3MBs both relays have the same settings NEITHER is an exit: ExitPolicy reject I see relay #2 has been restarted. Last eve it had been up four days. As of this writing just over 2 hours. Or is this another way to muck up a relay? Sysmanager Sent with [Proton Mail](https://proton.me/) secure email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Received a bad CERTS cell: Link certificate does not match TLS certificate
Hi all I found a message in the logs: Apr 16 15:07:46.000 [warn] Received a bad CERTS cell: Link certificate does not match TLS certificate -- Cheers Felix pgpz8Afm4HlbY.pgp Description: Digitale Signatur von OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] warn message in notices .log after reinstallation of the relay (and restore of torrc and "keys" folder)
Hi, I had issues with my bridge who is running on a Raspberry pi 3+ so i've decided to completely reinstall it. First i saved my torrc file and my "keys" folder from /var/lib/tor. First thing i did after a clean install of the server was to copy and paste my torrc file in /etc/tor/ and the files "ed25519_master_id_secret_key" and "secret_id_key" in the keys directory. Anyway after starting Tor i had the following messages in notices.log: [warn] http status 400 '"looks like your keypair has changed?...etc...etc... i decided to completely replace the content of the keys folder by my backup but i still have the same message. When i go to Tor relay search i see my bridge with two different identities and both are offline ( one of the hashed fingerprints is the right one). Anyway if i run "nyx" i can see that Tor is working, reachable from the outside and some circuits are built. I suspect i make a mistake with the "keys" but i'm a little bit lost. Can you guys help me please ? Sent with [ProtonMail](https://protonmail.com) Secure Email.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your computer is too slow to handle this many circuit creation requests
Hi, *UPDATE** I'm still seeing these warning messages but in a lower frequency: Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [1077 similar message(s) suppressed in last 60 seconds] The defenses seems to be working (?): DoS mitigation since startup: 45482775 circuits rejected, 157 marked addresses. 2187600 connections closed. 993 single hop clients refused. ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your computer is too slow to handle this many circuit creation requests
Hi, Running for more than a week the alpha version 0.3.3.2 (git-7b1d356bdb76607d) the issue seems to be resolved. Heartbeat: Tor's uptime is 7 days 11:59 hours, with 19157 circuits open. I've sent 2372.16 GB and received 2372.27 GB. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your computer is too slow to handle this many circuit creation requests
Roger Dingledine: > On Wed, Feb 21, 2018 at 01:13:00PM +, Vasilis wrote: >> I see a number of warning log messages on a dedicated server: >> [WARN] Your computer is too slow to handle this many circuit creation >> requests! > > You get that warning message when there are too many create cells coming > in, and your relay ends up sending back preemptively destroy cells for > some of them. That is, it tries to estimate internally how long it will > take to handle the current queue of create cells, and if the queue gets > so big that the one that just arrived will take several seconds before > it can be processed, Tor just sends back a destroy cell instead, and > gives you this warn. > > The flood of circuits created by the ddos storm will be causing this > sort of warning sometimes. For example, my FreeBogatov relay gets 30-70 > million create requests per 6 hours, and when that number goes over > about 100 million, there are times where it can't keep up. > > (Careful though because the heartbeat message about number of circuits > does not count circuits that come from client connections. That is, the > circuits in the heartbeat count are only circuits that come via other > relays. So non-Guards are giving you a reasonably accurate count, and > Guards are leaving out an unknown number of circuits from their count, > and that unknown number could be quite large.) > > Ultimately, the fix needs to be that more and more relays upgrade to a > version of Tor tht includes the DDoS mitigation. One of the main goals > of the mitigation is not to help *your* relay in particular, since hey > maybe your relay is huge and it can keep up, but rather to slow down the > mass of circuits heading towards *other* relays after yours. > > That is, you need *other* relays to deploy the mitigation in order to > help you. > https://en.wikipedia.org/wiki/Herd_immunity Makes sense great explanation, thank you! Wasn't planning to stop running/administering any of the relays. >> Setting the NumCPUs option to the actual number of CPUs (2) didn't help. > > Are you sure you only have 2 cores? These days each cpu has many cores, > so a system with 2 cpus could easily have 8 cores. It's an old processor with 2 CPU and 1 core per CPU. >> Is this hardware really too old/slow to run a relay on one ethernet Gigabit >> link? > > Well, there are times where it isn't able to keep up. But if you turn > off the relay or turn down its capacity, then it will just increase the > load on the other relays. So I think we shouldn't worry too much about > these warnings during this period of overload. > > Oh, I guess I should ask: are you using 0.3.3.2-alpha or a version with > the ddos mitigation? If not, that's a clear next step. I 'll upgrade to the alpha version and closely monitor its activity. Thanks, ~Vasilis signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your computer is too slow to handle this many circuit creation requests
On Wed, Feb 21, 2018 at 01:13:00PM +, Vasilis wrote: > I see a number of warning log messages on a dedicated server: > [WARN] Your computer is too slow to handle this many circuit creation > requests! You get that warning message when there are too many create cells coming in, and your relay ends up sending back preemptively destroy cells for some of them. That is, it tries to estimate internally how long it will take to handle the current queue of create cells, and if the queue gets so big that the one that just arrived will take several seconds before it can be processed, Tor just sends back a destroy cell instead, and gives you this warn. The flood of circuits created by the ddos storm will be causing this sort of warning sometimes. For example, my FreeBogatov relay gets 30-70 million create requests per 6 hours, and when that number goes over about 100 million, there are times where it can't keep up. (Careful though because the heartbeat message about number of circuits does not count circuits that come from client connections. That is, the circuits in the heartbeat count are only circuits that come via other relays. So non-Guards are giving you a reasonably accurate count, and Guards are leaving out an unknown number of circuits from their count, and that unknown number could be quite large.) Ultimately, the fix needs to be that more and more relays upgrade to a version of Tor tht includes the DDoS mitigation. One of the main goals of the mitigation is not to help *your* relay in particular, since hey maybe your relay is huge and it can keep up, but rather to slow down the mass of circuits heading towards *other* relays after yours. That is, you need *other* relays to deploy the mitigation in order to help you. https://en.wikipedia.org/wiki/Herd_immunity > Setting the NumCPUs option to the actual number of CPUs (2) didn't help. Are you sure you only have 2 cores? These days each cpu has many cores, so a system with 2 cpus could easily have 8 cores. > Is this hardware really too old/slow to run a relay on one ethernet Gigabit > link? Well, there are times where it isn't able to keep up. But if you turn off the relay or turn down its capacity, then it will just increase the load on the other relays. So I think we shouldn't worry too much about these warnings during this period of overload. Oh, I guess I should ask: are you using 0.3.3.2-alpha or a version with the ddos mitigation? If not, that's a clear next step. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [WARN] Your computer is too slow to handle this many circuit creation requests
Hi, I see a number of warning log messages on a dedicated server: [WARN] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [27615 similar message(s) suppressed in last 60 seconds] The relay is running on a dedicated hardware with the following specifications: CPU: Intel(R) Xeon(TM) CPU 3.00GHz RAM: 6G Kernel: Linux 3.16.0-5-amd64 Tor version: 0.3.2.9 flags: Fast, Guard, HSDir, Running, Stable, V2Dir, Valid exit policy: reject *:* Setting the NumCPUs option to the actual number of CPUs (2) didn't help. Is this hardware really too old/slow to run a relay on one ethernet Gigabit link? Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] assign_to_cpuworker failed. Ignoring.
> On 1 Aug 2017, at 08:17, Ybslik wrote: > ... > > Me - 9D60A484CFBDB5B890FB5B18941494734584BA17 > > ... > Jul 31 20:37:34.000 [notice] Since startup, we have initiated 0 v1 > connections, 0 v2 connections, 3 v3 connections, and 908239 v4 connections; > and received 3548 v1 connections, 254 v2 connections, 7 v3 connections, and > 1155164 v4 connections. > ... > I've highlighted the number of circuits in red..never had that many > before. Read this thread: https://lists.torproject.org/pipermail/tor-relays/2017-July/012660.html If you still have any questions, feel free to write back. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] channelpadding_ and [warn] assign_
On Mon, Jul 03, 2017 at 09:58:02PM +0200, Felix wrote: > [warn] channelpadding_compute_time_until_pad_for_netflow: Bug: Channel > padding timeout scheduled 212ms in the past. Did the monotonic clock just > jump? (on Tor 0.3.1.3-alpha dc47d936d47ffc25) https://bugs.torproject.org/22212 > and > > [warn] assign_to_cpuworker failed. Ignoring. https://bugs.torproject.org/22356 > Seems without impact to performance. I just wonder. > Switching to 3.1.4a might fix it ? The 0.3.1.4-alpha changelog lists both of these tickets. So, let us know if they continue once you've updated! --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] channelpadding_ and [warn] assign_
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/03/2017 09:58 PM, Felix wrote: > Switching to 3.1.4a might fix it ? Doubt, got it today too (just once till now) at 0.3.1.4-alpha - -- Toralf PGP C4EACDDE 0076E94E -BEGIN PGP SIGNATURE- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWVqiwxccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTqavAP9TMX3RPRH2thkxfHu6JE8HAreo ih3AIHefHcLhwfNP4AD9HromYZMykGvusiqfH7forOGap2cVyK342FDshgZ42JQ= =ZdBT -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] channelpadding_ and [warn] assign_
Hi everybody On 3.1.3a there are quiet some log entries like 10 per day and relay, more cicuits - more entries: [warn] channelpadding_compute_time_until_pad_for_netflow: Bug: Channel padding timeout scheduled 212ms in the past. Did the monotonic clock just jump? (on Tor 0.3.1.3-alpha dc47d936d47ffc25) and [warn] assign_to_cpuworker failed. Ignoring. Seems without impact to performance. I just wonder. Switching to 3.1.4a might fix it ? 3.0.8 doesn't show it. [] Tor 0.3.1.3-alpha (git-dc47d936d47ffc25) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.4.3, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.2.0. -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] circuit_mark_for_close under (Linux 4.4.0-21-generic) Tor 0.2.9.10
[warn] circuit_mark_for_close_(): Bug: Duplicate call to circuit_mark_for_close at ../src/or/onion.c:238 (first at ../src/or/command.c:579) (on Tor 0.2.9.10 ) Can this warning be neglected - I thought it is a BSD and not a Linux issue? Got nearly a hundred of them today - all with the same time stamp. Thanks - Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "[warn] Cannot make an outgoing connection without a DirPort" under BSD
https://trac.torproject.org/projects/tor/ticket/20711 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] "[warn] Cannot make an outgoing connection without a DirPort" under BSD
pa011: > I am running (FreeBSD 11.0-RELEASE-p2) Tor 0.2.8.11 > getting following warnings while Self-testing indicates that DirPort is > reachable from the outside? > > Can these warnings be ignored, while Tor is running properly afterwards ? > Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a > DirPort. This is probably a bug. Try to switch log level to "info" - tor should provide a more detailed backtrace saying something like "Address came from...". Please don't forget to sanitize log from irrelevant private data. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] "[warn] Cannot make an outgoing connection without a DirPort" under BSD
I am running (FreeBSD 11.0-RELEASE-p2) Tor 0.2.8.11 getting following warnings while Self-testing indicates that DirPort is reachable from the outside? Can these warnings be ignored, while Tor is running properly afterwards ? Merry Christmas! Paul Dec 24 13:20:57.000 [notice] Bootstrapped 80%: Connecting to the Tor network Dec 24 13:20:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:20:58.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Dec 24 13:20:58.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Dec 24 13:20:58.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Dec 24 13:20:58.000 [notice] Bootstrapped 100%: Done Dec 24 13:20:58.000 [notice] Now checking whether ORPort x.x.x.x:9001 and DirPort x.x.x.x:9030 are reachable... (this may take up to 20 minutes -$ Dec 24 13:20:59.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Dec 24 13:20:59.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Publishing server descriptor. Dec 24 13:21:00.000 [notice] Performing bandwidth self-test...done. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. Dec 24 13:21:57.000 [warn] Cannot make an outgoing connection without a DirPort. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Remote server sent bogus reason code 65021
Looks like this is solved and belonged to not open ports Sorry for the hassle Paul Am 16.08.2016 um 18:34 schrieb pa011: > Just established a new Exit with two instances on (Linux 3.16.0-4-amd64) ,Tor > 0.2.8.6 > > On the second instance I get these warnings: > > [WARN] Remote server sent bogus reason code 65021 [21 duplicates hidden] > [WARN] Remote server sent bogus reason code 65023 [95 duplicates hidden] > [NOTICE] Have tried resolving or connecting to address '[scrubbed]' at 3 > different places. Giving up. [40 duplicates hidden] > > The code65023 is ticking up by one in about 10 seconds? > > The default instance is free of that. > > Anything to worry about? > > Thanks > > Paul > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [WARN] Remote server sent bogus reason code 65021
Just established a new Exit with two instances on (Linux 3.16.0-4-amd64) ,Tor 0.2.8.6 On the second instance I get these warnings: [WARN] Remote server sent bogus reason code 65021 [21 duplicates hidden] [WARN] Remote server sent bogus reason code 65023 [95 duplicates hidden] [NOTICE] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. [40 duplicates hidden] The code65023 is ticking up by one in about 10 seconds? The default instance is free of that. Anything to worry about? Thanks Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] eventdns: All nameservers have failed
Hello, This warn is known for some time. It's safe to ignore this warning no matter how many times you see it in your log file, IIRC it's a libevent issue when DNS resolvers are idle. All my exit relays have multiple such lines in the log files constantly. It's highly important to run your own resolver on localhost 127.0.0.1 such as unbound or bind. Installation is pretty straight forward since you need only a resolver. You will still get this warning even with your own resolver hosted on localhost regardless if you use unbound or bind, it's unrelated to this warning message, but using a local resolver will help privacy of the users using your exit. It's the recommended way to run exit relays. On 6/19/2016 10:59 PM, pa011 wrote: > Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed > Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up > > > I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour. > > The /etc/resolv.conf contains > > # Generated by SolusVM > nameserver 8.8.8.8 > nameserver 8.8.4.4 > > Is it really best to set only one DNS like specified here > https://trac.torproject.org/projects/tor/ticket/11600 ? > > Or are there better working solutions? signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] eventdns: All nameservers have failed
It's been mentioned here once before, but you shouldn't be using Google's DNS servers as they see almost all of the Tor network traffic. My solution was to run a local DNS resolver (unbound in my case) and to use at least 2 DNS servers from the Open NIC project: https://www.opennicproject.org/configure-your-dns/ After adding servers from OpenNIC, the errors disappeared completely for me. On 06/19/2016 02:59 PM, pa011 wrote: Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour. The /etc/resolv.conf contains # Generated by SolusVM nameserver 8.8.8.8 nameserver 8.8.4.4 Is it really best to set only one DNS like specified here https://trac.torproject.org/projects/tor/ticket/11600 ? Or are there better working solutions? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] eventdns: All nameservers have failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/19/2016 09:59 PM, pa011 wrote: > Or are there better working solutions? I do have only 127.0.0.1 set in my resolv.conf and do use dnsmasq together with strict DNSSEC. works like a charm and DNSSEC is really a good thing IMO. The configuration is straight forward: # grep -v -e '#' -e'^$' /etc/dnsmasq.conf conf-file=/usr/share/dnsmasq/trust-anchors.conf dnssec dnssec-check-unsigned no-resolv server= server= server= server= server= server= cache-size=1 Furthermore it reduces the load to upstream DNS servers by 1/3 : # pkill -SIGUSR1 dnsmasq; sleep 1; tail /var/log/messages | grep dnsmasq Jun 19 22:14:49 ms-magpie dnsmasq[1442]: time 1466367289 Jun 19 22:14:49 ms-magpie dnsmasq[1442]: cache size 1, 91142/4075150 cache insertions re-used unexpired cache entries. Jun 19 22:14:49 ms-magpie dnsmasq[1442]: queries forwarded 1665387, queries answered locally 695441 Jun 19 22:14:49 ms-magpie dnsmasq[1442]: DNSSEC memory in use 174384, max 311808, allocated 84 - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAldm/cIACgkQxOrN3gB26U7r8wD8DDPMBmNHc3ENAQfeYd0clt3X xPZdiFXwiQ6a94niYu4A/0phgRXBP++MgJOURWHlN3irSJiVkniuUcChSXY8wr8K =ugdK -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] eventdns: All nameservers have failed
Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour. The /etc/resolv.conf contains # Generated by SolusVM nameserver 8.8.8.8 nameserver 8.8.4.4 Is it really best to set only one DNS like specified here https://trac.torproject.org/projects/tor/ticket/11600 ? Or are there better working solutions? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Received http status code 504 ("Gateway Time-out") from server '154.35.175.225:80' while fetching "/tor/ ...
On Thu, Jun 02, 2016 at 11:07:15AM +0100, Robin Kjeld wrote:
> Jun 02 07:24:40.000 [warn] Received http status code 504 ("Gateway Time-
> out") from server '154.35.175.225:80'
Right, that is the directory authority 'faravahar' being broken again. It
does this sometimes, unfortunately causing scary-sounding warnings in
relay log messages. It's nothing to worry about (so long as enough other
dir auths aren't broken).
--Roger
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Received http status code 504 ("Gateway Time-out") from server '154.35.175.225:80' while fetching "/tor/ ...
Tor version 0.2.7.6
Tor relay logged this a few times:
Jun 02 07:24:40.000 [warn] Received http status code 504 ("Gateway Time-
out") from server '154.35.175.225:80' while fetching "/tor/server/d/6D3-
3995A9D954195FCDB0385B6A26F0F71543161+6F7D97B389CBF5409D4011155047C70E9-
FCB832C+70041AC73A4118691EA88E399BE781F4B7A4CD58+701EBDF7F377CAB09F9D99-
F70AAEAAE8E82544EC+70900B72F73CBFF3E72DAC29A89474788CEF9004+70A0349B8DD-
808578B4CA4DBECFEF7F136F9218C+71CEB7849F84AB7C04F209FFA16124F08953D610+-
722A3CF1578EDE7FE430C5D1D67F321086BA0DF8+72D74B2BC453A4F8F23C54E3A7417F-
1C36681156+7383EE1D444867B8F9F8F051CFF4343BB795EE28+73B2899D83B8A0C2B5A-
7B6059A155B0BEFB5ADC4+759459609126827E352FAC6F6875F39132869291+75A196C0-
E4A2805B8E22F83536C3A7DE7323A1AB+768F373C6F831EF48E303430C81198527ADADD-
65+76BFB344148FF57B070AAA145B8E1FF13F349BFA+76E170B620F90AD5DC42F47473B-
19671E64B24A3+76FCB446C6D467BB3C90074F5629807F4EC3+7732811259B3BB6B-
4EA9226FB9BAE1BBCD28E953+793C514D5EE5B344BEE851D0E1AC74A349FB2264+79AE1-
8E570C791493C7861D50C6727E2ACAAF9D9+7B3A243BC8D5D28C35BC2228E956CEC4A84-
E2FD9+7B491188699BE315594674BCF220F646374D37FB+7B6B192F80DF97B77F154759-
D52DCB36EDAA4C04+7B7646488C79B4B65E68377F031C8F311B5DA41C+7C3451A8B0815-
2D3F96D14C2A8FF7E7E9A7B35BA+7C760434848F269526B9106C1AF90ECB30C99233+7D-
71D536F0008C92359B90A562C9833F5F05FBAE+7E1C1950A7811EBE18C9A13786D368F5-
EE6D1739+7E4D270E81E09F6FC04C2CB86EAF35EF2D1E17DC+7EFADD3DCBCFC177FE279-
2B04E56ACBD41738048+7F149EDEB7FC006E217999D41B7847EBC1367C84+8037A25D01-
DFCE6B96C17B78263C9729B392BC13+80A970A07F05248443B6323179118DD60B6FE8AF-
+80D5060536A2CB4824C4EAAA49DF564AB80F8817+8168C3A6E8F8376B23E4C9C323633-
CB6A1ED311F+818B389B9692BB25405A1AC61F578B3D034D70D3+82956AA740B1BD8210-
52FF6EDC73FB2806E64472+82CE752961AA720E1762EF69C55E44CDD7DDE3A1+83629CD-
7509434E26020BC28D9F5AFBC3DF9EA5C+859280FD9FF7E586AA306B11E613BEA170B82-
44C+862921EEDF2EBDD44D546F3B05AB9AD815A128CF+86916AB2F07553D663B7F3B8A8-
1383296068D180+86A954EC560D8F73DA482F38CAF0617DCB91A816+86AD7F577807E21-
B57816992190A1568E1731F62+87167BB849E55F842DD78A4377FDD7477AD9C819+875D-
3632780DEE3B9E89995F52BBAE2EF4AA6B8E+87FF43A30177FD9801F604B94C55FA8BD8-
76EECC+88952C1DD1D4E42E32876940AB2D03E2B5AB25AC+889BC7B97BA1D324D7509E9-
FCD8D0601F6CE6E21+894DC5E08249EFF04EC49C3BCBFFCE3122E0CCCD+8A2B0EB6E654-
D220AE549C8C09EBE8D64BD2B3AF+8A7A13ED1B836A7431626A92BCBBCE77BFFA379D+8-
C199B1772784027F71C951462AC2E0ED796B1BD+8E8E22DE494E10707A8DDE6EF8A6EF8-
3810A009E+8F90BD2B1C5647DAA742BA25643F2617CDCEB383+903E82F24EE49BE72DFC-
C60ED4C64D0918F8D3EA+91A539224B5620E65E6A36FFA27ED5E5F4DCE35D+926FD4182-
E326F2F9AAC5E2DEF51016027EE6367+92FBF1C6B639D05273CB2181F19A46DA2AC968D-
B+9307B09E1DE0DA6799A827D7A51DA62BD0F7D693+931453E4CBDC0D065AA639843B5C-
12CBCD1CF26C+94CA00B23F72666493399F3E4B6C50DCE9B5571B+95302D3629AC852AF-
BEBEEF4A48C99FA096A09E8+9538D730B09FE41427ACBABCD82593EA85CA77E9+95AC53-
CCFB1854AAFC3EAB2A193EB0283107E414+95BA05F40C786971DB8B6E866A31C60D5FCD-
BEF1+968F2D92839F2D604041B3587AC0513FD983D194+96BB8D5DCA68BC49B3D4D9A7C-
53E9E76886B6997+96BD8E7BC2830968B08D67834895FE12DB07EF49+977886E5651552-
6B4F1210B460F2C0ADD7FD0D81+98E5C2870D9803E1CBE334B2EB2B718C834138B5+98F-
9E9696885D68C11AA5116A20750B98515F7AA+992A0AF2B05F9B64B4B038BF0E2FC0020-
7154492+9951D9A803C7388126FB0303DDA89031E8453F82+99DD7FC8F1C4DE68FECE2A-
B36FE289B9E01CD53B+9A26CDB3BF3904B9FC7C6E3D846D596B15E9BA58+9A412922A40-
E5239D1969BDF7CB509852CD4C38D+9B4E0AA9D3C36CD9DFFFA9E6CEE3FE62E97B5069+-
9B8B598D5D46A3BBC3B4D1AA603F98374B504804+9C3B40EEB6A12E833FD4C661440413-
9CAD02D223+9C9CF0DE4D877BDE43BAFE9E9B695BED1A29D057+9DB1718DCD5F679FA0A-
6D060679C31229B53647D+9DF89A5588542EEF76379376DA1C8D76B5AB5409+9E4F0417-
C3FF859F3C12DC2FCD5534EFFBC67F0C+9E676DB8E98F5859F6C5BF96D8B67141A8E2FC-
D3+9E6FECAA29FF31835098BF53D964C525AA8D94AE+9F0A9522F6FB6F1EE1318D2DEB9-
4E830377CE730+9F4E97792302B5CAAC3A302E8BA0F665C4488934+A059681F1A2C40FF-
54F6ADC79536140EF33BFE69+A0627FBE8951E2CA32D6DF511EC5EBB1DC2747F5+A13AC-
CB7074E264E0F240156860365BCDAFC14E8+A18B9E8897F1C5E16A12329989A79FA87D8-
BAC5E+A1E21DE9D05B134243F4210E5C7A1534E0F75CC9+A20EEB1C32CA85087E036275-
9F1B6820B15EFF38+A375B7FF8818FFDA4CCD1A9B0829A850494CD7DE+A3A7118B579EC-
83D2D685CFACCE72CAF0AC2D0D4.z". I'll try again soon.
Best regards
Robin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
On Sunday 21 February 2016 12:02:49 nusenu wrote: > > since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the > > following warnings: > > > > 09:20:30 [WARN] Failing because we have 4063 connections already. Please > > read doc/TUNING for guidance. [101144347 similar message(s) suppressed in > > last 21600 seconds] > > Are you using tor packages from > https://deb.torproject.org/torproject.org/dists/ ? I get packages via deb https://deb.torproject.org/torproject.org precise main But I use a custom startup script from torservers, that is able to handle multiple instances. It should set ulimits -a 65535 but that seams not to work. After I increased it via sysctl, the warning is gone. torland ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
On Sunday 21 February 2016 12:57:52 Julien ROBIN wrote: > When I had 2 tor clients running (the second launched manually by a user > named "tor2"), I modified the "limits.conf" file, adding those 2 lines at > the end : > > #* softcore0 > #roothardcore10 > #* hardrss 1 > #@studenthardnproc 20 > #@facultysoftnproc 20 > #@facultyhardnproc 50 > #ftp hardnproc 0 > #ftp - chroot /ftp > #@student- maxlogins 4 > tor2 softnofile 10 > tor2 hardnofile 10 > > May be it needs a restart, or it doesn't apply to what have been started by > "tor2" user before the modification When tor is launched by /etc/init.d/tor > start may be this haven't to be done manually. Thanks Julian for the hint. I adjusted limits.conf accordingly, so the users that run the tor processes get increased number of fds. torland ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
On Sunday 21 February 2016 11:56:37 Jonas Bergler wrote: > https://gitweb.torproject.org/tor.git/tree/doc/TUNING Thanks Jonas for the link. file descriptors should be set to ulimit -n 65535 in the tor startup script. I thought that would work. But checking /proc/PID/limits I saw that file descriptors were actually limited to 4096. I increased fds via sysctl. Now the warning is gone. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
> since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the following > warnings: > > 09:20:30 [WARN] Failing because we have 4063 connections already. Please read > doc/TUNING for guidance. [101144347 similar message(s) suppressed in last > 21600 seconds] Are you using tor packages from https://deb.torproject.org/torproject.org/dists/ ? > Google only spits out https://trac.torproject.org/projects/tor/ticket/16929 > which does not help me. I don't find the mentioned branch bug16929 in git. > > Can someone please advise what has to be done to avoid the warning, > or point > me where I find can the file "doc/TUNING". https://gitweb.torproject.org/tor.git/tree/doc/TUNING signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
Hi, I think it's a problem of amount of file descriptors : depending on the user, you have a limited amount of file descriptor that can be used (inside the tor's code, file descriptors are also used as handle/identifier for all network connections). I think the max amount of it (for a given user) can be checked with the command "ulimit -n" as this user. When I had 2 tor clients running (the second launched manually by a user named "tor2"), I modified the "limits.conf" file, adding those 2 lines at the end : #* softcore0 #roothardcore10 #* hardrss 1 #@studenthardnproc 20 #@facultysoftnproc 20 #@facultyhardnproc 50 #ftp hardnproc 0 #ftp - chroot /ftp #@student- maxlogins 4 tor2 softnofile 10 tor2 hardnofile 10 May be it needs a restart, or it doesn't apply to what have been started by "tor2" user before the modification When tor is launched by /etc/init.d/tor start may be this haven't to be done manually. That's all I know about it, hope it will help you to find and correct the problem ! Best regards, Julien ROBIN - Mail original - De: tor-ad...@torland.me À: tor-relays@lists.torproject.org Envoyé: Dimanche 21 Février 2016 12:39:59 Objet: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance Hi all, since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the following warnings: 09:20:30 [WARN] Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [101144347 similar message(s) suppressed in last 21600 seconds] Google only spits out https://trac.torproject.org/projects/tor/ticket/16929 which does not help me. I don't find the mentioned branch bug16929 in git. Can someone please advise what has to be done to avoid the warning, or point me where I find can the file "doc/TUNING". Thanks torland ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
https://gitweb.torproject.org/tor.git/tree/doc/TUNING On Sun, Feb 21, 2016 at 11:39 AM, wrote: > Hi all, > > since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the > following > warnings: > > 09:20:30 [WARN] Failing because we have 4063 connections already. Please > read > doc/TUNING for guidance. [101144347 similar message(s) suppressed in last > 21600 seconds] > > Google only spits out > https://trac.torproject.org/projects/tor/ticket/16929 > which does not help me. I don't find the mentioned branch bug16929 in git. > > Can someone please advise what has to be done to avoid the warning, or > point > me where I find can the file "doc/TUNING". > > Thanks > > torland > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [WARN]Failing because we have 4063 connections already. Please read doc/TUNING for guidance
Hi all, since I upgraded the torland relay from 2.6.7 to 0.2.7.6 I get the following warnings: 09:20:30 [WARN] Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [101144347 similar message(s) suppressed in last 21600 seconds] Google only spits out https://trac.torproject.org/projects/tor/ticket/16929 which does not help me. I don't find the mentioned branch bug16929 in git. Can someone please advise what has to be done to avoid the warning, or point me where I find can the file "doc/TUNING". Thanks torland ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Bad password or authentication cookie on controller.
> On 22 Jan 2016, at 08:33, pa011 wrote: > > Hello, > > yesterday I got within a minute three times the above warning in my log > file on Tor 0.2.7.6. > > Could somebody please explain to me what it means and how to solve? Someone tried to login to your control port with the wrong password. Are you running a relay monitor? (It could be misconfigured.) Is your ControlPort bound to a non-loopback address? Are you running in a FreeBSD jail or OpenVZ VM? They can bind to non-loopback addresses unexpectedly. Are you running an exit? Have you set your exit policy to block all local addresses on your relay? Tor tries to find and block all local addresses, sometimes it can't discover all of them. > Is there a source where I can possibly find answers on this and other > warnings? Unfortunately, there's no reference containing all of Tor's warnings. Search the mailing lists, source code or Internet? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Bad password or authentication cookie on controller.
Hello, yesterday I got within a minute three times the above warning in my log file on Tor 0.2.7.6. Could somebody please explain to me what it means and how to solve? Is there a source where I can possibly find answers on this and other warnings? Thanks in advance Paul ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/23/2015 09:59 PM, Roger Dingledine wrote: > If your DirPorts are on port 80, it might even just be a random bad > person on the Internet who thinks he is attacking webservers, and > doesn't even know it is Tor. > indeed - port 80 here. > I guess at some point we should make these into protocol-warns > (meaning they're info-level logs unless you set "ProtocolWarnings > 1"), since there isn't really anything you should *do* in response > to them. yes, I translate a "[warn]" into "do something !" - -- Toralf, pgp key: 872AE508 0076E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlWxVvUACgkQxOrN3gB26U4HYQD+Js4mdkSvHpqft2jHiq9fwov/ hGEGb3goh6bg2W7lKkgA/2hn2YvqlYs11xpstbNUxD+w6GvqMNBflzRAkiy8TnjZ =FVe3 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
On Thu, Jul 23, 2015 at 09:38:02AM -0400, Steve Snyder wrote: > Yes, I got the same thing recently. A burst of 56 of these log entries over > a 3-minute period on July 21st. Seen with v0.2.6.10. > > Somebody shaking doorknobs. If your DirPorts are on port 80, it might even just be a random bad person on the Internet who thinks he is attacking webservers, and doesn't even know it is Tor. I guess at some point we should make these into protocol-warns (meaning they're info-level logs unless you set "ProtocolWarnings 1"), since there isn't really anything you should *do* in response to them. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/23/2015 03:38 PM, Steve Snyder wrote: > Seen with v0.2.6.10. yep, 0.2.6.10 here too - -- Toralf, pgp key: 872AE508 0076E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlWxNL0ACgkQxOrN3gB26U4eBQEAh8Vdxp1dxod0hYpmiCIEPJkV 9jwVt5bJa4FXXR9ricIA/R+2PFRg3ZSuTk4gVQh8SKF6qGa5W0Y309/ZpxAsrDP0 =UFQ6 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
Yes, I got the same thing recently. A burst of 56 of these log entries over a 3-minute period on July 21st. Seen with v0.2.6.10. Somebody shaking doorknobs. On Thursday, July 23, 2015 8:46am, "Toralf Förster" said: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 07/23/2015 02:26 PM, Pascal Terjan wrote: >> You message seems encrypted with your own key so only you can read it. > > Ick, again here just signed : > > > Got the warnings messages today morning for the first time -I'm just curioius > if > somebody else was affected too ? > > > Jul 23 09:32:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:32:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:32:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:32:23.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:32:23.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:32:23.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:32:23.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:32:24.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:38:11.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:38:13.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:38:13.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:38:56.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:38:56.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:15.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:19.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:19.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like > someone > is trying to crash us. > Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to > DirPort. > Closing. > Jul 23 09:39:23.000
Re: [tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/23/2015 02:26 PM, Pascal Terjan wrote: > You message seems encrypted with your own key so only you can read it. Ick, again here just signed : Got the warnings messages today morning for the first time -I'm just curioius if somebody else was affected too ? Jul 23 09:32:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:32:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:32:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:32:23.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:32:23.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:32:23.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:32:23.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:32:24.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:38:11.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:38:13.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:38:13.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:38:56.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:38:56.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:15.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:19.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:19.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:20.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:20.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:21.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:21.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:22.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:22.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:23.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:23.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:23.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:23.000 [warn] Request too large from address '[scrubbed]' to DirPort. Closing. Jul 23 09:39:23.000 [warn] Content-Length is less than zero; it looks like someone is trying to crash us. Jul 23 09:39:23.
Re: [tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
On 23 July 2015 at 13:22, Toralf Förster wrote: > -BEGIN PGP MESSAGE- > Charset: utf-8 > Version: GnuPG v2 > > hQQOA9vCYl42+L0WEBAArg1D4faK3HdxN9Zqql89LPgFAdUVfIuyS+HdMpeHYGcU [...] > -END PGP MESSAGE- You message seems encrypted with your own key so only you can read it. gpg: encrypted with ELG-E key, ID 36F8BD16 gpg: decryption failed: secret key not available ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Content-Length is less than zero; it looks like someone is trying to crash us
-BEGIN PGP MESSAGE- Charset: utf-8 Version: GnuPG v2 hQQOA9vCYl42+L0WEBAArg1D4faK3HdxN9Zqql89LPgFAdUVfIuyS+HdMpeHYGcU bHuEAiFA20YWtXTqvEQZ3T1FFCN5tX3psIJdfSUmvIEo8Q8vvK18g2wAiyXUp+aG Rvm4KLfjVIYVNTO4jc3t9rFiaIhE1OtF9IY41Cr9UPZ4ICkg2Yszvy49F9FVPrjY vEvu0ng3FIdFVdNTXFg+UZ+qN7Rvv/P2cWlcgLfltE6pne+7WHFy/KTNClysyEmF ee0QciCcqs+qLAeYpKyDfbUUQMiYxA0rUKk/o6UMJyAmzwNSr+i/cY1LWhyvBaHk 7c2lqBsj2SQQeqMEnrENE/hHRdOOIMSe06lSRcOt4HG8y1MFGhOvXmA+3CyR4EYk +MazRhZ+obOwhOCo1Hq7bRnuZygRL/sE/AY+MX/OQ7Cy/MaFhIHdIdc9HZ50VgZB Ze9TclgA/Tl+hMGSG6kyuagx3K0GrdrhfAmIZltKezqFG9ug+PLEiscZ5oSBZLKz Zpft46iKSme6zhtx63CJUsoxHF73OzTkW2zVPRpsPCXW3cpMlaya/Mb9B8yB8Bqa lRbC2mql7hWMwmOCC4x5OP7usztiu7BNY53hb5FYKpwCWcM+gNFP6TR3CD+uOvVp 0kzJb+GX6bm0j4S5TcAg8BcEvVjCbtiUJfPrLDuqaZwdQSsQd0hA6wU72WhMEFAQ ANF59cv9JL2u+9o92VZ38ROvh0Cph34MAbn/s7keZWaKRb4GXaeSDeHdAnT9mMlb Pu6s+K5YrOysxA0OwICfn9GNfOPDi8paP0eCZebp8SOKwmLo/u2H9jYdqPqzgo0U scjPZA0reKBskdoPFZtdiGy/Pwb+SWjolnpjSJOOj2ziCgt0VZOyMfU+8X1T2Foj 7OqAcmz/gihhGG86g2fstF26M0rPtbB7ug9MWdxk9hNDnt14NW1+Zxa/XouWhF2x e5vbX4bSCMczD4zey0G4U0kSjJKs88CQ1dPWeHW4fZEVby1cEdq1WxS3Rz9hFWp9 uGNJZvg1NEs8JiznyKYm1ae8wzacXt0LFEJbf0NfZFxHRYdBaJ37xg1PErOIyAhJ FbEDZOTY012xf9ZgeY8FOAYVbj61v9QuB3In48m0xNNv3/fyIuUuECtuyTfOwHyt pm+oPjF7Vckj9FEljmct5qDceDbgaZU71F1cVGCM4MRhpbYw2RVSuGzjfJmkyhty cLWHysQfBI9qGjDLvyY6y5ffJX7IpwngwSXG0AgQRafAUO70ubeWMm7ExKLqgMyG LiPp5lxZj9W+bwp/pmkaAreXzZRsxwjIGsob+oLN8PFO3eU6rk2lWsNjGF8t0nWa hn8+3Oqdi00/ij1DPLuL0j7SasC1HosU6MAhgoG6gDo+0ukBSKVDsVwkavPTT1aD fwoCUhsIUtRz3O9nmVTppPk5s4XpCbKcn9SJziyDRpHoMIiXib58lOq/MjzfB6pf YUkDkvUJ0AghuPDl0LbkEPGi9WrwZSfoZxNXSj7AxdsqQYrkw/UwUrclDg8npP1R ptwGJVWbrri5lzEhFYliFQN7qgxsCicdZeZPza130gC//J4oZ0GcIzZK37NIduSQ xpCtMeofaHnUaq7hQnwk6Ac/Ct3FXY+TDbhOPKkpyH/ldRxoY25eDOvsdnMVQEo6 whooRuAiVqumMZor4hWvaJ7+/IwcgfM48xb4kxAq6iihzFCqzAQRZPIsLFyTGXn/ Z09jVjK6SaKj1U+DolmmpmIsQSmyj7G21oXO0gaf0Yu4dhjnorndQ2UoYOUSrzyg 7W2lkc64VszELxYL/sdXxbGmdJXwQKb8hVYy6DuD2xpZnp17WdvcxfhrsPnP19Th V9k1qDSSdftFcDLzKLp5yp5hJQQVnaVLFY4lrADSj996uxVYUBj6rUyl+YuLF+Sg FGWD76DiGbfo33uhC/UDgspITD3laFZlAB1FBBnondXOn6QRHXqqM+QS3mSa5h7c jSHLi68tZro5nkq4GWv/NKX0qaZVYwqi8Klzuzzk5zpuoPslk8EEtMB24BeTj8/F ugl7/GrS+cHqyO+kApXT8XdHba0L0Z0y+/geHwwgsCd5RXjqKJssEAFrgh28+zgp faJdt3bFa9CZWQnYXOwP7G8F+x10Eo9uRC6esSDmiwLvg6f6u2BBX4FJTeQl9Exd 18+P/JDmT5SM7BsfaCXhLVK15aEeSDnZkoTP0bkbeIAAJU0gkSWnGlS0WzBSqQBZ sNNVLhBbaDGI1kQuf6SUO5ULrmzU37ke9xSBucH4IrH2pEWygrKuJn1E9G+M7QBj vQ== =j7hG -END PGP MESSAGE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server.
This morning I rebooted my relay after some patching. I was running 2.6.7 on Ubuntu 14.04.2 LTS from. The server is always a bit slow rebooting but when it came back up always check the Tor relay and now I see an excessive amount of these errors: May 29 12:20:36.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 906; recommendation warn; host CC23B32FA040945FF49D94AC3D4334429CB4E2CD at 62.75.241.71:1110) May 29 12:20:36.000 [warn] 905 connections have failed: May 29 12:20:36.000 [warn] 849 connections died in state connect()ing with SSL state (No SSL object) May 29 12:20:36.000 [warn] 42 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE May 29 12:20:36.000 [warn] 8 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (TLS) with SSL state SSLv3 read finished A in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in CLOSED I still see about 7000 inbound connections and 3000 outbound, I'm not sure what my connection average is, but the current bandwidth being used is below average (from the reboot). There have been a couple DDOS alerts from my ISP the past couple days, something I never used to get. I can confirm via my dashboard nothing has been mitigated so I assume no filtering is going on, and traffic is still coming and going, but for some reason there are a lot of connections not being made it appears from the logs, and these only started appearing after I restarted my server/relay. Any ideas what would be causing all these issues? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Tried to establish rendezvous on non-OR or non-edge circuit.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21.05.2015 13:23, Sharif Olorin wrote: >> Any idea ? or its normal ? > > I'm not sure, but I also saw this for the first time today after > enabling ipv6 on a relay last week. A quick look at the relevant > code doesn't shed any immediate light on what would be causing this > (the triggering request is to establish a rendezvous point with a > hidden service, but I'm not familiar with the semantics of the > CIRCUIT_PURPOSE check that's failing). I have been getting these warnings on both of my relays for a long time, whether with or without IPv6. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVXcckAAoJEJe61A/xrcOQFboQAJFbwudTfJuQKvTQFxCQ7IAJ HWhBCCsMHRHGyRZdywJJXNx5LKx+GYnvjWqNZiYANeGKpCvAsL6oXF60s81smv1U baoXPdyA5z+GwVOTJVbC+URt1UzjMHV18Y5gdWM6w/IbBaiTUBu83KPhGrmE3z8V NFKRb8aqrfqZ+tUx6K2vIONup6/NaByFHMF6d6xJfOCC0xrYTR0a2HnFV0cDP4Ne vNYuTbLAoSkwyfQgJ0mvCLY0y+VDbW4RLgoLzBUchDIJSABghTnvfnH5U+cye8m+ fnFzY5WolIehtBwX9Y1vsJNpY9WGn9P5RO2OVKBn3s+u7IT6kIWcpVyv25MmkVUD 9c7ilxhsgdBjaEF29gAELZbAZiCPDXm2xMopwxZ67vVxBAOqc3PwbB4T4ly2idzZ dL/i9Kw4PgPWN5YIkaR6ksyz67fTwXmg14crSj63xYyZHGUY1h1gGphH/SG7HdSF +MLwJ+HKc2R9Qj0zVn3yCweybwMTgEh+d4MfkD42+dFvsebG5Kpy/vKse/IC/laM BpgPcWM3TBYkls4cq+/GzgX/qe9oeNCt8RB7H0Rq3nLdNvS7SBXZWCB+TWsq8XFr B9brTZWqzfUsqkxJARyDlUmkiygAQUliRq2ZR4I9ayWSaZw1LBKAfvX2XCg1+m9v uHVr3hEUDx5ocfUJPQ5g =QB5r -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Tried to establish rendezvous on non-OR or non-edge circuit.
Hi people .. i yesterday started IPV6 but now i see in log following messages periodically part of my torrc below. I only add ipv6 lines. Any idea ? or its normal ? Thanks Cmar ORPort 37.157.192.208:443 ORPort [2a02:2b88:2:1::3a62:1]:9050 ## If you want to listen on a port other than the one advertised in ## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as ## follows. You'll need to do ipchains or other port forwarding ## yourself to make this work. #ORPort 443 NoListen #ORPort 127.0.0.1:9090 NoAdvertise ## The IP address or full DNS name for incoming connections to your ## relay. Leave commented out and Tor will guess. Address 37.157.192.208 ## If you have multiple network interfaces, you can specify one for ## outgoing traffic to use. OutboundBindAddress 37.157.192.208 info from log: May 19 22:42:03.000 [notice] Average packaged cell fullness: 99.082% May 19 22:42:03.000 [notice] TLS write overhead: 3% May 19 22:42:03.000 [notice] Circuit handshake stats since last time: 118791/118793 TAP, 161141/161141 NTor. May 19 23:13:45.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. May 20 03:08:03.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. May 20 03:33:54.000 [warn] Tried to establish rendezvous on non-OR or non-edge circuit. May 20 04:42:03.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 4375 circuits open. I've sent 211.07 GB and received 203.24 GB. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] Tried to establish rendezvous on non-OR or non-edge circuit.
> Any idea ? or its normal ? I'm not sure, but I also saw this for the first time today after enabling ipv6 on a relay last week. A quick look at the relevant code doesn't shed any immediate light on what would be causing this (the triggering request is to establish a rendezvous point with a hidden service, but I'm not familiar with the semantics of the CIRCUIT_PURPOSE check that's failing). Relevant: https://trac.torproject.org/projects/tor/ticket/15618 Regards, Sharif -- PGP: 6FB7 ED25 BFCF 3E22 72AE 6E8C 47D4 CE7F 6B9F DF57 signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [warn] No unused circIDs found on channel without wide circID support
reply-to: tor-dev On Monday 29 September 2014 15:00:29 tor-admin wrote: > since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this > something to worry about? IMHO this might be due to a programming error in the circuit ID selection code or possibly indicate a DoS attack. > -- > Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide > circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs > in use by circuits, and 64 with pending destroy cells. (0 of those were > marked bogusly.) The ones with pending destroy cells have been marked > unusable for an average of 7594 seconds and a maximum of 16137 seconds. > This channel is 18469 seconds old. Failing a circuit. > Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of > which 4 are active. It says it has 29535 destroy cells queued. Those lines are important. I would suggest opening a ticket on trac. See #11553. Best, Robert signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] No unused circIDs found on channel without wide circID support
Hi, since upgrading torland to 0.2.5.8-rc I see the below warnings. Is this something to worry about? Regards, torland -- Sep 28 16:07:24.000 [warn] No unused circIDs found on channel without wide circID support, with 0 inbound and 4 outbound circuits. Found 0 circuit IDs in use by circuits, and 64 with pending destroy cells. (0 of those were marked bogusly.) The ones with pending destroy cells have been marked unusable for an average of 7594 seconds and a maximum of 16137 seconds. This channel is 18469 seconds old. Failing a circuit. Sep 28 16:07:24.000 [warn] Circuitmux on this channel has 4 circuits, of which 4 are active. It says it has 29535 destroy cells queued. Sep 28 16:07:24.000 [warn] Channel 93320 (at 0x7fbff4579d90) with transport TLS channel (connection 3245390) is in state open (2) Sep 28 16:07:24.000 [warn] * Channel 93320 was created at 1411894775 (18469 seconds ago) and last active at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 says it is connected to an OR with digest 4C733BAC82CC609ACC58AD95BFBFF04D5D06188C and no known nickname Sep 28 16:07:24.000 [warn] * Channel 93320 says its remote address is [scrubbed], and gives a canonical description of "[scrubbed]" and an actual description of "[scrubbed]" Sep 28 16:07:24.000 [warn] * Channel 93320 has these marks: !bad_for_new_circs canonical is_canonical_is_reliable !client !local outgoing Sep 28 16:07:24.000 [warn] * Channel 93320 has 0 queued incoming cells and 0 queued outgoing cells Sep 28 16:07:24.000 [warn] * Channel 93320 has 4 active circuits out of 4 in total Sep 28 16:07:24.000 [warn] * Channel 93320 was last used by a client at 0 (1411913244 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 was last drained at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last received a cell at 1411913240 (4 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 last transmitted a cell at 1411913141 (103 seconds ago) Sep 28 16:07:24.000 [warn] * Channel 93320 has received 234 cells and transmitted 2497 Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 78.927350 seconds between received cells Sep 28 16:07:24.000 [warn] * Channel 93320 has averaged 7.396476 seconds between transmitted cells Sep 28 16:07:24.000 [warn] failed to get unique circID ___ 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 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
[tor-relays] [WARN] crypto error while checking RSA signature: padding check failed
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 ___ 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 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
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andreas Krey: > On Tue, 18 Feb 2014 22:02:21 +, 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. > > 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. This is the case with older versions of Tor (I haven't been active as much recently, sadly) on the Raspberry Pi. When the Pi gets overloaded, Tor thinks there are clock jumps. Best, - -Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJTBsoWAAoJED/jpRoe7/ujGIoIALuGntLCZrRKvXBQKKwg+mJQ K0NwwGKWDOr62ZC6viAD1G41sTMWSlJjzPx4A3mkzC0fEkwGi6fucaTPMrIrOmTj W79KoDZVmYQ5T/jmGA+uMV69Hvs+/OfzfYxZF7pgb02KN+nbEV+kykeNNpmPzQtG znqgdurc75SHbxLh2EYs8hJ+uyRlVTOM1RKDD0TlybCFDfB1Iuie2WCrNnaPqWJM cQeLMByz8vijyXH+x2LWlJ/gVt2wOUoMKQ2eWdwX0jTqKcedjHoY3OEq+xjOitrW eKMaqpyG6XWPAElZXaYCBx0+PejaWGLB6Qp9OXKfix1XIIFW7GMe3r/tWKoFb+I= =iq0R -END PGP SIGNATURE- ___ 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.
> I've now gone and added some ntp servers from telstra, iinet and ntp.org. > Good. Well now I have a number of ntp servers listed, hopefully it > shall improve the situation. I don't think ntpd has an option yet to autoreplace bad servers from DNS pools via future DNS queries. Either way all that's really needed is 2+1 to break ties, plus 1 or 2 for redundancy. If system [ntp]date is set first, then under ntpd running for 15min+, if ntpq -np does not show one asterisk(*) in front This will tell you status of peers. > 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)". You'd have to first figure out why it didn't work out of the box. > 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. ___ 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 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, l
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
>> - configure tor to syslog > > added 'Log syslog' >> - 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. > 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 ntpd is server and client. ntp.conf can disable/restrict server and other forms of listening to just 127.0.0.1/::1, or firewall it. > BTW, looks like ntpd has the same options as ntpdate, intended for the > same functions (at least on Debian, says ntpdate is deprecated). It's said that for ages. > 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 If ntpd daemon was running right you'd see ntpdate -q's of under 1ms. .2sec/5min is way out so ntpd isn't running or running right. 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. > 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. >> - 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 > 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. > (downloading debian boot cd for example) - and no ntp server > connection failures I could spot in the logs just before. >> your ntp cli query may not be the same as the ntp >> daemon query re: udp/tcp port they use, stateful >> firewall timeout, etc... ie: somehow ntp blocked. >> Or stale/unwriteable startup drift files on disk. > > I am running the 5-minutely script at the moment. But perhaps I should > keep running the system ntpd at the same time, so I can do this > suggested test? I think ntpd will complain about unreachability anyway, and it seems to be doing peer picking above ok. >> 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. ___ 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 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 cli
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
Since you say it repeats you oppurtunity to check the system clock first: - configure tor to syslog - send an ntpdate -q pool to syslog every 5min, remove when solved. - send *.* to /var/log/all 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, 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. 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 cli query may not be the same as the ntp daemon query re: udp/tcp port they use, stateful firewall timeout, etc... ie: somehow ntp blocked. Or stale/unwriteable startup drift files on disk. If ntpdate is set, then under ntpd running for 15min+, if ntpq -np does not show one asterisk(*) in front of one of the nonlocal peers, you're not synced. And you'll be no luck until you are, fix that first. Not likely to be Tor or kernel, but you can then next - move the drive to another known good mobo/cpu box. - do the kernel event logging thing - bump tor's loglevel ___ 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, Zenaan Harkness wrote: > On 2/19/14, Alexander Makarov 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
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yea, maybe you will find something strange or regular On 19.02.2014 10:59, Zenaan Harkness wrote: > On 2/19/14, Alexander Makarov wrote: >> On 18.02.2014 23:39, Zenaan Harkness wrote: >>> On 2/18/14, Alexander Makarov 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 > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > - -- Best regards, Alexander Makarov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBCs/AAoJEBuTDJZeb03Vfs8P/3PKhPayOSwEoT2nUeUMKdo7 GLusU4CS+bPVwYkz0iGOwAG/X/Of+wOMGDseaQh/Ta0Cfex4qzNwvtXaVe/lDpEs rYq459ibWR3TApeYzS1B7H2uqRqPqDZscofClygpfzRBf44Ge6nIbqRhaq93Dg7Q +kgMKTd+HAKFgZwJRsl1c1y2ISdRFnyOs8AuBciZuN8UCQhy8iiQhTXMTAW3Dn6J +RarlCN0FqD1Z0nCdNjMEAqQH6r2z4kX9rnMr3TkXwgKoJjuHn/PhLa6kjBUbnE0 cKHfL0ww8Ur+yG3H42mny0/sgrv+lF9vLzYDzo6LdvXWGXadt5703KsLkhZ0Cw1f sb8+mJ+uhyCiSNOFcZp1nQ82bXskFYpf1HrpBJaby+r9ZeovMH5RAVw95Ghnp+f9 MvuVMOR6ufp9MFBkHuULmeHA/mT4vXzupQNHSeXR5OwoknR52dbnyb3JDKCFd+sB sXqVorEobXFtWlft2aEAYC7pSTiKNypaFc0jDwAoGWNGWDfQs1iTz7XjZ2bqoDw0 bhqgGVvOOUPE4G6X14RBcZ1nk4esQyY11eJGPyRsp6r5D9iMNebhkfEo3US9Sx2B c+OBrWCO0I51A218TV5+wITuzq8gbq8WnwfX3TSSvydd85Gtl0pyTJeQYhalFgJV M8bVnTpBMSzjNO4eBJJQ =u1Rp -END PGP SIGNATURE- ___ 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.
Iinet are having some sort of problem this morning which was just resolved a short while ago. ___ 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 wrote: > On 18.02.2014 23:39, Zenaan Harkness wrote: >> On 2/18/14, Alexander Makarov 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
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 wrote: > On Tue, Feb 18, 2014 at 12:02 PM, 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. > 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 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 Tue, 18 Feb 2014 22:02:21 +, 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. 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. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ 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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could you show the log? Can you rebuild you kernel with debug option and check what kernel events have the same timestamps On 18.02.2014 23:39, Zenaan Harkness wrote: > On 2/18/14, Alexander Makarov 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 > - -- Best regards, Alexander Makarov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTA1nlAAoJEBuTDJZeb03VbSkQALF56FA/x/PjHFdsqeHMismS OwaQXDEp9LwnMhTwy+sl67FTZqGegKy/eY/elfTV35Tz2J2zEraj05CoiJMIIN1z Sw9/PH2OexWsGPO6ZrfnhwcO1e+lgso2ayQNYeAkV2o2xy+87hJmlKUq5Zf+3SBJ xGziNJ8WKq9ttArMwkXy26SsuG6hWGPRSU/CE//CDdanqiufp5t1qEiv5OnkmcdN ji0MqwVjwJz7ccJnyAS/6KgoCeROkntxuu8PrSmpFhlkcGr+lugtOK2ccBALeomX EjMVMg3qbC9ZeCVm6LCKSL43LNjjptkXQPumS8w/hLD6LwNZO3pmPIAB2wMqIs7w TALp2psg1cJnl6wiYqt9b/x3gQc3iTcFq0ME0C41wohoRL8fFyVCOZ3Shcyi27Vp zJzfkKJAzAoLPiZa3R0t1/v9z/vp0kYQSUlIaVlNgBF4w+BlS2S1WypVrc0G+rsu SATj0C9JXpMe8T3QtZByIOGoLWbuBKsCbeSTvuYLrKRPIgDTk6XOeQefXraYWbtz K+9MjaIRy7nEq4rgOz9MxwyabBegnaBQhk/nAkpVIpQJwhBRcTRMFwtmRz/Fuu/I o2TUFghlfRSD1exWmROUHKm9wTl8Nop6JN0nNuXtybca4Hze4LuG+hwQQ29OUvr5 eJ7QRxdPLJnNWwk0iPR5 =duvg -END PGP SIGNATURE- ___ 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.
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. On Tue, Feb 18, 2014 at 12:02 PM, 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? > > TIA > Zenaan > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ 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.
I was told by a network engineer that recently there have been attacks targetting ntp. It may or may not have anything to do with your relay though. Robert > > 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? > > ___ 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 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.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maybe problem with hardware clocks? 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? > > TIA > Zenaan > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > - -- Best regards, Alexander Makarov -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTA0gIAAoJEBuTDJZeb03V5h8P/17FbMwXPJZ9X+uKWN+A2fSq TTIbrOn1CQ5w/JW2Pqg5ykC/Q5QSxIJTWHnXl7dppQ82tkPtSBbRHjXSddgq2WwS csGqV70KIPpr9FTGyuLrZPnNognKpdorzaYy5lq1ECp1IQkrdweuzbQEdUpeLnOq n3O00Bjf4WhFHSpKdXPjHDpGac2GPywRoqsrF6OCVrVSN0ptZiPibRP1RDvYl0bb 8P6iQ7+53rIMvzuDGSaAh1yFVAB1ilbnMUXGZpNpBS9yYLt7m6Pg8MbvM+1/tXHQ a3J1QWFwUduF2pvBIokeb8FjJsWwQDbSYm76lNxAwsVDWTo4KCns2+vWLUwkN4Tv HQVXIGKPHoS/p9QBXrKz26zWlK4V6NY6FlfrYzkwkNeRf+ZCFZGJIOGIZryniXAH RTN6/dBgr3MrxZiWViS96TkEVaS315qtIVfS3clgN9FdtoB8KpojN7N8V7s2ODFI 43Au4M6FEQjeGm371MfiAtZOtDuWrER3rH+vgFyE1yl5UkeidLIIAwMNIm31WSXq /UxrhXb4NxF4oM+Qj3rvXTPKUtEym/gBlFEztyhXUOrOjs7kzr4550Um9B2ehcAo FWs4JQKlElQbEl5QsXC+HH9YzSCK4cLh1QcbbiM8gpIuuuFJ7Bsr+TlAIRBIdVXd 668JcZMi9/NW6+8LgyZ+ =EMtC -END PGP SIGNATURE- ___ 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] Tried to establish rendezvous on non-OR or non-edge circuit.
On Fri, Jan 25, 2013 at 8:12 AM, Samuel Walker wrote: > Hi, > > I've started receiving this message on my relay (non-exit, non-hidden-serivce) > >> [warn] Tried to establish rendezvous on non-OR or non-edge circuit. > > I've had a look in the bug tracker, and it looks like it was previously noted > under 4171, with the cause being 4641. Both now fixed. > > Should I be concerned over this? Probably not. The likeliest explanation (from what I can tell) is somebody else running an old buggy version. Not your problem, most likely. -- Nick ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Tried to establish rendezvous on non-OR or non-edge circuit.
Hi, I've started receiving this message on my relay (non-exit, non-hidden-serivce) > [warn] Tried to establish rendezvous on non-OR or non-edge circuit. I've had a look in the bug tracker, and it looks like it was previously noted under 4171, with the cause being 4641. Both now fixed. Should I be concerned over this? Many Thanks ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] [warn] Request too large from address '[scrubbed]' to DirPort. Closing.
Hi, last night the log of one of my nodes showed within 2 minutes about 160 of these messages. Traffic stats show that the incoming bandwidth increased from the average of 300 Mbit/s to more than 400 Mbit/s, where at the same time outgoing traffic dropped. From the peak I see, the requests must have been really big. Does anyone noticed this on other tor servers too? Regards, Klaus signature.asc Description: This is a digitally signed message part. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
