Thx for the fast replies, I wasn't really scared but rather curious about what the logs were saying.
On Wed, Jan 02, 2008 at 05:22:36PM +0100, Csaba Kiraly wrote: > Hi, > As far as I can tell (I'm not a developer) the error message you see is > normal behavior, just logged in a way that scares people ;) > Of course it can also be something else, but you can find a possible > explanation in my previous mail in the "no traffic?" thread: > http://archives.seul.org/or/talk/Nov-2007/msg00038.html I read the message, and there is a simularity, mayber there is something about openssl with freebsd, as Scott Bennet lso runs a freebsd machine. Mine is running now with freebsd7, but the logs did show up also with fbsd6-stable. > > The cause is a housekeeping operation at the other side, which tears down > your connection, but for some reason the TLS session is not closed nicely. > Messages in the two logs should be similar to the following (say "auth1" is > your machine, "auth2" is the other node): > > auth2 Nov 06 13:18:50.660 [info] run_connection_housekeeping(): Marking > duplicate conn to 193.168.2.1:34066 obsolete (fd 16, 140 secs old). > auth2 Nov 06 13:18:50.660 [info] run_connection_housekeeping(): Expiring > non-used OR connection to fd 16 (193.168.2.1:34066) [Obsolete]. > auth1 Nov 06 13:18:50.661 [info] connection_read_to_buf(): tls error. > breaking (nickname auth2, address 193.168.2.2). All correct, the ones I cannot really understand are those: Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: oaep decoding error (in rsa routines:RSA_padding_check_PKCS1_OAEP) Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: padding check failed (in rsa routines:RSA_EAY_PRIVATE_DECRYPT) and the ones with: Jan 02 12:45:57.965 [info] TLS error: <syscall error while writing> (errno=1: Operation not permitted) Jan 02 12:45:57.965 [info] connection_handle_write(): tls error. breaking. Jan 02 12:45:57.965 [info] TLS error: <syscall error while writing> (errno=1: Operation not permitted) what should be not permitted ? strange... > > This does not justify bandwidth problems, so you might have to look for > some other reason as well .... > Csaba > I reckon one reason for bandwidth behaviour is, the node runs with another secret-key, as I lost the original. It may take some time until it is 'named' again, so the 7 authorities handle the node differently. How long does it take nowadays for a registered name to expire and the name to be used for (in my case the same) new machine ? > Alexander W. Janssen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hans Schnehl wrote: >> >>> Hi, >>> >> >> Hi! >> >> >>> Jan 02 12:46:06.204 [debug] TLS error: <syscall error while reading> >>> (errno=54: Connection reset by peer) Jan 02 12:46:06.204 [info] >>> connection_read_to_buf(): tls error [connection reset]. breaking >>> (nickname NoNickNode, address 111.112.113.114). >>> >> >> It looks like one of the nodes you have a connection too just kicked you >> out for some reason ("connection reset by peer"). This is pretty normal. >> Could be the remote node shutting down the software, rebooting and such. >> >> >>> Jan 02 12:46:14.711 [debug] crypto error while performing RSA >>> decryption: oaep decoding error (in rsa >>> routines:RSA_padding_check_PKCS1_OAEP) >>> >> >> Not sure about those, but it could be consecutive errors resulting from >> the encrypted connection (TLS) being shut down. >> >> >>> Tor is running, but appears to be using only fractions of the >>> bandwidth it is supposed to. Can someone please give a short >>> explanation? >>> >> >> No idea about that though. But it usually takes some time until everyone >> learned about your node - from my experience it takes up to 24 hours >> until the bandwidth is fully utilized. >> >> I'm just guessing from my generic experience :) I had with Tor 0.2.0.7 and ..06 a full utilizatiojn of bandwidth within roughly 2 to three hours after reconnection, but that was lost somewhere with the next -0.8- to todays -0.15. Regards Hans
